jckarter

jckarter

@jckarter

everyone already knows i'm a dog

the swift programming language is my fault to some degree. mostly here to see dogs, shitpost, fix old computers, and/or talk about math and weird computer programming things. for effortposts check the #longpost pinned tag. asks are open.

log inask
email
mailto:joe@duriansoftware.com
discord
jckarter
webzone
duriansoftware.com/
code stuff
github.com/jckarter/
fediverse
f.duriansoftware.com/@joe
bluesky
bsky.app/profile/jckarter.bsky.social
rss
duriansoftware.com/joe/index.rss
jckarter
@jckarter

I've seen a few "where is the cohost app" posts go by. I know that bacefook had their big "native-first" epiphany like five years ago after trying webtech and everyone's been following their lead since, but it seems to me like the calculus has changed again, and as a user, I prefer web apps to "native" ones for a number of reasons:

  • I know the devs don't have to pay 30% to, or satisfy the arbitrary whims of, a platform gatekeeper
  • web browsers have relatively functional sandboxes compared to native apps, which have a lot more ready access to quietly mine your device for data (and the platform owners largely look away and pretend not to notice for large apps)
  • good web browsers impose resource limits on pages, so you don't have the "chat app takes up 16GB of ram problem" as much because the browser will crash the page before it gets to that level
  • you have a higher baseline of functionality with webpages than apps—text selection, cut and paste, ability to grab original images (using web inspector as a last resort if the page tries to prevent you from right clicking), ability to run multiple tabs at once without relying on the app implementing multiple session support, etc.
  • back in ye olden days, "native" platforms had a strong baseline of functionality in native widgets that would be hard to fully replicate, but these days, the native platform holders have lost their focus on what even their "native" APIs are, and don't seem to care much even for their first-party apps about providing a coherent platform experience. As an old, I lament the loss of clarity, but this "anything goes" environment also means that the barrier to entry for non-"native" experiences is much easier to surmount, and more accessible to limited-resource devs.

As a developer, ideally you should favor web dev because you have to pay less to fewer people to deploy, and you actually can "write once run almost anywhere" these days. As a user, you should favor web dev because it's better for the devs, and for the reasons above. Or am I missing something?

You must log in to comment.

in reply to @jckarter's post:

vyr
@vyr

as a user, i favor mobile apps because good ones:

  • are waaaaay more responsive
  • work better on slow connections and older devices
  • explicitly save state when the system kills them due to low RAM so i don't lose the post i was typing. browsers will do Whatever
  • actually use native controls and gestures: iOS bottom-of-the-screen menus and tab bars, swipes, tap top to scroll up, pull to refresh, pinch zoom on images, etc. most webapps have never been used with anything but a mouse and it shows
  • have native notifications, which i can control with system notification control UI
  • live in my app switcher instead of my browser tab switcher (iirc this is more of an iOS problem and Chrome surfaces individual tabs on Android)
  • don't have weird leftovers from the page-as-document metaphor of webapps or the default behavior of browser controls. yes, you can do all the things you said. you can also accidentally select button text when selecting actual text, or zoom the page partway by accident so it looks weird until you fix it, or get the thing that happened right now as i was typing this post where the text box just wouldn't resize after i typed some text above the end of the post and scrolled and i couldn't see the end of the text box any more. oh it happened again. twice

i understand the need to prioritize, but the jank of a webapp is very grating for a heavy mobile user like me. it's death by a thousand cuts. honestly, it has been a reason why i don't use Cohost much.

ime the very best apps that a hypothetical ideal Cohost app should be imitating are third-party clients for services with rich APIs, written by people who don't care about the service's goals per se and just want to give a good user experience: Apollo for Reddit on iOS is the best example i can think of. Metatext for Mastodon is up there. Paperback the manga site client. stuff like that. (half points to Tweetlogix for being fast as hell but having some weird UI choices.)

the worst ones are the apps that reimplement everything available as native controls, but halfass it on top of web tech, so now it's clumsier than native and way worse than the webapp. Discord kinda falls into this category. most shopping apps definitely fall into this category — i'd much rather use a web browser so i can have multiple tabs and all the good web things you mentioned.

i literally can't get back to the top of the post now so let me just close by saying that i've worked on both commercial webapps and commercial iOS apps, and i'm really trying not to talk out of my ass here.

login to reply
jckarter
@jckarter

I agree, I really appreciate the reply @Vyr. You brought up a number of things I hadn't thought about. It's frustrating that web and native APIs start off with such a disjoint set of ground-level functionality, and both require more effort than most devs bother with to meet the other's strengths. You can make a responsive PWA that uses caching and local storage well to load quickly, restore state, and remain responsive with a bad connection, but few bother.

I wish platforms would more readily embrace the fact that the web browser is an application platform now, and provide better integration with native app switching, notification, and other system UI features to web apps, though of course most platforms have an ideological and/or business bent toward keeping webapps second-class to "native" apps.

login to reply
vyr
@vyr

yep. while Apple engineering is honestly doing some great work to make native development extremely easy (SwiftUI/Swift async fangirl here) and there are arguments for not letting every pissant web ad company get at every API in your OS, Apple financial wants their 30% and they're in no hurry to make webapps much more useful, especially when most of the APIs for doing that have been spearheaded by known ad company Google. can't wait to see some EU action on that front soon 😄🍿

login to reply
bem
@bem

the fact that mobile browsers (particularly mobile Safari) just kill things Whenever, coupled with the way that I tend to just use private browsing for everything because there's no other good way to prevent browser state from accumulating, means that I basically can't stay signed in to any web site for any length of time on mobile. this is why I don't really use cohost yet: I have to be on a real computer and actually putting energy into it and right now social media is an iPad thing for me

I totally agree that the cohost devs shouldn't actually make a mobile app though. it's more than just the 30%, it also puts you at the mercy of Apple's arbitrary content moderation rules. see also Tumblr

login to reply
NeoNacho
@NeoNacho

It apparently is still impossible for a web app to even match the basic experience of a table view, without either tiny pagination intervals or breaking after scrolling through a couple pages, so it doesn't seem like we're very close to matching the experience of the Twitter app (which isn't even very good!) on the web. That's without even thinking about accessibility or offline/low connectivity scenarios.

login to reply
tjhorner
@tjhorner

all of these points are valid, but unfortunately the mobile web is extremely janky and fucked right now, especially on iOS (and that is almost certainly intentional on Apple's part). basically I agree with what @vyr said

login to reply
Pinned Tags