Because Apple is intentionally limiting the mobile web to force your hand to create an app.

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.

Is there anywhere I can try out this application?

Nothing I can show of it yet, but I encourage you to look into the WebUSB and WebBT APIs with an open mind.

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.

Oh, I know this one! Because Apple made Safari the new Internet Explorer to force you into their walled garden where they extract their tithe.

I can't stand building for iOS Safari. It is the pain-point in so much of my development.

It's hard to do photo/video/media integration on a web page. There no good way to interact with the filesystem to share content, start a livestream, etc. UIKit also make it pretty easy to create layouts that work well on your phone with swiping gestures.

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.

Your service not having access to my data is a feature. It's one of the primary reasons I prefer websites over apps.

what if the service is a way to manage your data? In my case its a photo library alternative for fitness photos/videos. Take a picture of your handstand every month and store it locally in the app documents folder or on PhotoKit so that you can see improvements over time (nothing is stored in the cloud). I don't know of a way to do that on a mobile website.

I wish you well.

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?

I personally like keeping it separate from my phone's photos/video folders. You can also add notes/rep counts and add links to useful workouts you find online.

What personal data (that you didn't explicitly provide or allow access to) does an app have access to that a website doesn't?

There's a million things they can do. Permissions aren't that fine-grained, and the apps always have ways to infer a lot of stuff. Heck, they can even make background tasks, while if it's a website I know that if I close the tab your tool is gone.

There's a whole range of things that an app can do/infer on a system that a web page in a browser can't.

Things like processes that are running, RAM, battery life, and more.

I don't know about iOS, but the file picker on Android is fine. Live streaming through Javascript is also no harder than live streaming through native libraries. Granted, there may be less "official" SDKs out there because the web is an open ecosystem, but still.

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.

Even if technically all SDKs had an equivalent, a PWA never, ever feels like a real native app. All the difference is noticable. It's all the slight details, gesture and touch handling, and few more, but they all sum of and it feels laggy.

I think people are used to just scrolling to an icon on their home screen and tapping on it, and companies like Apple/Google don't really like the idea of PWAs because they lose control over the developers and walled garden ecosystems they have created

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

Google actually pushed for the PWA and did/does things to support them. It’s largely Apple that has made them more difficult/impossible.

Chrome supports installing web apps to your home screen, though clearly even among the HN crowd that is not common knowledge.

Apple doesn't support a lot of modern web api or the api they provide is crippled. just few examples: there is no full screen mode Web api on iPhone - only on ipad - games pretty much require those.

There is no web push notification support on ios - only on desktop safari.

Because apple deliberately hobbles mobile safari so that you need a native app to get real stuff to work. Google talks the talk for web apps but still falls far short. And why not? They are making so much money by not actually supporting web apps. It's in both companies DNA now.

>Serious question, why does everything require an app?

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.

>An App button on your home screen is zillion times better for 95% of user than a web address.

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)

Apple intentionally hobbled mobile web for a long time on iOS to incentivize people writing a native app over just making a webapp.

onlyfans is doing just fine in this space. They didn't want to worry about app store TOS or % cuts and decided to be web only.

While a good example of a web app that could've been a native app, there's a strong argument that they didn't decide to be web only as much as forced due to the nature of their content never being allowed in the app stores.

Yeah, the online gray area companies like porn and gambling are the ones largely holding up the web at this point.

We're building a mobile app because our users demand it.

Nowadays even most games are casual games that can also be run on the web easily. I'm personally making my first game and it's going to be delivered through the web. Crossing my fingers that people actually appreciate the lack of a download and the cross-platform support out of the box.

I’m wondering if native mobile apps are doomed to disappear as the web and mobile Browsers meet in the middle, the same way everything was a native app for quite some time in desktop land and now everything is a webapp.

If you watch Apple they're doing everything within their power to make sure this doesn't happen.

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.

Doubt it, mobile phones have only increased in features. More features, more likely need native app.

What incentive to does Apple have to make people use apps less and the web more?

What features? Not every app needs access to your camera.

Apple doesn't allow third party web browsers on iOS so native apps are the only viable solution until that changes.

My guess is that this will be the subject of a lawsuit at some point.

Usually for proper push messaging and background processing

Those have been part of the web standards for ages (serviceworkers, web notifications).

Correct me if I'm wrong (I'd actually love to be wrong), but browsers don't let you do silent pushes, and background data fetches are pretty limited, which makes it hard to do something where the phone gets updated frequently with non-urgent data, so that when you open the app/page, you have current data regardless of connectivity when you open the app, assuming you've got at least intermittent connectivity.

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.

Push is supported by all competent browsers, which of course excludes Internet Explorer, Android WebView (the shitty built-in one) and Safari (iOS and desktop) [0]. Firefox (on every platform but iOS) even supports a limited amount of silent pushes. I personally wouldn't want silent background pushes to an installed web app anyway, I don't see what data is important enough to sync but not important enough to notify about. Such a mechanism would absolutely ruin the device's battery life.

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...

Nitpick: background processing doesn't generally kill battery life because the platform API's provide guardrails around how long/frequent you can run, and batches as many wakeups together as possible. You essentially have a runtime budget you deplete as you run.

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.

Why the heck do you need to be constantly pushed headlines, sport scores, and non-urgent messages? Just make them load fast, so when you only use resources on the device when the app is actually in use.

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.

Because I want to use these things when I have no connectivity. And I don't always plan ahead for no connectivity.

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

"Proper" app development treats the network as optional. Its surprising how spotty connectivity is in the real world, and so its a huge UX boost to load data predicatively when possible (not to mention that running offline-first is a magical experience for the user).

Web notifications don’t work on iOS and I’m assuming Android as well? Serviceworkers aren’t woken up in response to a background push if your phone is lock and not on that webpage.

From a user standpoint, Web Notifications work quite well on Android. When using Chrome for Android (Chromium), each site is assigned a separate Notification Channel so users can change notification priority or block notifications. Firefox for Android (Gecko) works similarly but without Notification Channels.

Web notifications work fine on Android. Has Apple still not fixed notifications then? I was under the impression that they claimed to have massively improve Safari during last year's conference?

AFAIK web notifications do not exist on iOS.

OK, well iOS doesn't adhere to the standard, which means most of the US mobile device market does not support it.

Yeah, not supported on iOS.

Well, there was technically that iOS wallet/pass trick - dunno if it's been plugged tho.

Otherwise, yeah.

not on mobile safari

Right, and for those who aren't aware, that means not on any iOS browser since they all (are required to) use safari under the covers

With apps, publishers have more control, compared to webpages. For example, it's harder to block ads, or specific components of the page.

Many features aren't available on the web. e.g. web midi isn't planned on being worked on anytime soon by the webkit team. Also, iOS Safari browser updates constantly break/maim apps. e.g. iOS 14.4.x all had real time audio processing issues that weren't fixed until iOS 14.5.

Wrong question