I've been working on hardware that we've been trying to ship using open technology for the protocols so it doesn't need apps. So focusing on things like WebBT and WebUSB which is almost magic, a user can unbox your device go to a website and then do anything you'd possibly want with. But yeah all falls apart the second it needs to work on an iPhone and you're back in the world of having to build an app.
Whole thing works flawlessly with just a webdev team on computers and android devices but because of Apple to ship this vision we need to build a solitary iOS app too.
I say this as an iPhone user too, unfortunately I feel too locked into their platform to leave now.
I know a lot of HN users don't like them because they see it as a gateway to fingerprinting, not sure how much truth there is to that but for me I see there is a huge benefit to devices being able to communicate with our computers over open and understandable protocols.
Currently today, say you buy an IOT device you have to download a smartphone app. On a long enough timeline that smartphone app will stop being updated and then eventually it will stop working after an OS update, especially if its iOS and then at that point the device basically becomes landfill fodder.
If it were WebUSB or WebBT you just need to ship a web page, there is a greater chance that web page will still work down the line with newer browsers, if it doesn't rely on a server you could even archive that web page and at least it's easier to reverse engineer. Not to mention the web app will work on Linux too, no need to ship platform specific executables.
For me WebUSB and WebBT are great moves towards more sustainable and maintainable hardware.
I am an app developer that would love to move to a mobile web app but those are the problems that I am running into at least. If web assembly can accomplish all of that then I just am not well educated enough to use it instead.
Jitsi and Kickstarter have quite competent streaming systems. I remember being amazed by the incredibly low latency the Kickstarter streaming system has (always sub 100ms between camera and my screen across the Atlantic with good quality!).
An app for uploading images and videos, writing text posts, receiving payment and streaming video doesn't need a native app. If there is a choice between giving an absurd percentage to Apple or building a web version, the web version makes a lot more sense.
However, even if they build out a web version right now, Apple will refuse any update pointing users towards the web version of any app because that goes against their TOS. That will make any switch quite difficult.
Things like processes that are running, RAM, battery life, and more.
I wont be a customer because I don’t care enough about my looks or fitness to get into daily photos. But, really, what does your app offer over the photo gallery and folders already on my phone?
Developers will optimize for what feels natural to the user, i.e. installing an "app" which doesn't require typing an address in the browser or scrolling through bookmarks
Also some companies from the developer side will want that extra user control that you don't have in the browser, for example to track them more, play unskippable ads, or access to some native features on the phone which are not available in web apps
There is no web push notification support on ios - only on desktop safari.
An App button on your home screen is zillion times better for 95% of user than a web address.
If Apple allowed one click installation of Web App. ( Not clicking on Safari settings and add Site to Home Screen button ). Or Scanning a QRCode to download a Web App.
Along with adding all the missing Web App features to Safari that could be enabled only for Web App and not Web browser.
That would have been fine by me. This is borderline as good as side loading.
I can create a button on my home screen that will take me right to a web page with one click (on android, I'm assuming you can also do this on ios)
Current day because they've neglected Macs so much over the past few years your Mac is now mostly just a shell to run a jumble of electron apps (I used to love Mac Cocoa apps but can't even name one that has launched in the past 2 years) but if you follow what they're doing they'd prefer it if it was a selection of iPadOS apps instead.
What incentive to does Apple have to make people use apps less and the web more?
Otherwise, yeah.
Weather, headline news, sports scores, non-urgent messaging could really use silent push to get data synced whenever you want to use it, but clearly not with Safari on an iPhone, and I don't think you can do it on Android without an app either.
It's exactly this kind of wasteful resource usage and the accompanying notification spam that drives me to avoid native apps in the first place.
Given where I live, my big one is ferries. When I get on the ferry, it's a nice time to see what's going on in the world, and what the weather will be like, and maybe check work email (before I retired), but I can't do any of those in an online only world because cell coverage is very spotty. For the small handful of apps that manage a data store on the device, I can use those and catch up on things and queue outgoing messages. I'd like to make some more things for me, but native Android development is beyond my patience, and PWA doesn't have the capabilities, and some horrible blend of the two is what's wrong with today's world :p
Google, being Google, have developed a Background Sync API [1] that can achieve background sync without notifying the user. This also extends to Edge and Opera and such because they share an engine.
I can see the use in a system where you sync data to a device that has intermittent connectivity, but I've honestly never seen such a system work for native apps when I've had intermittent connectivity myself. Even Google's automatic weather notifications don't show the right weather until I tap then and a web search loads.
Your background sync requirement is a nice to have and it'd certainly be a reason to use the app instead of the web version of a service for users with limited connectivity, but they're not really strict requirements for most applications. The applications we use today mostly consist of scrolling and connected browsing, with some data management and sync in between. For example, I browse twitter through the web app and outside the "fleets", whatever they are, that Twitter simply decided not to port, I'm not missing anything. I get notifications, I can browse, I can compose, there's really nothing more I need.
In the end, Apple's (intentional, probably) nerfing of Safari is what primarily stands in the way of proper mobile app support on the web. Notifications are a feature that I'd say most apps would require these days and Apple simply refuses to allow them. There's plenty of other WebKit gripes that developers have to overcome to program for iOS, but the complete lack of certain features is absolutely the worst.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Push_API [1]: https://developers.google.com/web/updates/2015/12/background...
That said, you're right that most apps dont truly take advantage of background processing. What you have to understand is that the lack of background processing is what keeps notifications unsupported on iOS. Not only can you not support push messaging natively, but you can't _replicate_ a push messaging system either because there's no way to run code when your webpage/PWA isn't in the foreground.