Yes, there'd be way more of them, because the barrier to entry (and justifiable motivation for needing an "app" in the first place) would be even lower.
> and justifiable motivation for needing an "app" in the first place
I don't understand this at all. Lack of push notifications is one of the biggest reasons why I still have a number of native apps installed, apps that could be sandboxed webapps otherwise. I have heard push notifications on iOS used as justification for building a native app instead of a webapp so many times. I have talked with users about how there are certain services (Facebook, Twitter, etc...) that I refuse to install on my phone, and their response has been, "well, I'm installing the native app because otherwise I won't get a notification when I'm messaged."
I have a hard time believing that lack of notifications or the barrier entry to building iOS apps has made companies more likely to build websites. My experience has always been the opposite, if I ask a developer why they're building a native app instead of a website, there is a really high chance that push notifications are the reason they give me.
----
And there's honestly not a lot of reason for most apps to be native apps at all except that:
A) data storage is unreliable and can get deleted unrecoverably without user prompts.
B) push notifications are unreliable on Android and don't work on iOS.
Email, timers, alarms, every social media site, etc... How many native apps are on your phone -- apps that have much greater access to your hardware and that can fingerprint you with a lot more ease -- that realistically never needed low-level access to your hardware in the first place, and are only native because that's the only way to provide notifications or work reliably without a server?
Honestly, my biggest criticism of push notifications (and part of the reason why I think they're less powerful than people are making them out to be) is that they're server-centric; the push notifications standard has all the fingerprints of Google saying "well, why would anyone ever make a webapp that didn't have a backend?" If there was a reliable way to schedule notifications/alarms offline without ever going through a server at all, and if there was a reliable way to store user information where I didn't have to worry it would magically vanish unless I backed it up to a cloud, I think I would be able to uninstall something like 50% of the apps on my phone and replace them with trivially small Javascript apps. And whenever a company tried to give me some bloated mess, I could run an adblocker on top of it or just deploy my own replacement.
And that would be a really good thing. It's good that (for example) Wordle is a PWA because I can run an adblocker on top of it. Wordle is far better as a PWA than it would be as a native app. Similarly I honestly should not have to install an alarm app on my phone; that does not need direct access to my hardware, it can be a webapp. Except it can't, because there's no way for a user to allow a website to schedule an alarm.
I too want to just use mostly websites instead of native phone apps, and I too don't want my data sent to a bunch of random servers someplace. I don't understand how people think that blocking basic functionality makes companies less likely to require native apps though. The reasoning does not make sense to me; I don't know what I'm missing but the argument seems like it's saying that making something easier will make fewer people do it? I don't understand that logic.
----
Edit: Ok, charitably, if the argument is that this will make more of the limited webapps that exist today ask for additional permissions, then yeah, I see that.
But A: most of those companies were trying to get you to install native apps before
B: having those companies hand you a webapp gives you much more control over what they're doing, including doing things like blocking prompts and setting up extensions to block their nag methods, which you can't do natively.
And C: it sounds like Apple is basically duplicating their install permissions for notifications anyway, which I think is a very sensible approach.
It would be good for push notification to be revisited as a standard, because I think it's a kind of terrible standard? But it would be good to revisit notifications in general. And Apple's approach, which explicitly wires push notifications up to obey the same permissions and settings as native apps, seems like a good step in that direction.
I mean specifically the ability to prompt to install a site as a PWA. If they add such a prompt, then you no longer have to go to the trouble of having an app before bugging the user to install your "app". That barrier's the only thing that keeps the "THIS IS BETTER IN THE APP" spam to a tolerable level, as it is—and only barely.
> And there's honestly not a lot of reason for most apps to be native apps at all except that:
Battery life and performance. Except for the ones that shouldn't be apps of any kind, whatsoever, but just websites, which is admittedly a lot of them.
> I mean specifically the ability to prompt to install a site as a PWA. If they add such a prompt, then you no longer have to go to the trouble of having an app before bugging the user to install your "app". That barrier's the only thing that keeps the "THIS IS BETTER IN THE APP" spam to a tolerable level, as it is—and only barely.
I don't believe this at all. The barrier of entry around building iOS apps is small enough that it pretty much only applies to small developers. What that barrier does is it means that fewer 1-2 person Open Source projects offer replacements for those native apps.
But any company that has the resources to track you and cares enough to get you to install an app, also has the resources to make one. Increasingly, what's common in this space (especially with newer social networks) is to just not have a website at all, and to only provide an app. I don't think those companies will change their behavior regardless of whether or not push notifications are supported -- the only thing that will change there is whether or not smaller sites can get away with offering alternatives.
I also think it's a really bad long-term strategy for us to say "we'll prevent spam by making computing less accessible." Notification/app spam is a UX problem (to Apple's credit, it's a UX problem that it is putting significantly more effort into solving than Android is). That could be a longer conversation, but the solution to this kind of spam from websites is to rethink how we provide capabilities, not to stick random hurdles in front deploying apps. Again, long conversation, but I have maintained for some time that websites (and native apps) should not know what they have access to. It should not be possible for a website to tell whether or not it's been added to a homescreen.
> Battery life and performance. Except for the ones that shouldn't be apps of any kind
Opinion me, most applications (calendars, email, text editors) are just interactive documents. People have this clear line in their head of the difference between an app and a website, but my alarm clock is not special in the way that Blender is. My alarm clock is an interactive document, it could be a PWA and it wouldn't be a problem at all for my battery life. My notetaking app on my phone is an interactive document. It thinks it is an app, but it's not -- it's an interactive document that has been made into a native app because it doesn't have reliable offline storage otherwise.
My contention around mobile devices for a while has been that a lot of websites don't need to transmit data off of my device at all, and it would be better for everyone if they didn't have a backend. Whether that makes them a website or app, I don't know, that's semantics to me. Regardless, the point stands that they should have capabilities available to them (alarms, scheduled notifications, pin-to-homescreen, caching resources) that allow them to be used offline.
> I don't believe this at all. The barrier of entry around building iOS apps is small enough that it pretty much only applies to small developers. What that barrier does is it means that fewer 1-2 person Open Source projects offer replacements for those native apps.
Well, a lot of sites that probably would spam an app if they had one, don't, because they don't have one, for one thing. Also see every single PWA discussion on here for an endless stream of PWA boosters complaining about how it's too hard and/or expensive to write native apps. Apparently it is an effective barrier, if we believe them. It's the entire reason they want PWAs on iOS—to remove the barriers to deploying apps to iOS.
> But any company that has the resources to track you and cares enough to get you to install an app, also has the resources to make one.
It's not about tracking, it's about every single site on the web popping yet another annoying prompt nobody wants. That's already awful. Most of the native-app installation ones are spammy crap as it is. 99+% of the PWA prompts would be, and they'd be everywhere.
> > Battery life and performance. Except for the ones that shouldn't be apps of any kind
> Opinion me, most applications (calendars, email, text editors) are just interactive documents. People have this clear line in their head of the difference between an app and a website, but my alarm clock is not special in the way that Blender is. My alarm clock is an interactive document, it could be a PWA and it wouldn't be a problem at all for my battery life.
In theory webtech can make semi-reasonably-slim "apps" for things like this.
In practice—input latency, rendering performance, memory use, idle processor use, load time, and battery life, are between noticeably and hilariously worse in practically every case.
I'm also a little confused about the alarm clock thing. My phone just... has an alarm clock. As a built-in native app. My Android phones did too, back when I was on Android, though they were disturbingly unreliable (as were the ones on my wife's phones, before I got her to switch)—is that the motivation for the focus on needing 3rd party alarm clock apps? As far as ability to set timers at the system level, sure, a PWA should probably be able to do that, I guess (a web site 1,000% should not). Like, at this point I'd consider a phone without a quite-good built in alarm clock simply defective.
And this, I cannot relate to:
> My notetaking app on my phone is an interactive document. It thinks it is an app, but it's not -- it's an interactive document that has been made into a native app because it doesn't have reliable offline storage otherwise.
My note taking app's... not what you're describing. It's an app. Is has lots of features that an "interactive document" wouldn't, unless that term's so broad that it's just a synonym for "computer program". It also performs a ton better than web note-taking "apps" I've tried, which is part of why I use it instead of a web-based option—that and the features, stability, and lack of jank. Hell, it performs better than most featureful document-editing apps I'm aware of period (unless you dig back into pretty distant computing history), and certainly any webtech-based ones, even if it were in fact just a shell for manipulating an "interactive document"—even if that's true, yes, I absolutely want an "app" for that.
> My contention around mobile devices for a while has been that a lot of websites don't need to transmit data off of my device at all, and it would be better for everyone if they didn't have a backend. Whether that makes them a website or app, I don't know, that's semantics to me. Regardless, the point stands that they should have capabilities available to them (alarms, scheduled notifications, pin-to-homescreen, caching resources) that allow them to be used offline.
As far as this goes, it's worth noting that native apps on iOS have some important privacy-preserving restrictions that I doubt they'll be able to replicate for PWAs, because they're review-enforced, not enforced (because, not enforceable) by sandboxing or other automated measures. Fingerprinting the device? Prohibited for apps (long prohibited—that goes way back). Basically impossible to enforce without review, though, unless you cut access to features and hardware down to almost nothing (ahem). The cross-app tracking, the prohibition of which has (so very delightfully) made Facebook extremely upset? Unenforceable without review. For that reason I'm pretty leery of giving the Web platform any more space to move around in and spy on me than it's already got, and that includes further hardware or OS-feature access. This situation may differ on Android, where it may indeed be the case that apps are unequivocally worse for privacy than websites/webapps—it is, at a minimum, not so clear this is the case on iOS.
> Well, a lot of sites that probably would spam an app if they had one, don't, because they don't have one, for one thing.
This is my contention; the apps that want to spam you about this have resources to build apps. The people who don't are the people you see complaining on HN -- they're not companies.
> It's not about tracking, it's about every single site on the web popping yet another annoying prompt nobody wants.
Then I don't get the problem, because this only applies to PWAs you install. If you're worried about prompts asking you to install a PWA, then... that also is a UX problem, it has nothing to do with capabilities. Both Android and iOS I believe include mechanisms to block websites from over-spamming about PWA installation. The mechanisms could be better, but that's down to the fact that both Android and iOS have kind of a bad starting model for how permissions should work; apps shouldn't really be able to ask for anything without user prompting.
----
> In practice—input latency, rendering performance, memory use, idle processor use, load time, and battery life, are between noticeably and hilariously worse in practically every case.
If you say so? My feeling is that most overhead for most apps is the result of background logic. I'm not sure that how quickly you can render a DOM list matters much for battery life on average. Which is part of why background scheduling is so important, so you can get stuff to stop running in the background.
I'll also point out that most of the native apps on most people's iPhones include webviews already; they're good enough performance to use natively. Yes there are apps where you might really care about this, yes there are apps that I don't want running in a webview. But again, think of some examples here. Is it really a problem for you that Wordle isn't a native app? Do you think that's impacting your battery to any noticeable degree? Do you boot up Wordle and get frustrated by the input latency?
I don't know that I would use a webapp to replace Emacs (although I'll point out that Emacs also suffers quite a lot of latency problems because of its threading/rendering model and because of how it handles syntax highlighting, so I'm not sure it is actually competitive with web performance). But the point is, that's an environment where I'm doing programming on a keyboard. For a notetaking app on a phone? Is keyboard latency even going to be noticeable to you if you're using a swipe keyboard that sends input word-by-word?
----
> I'm also a little confused about the alarm clock thing. My phone just... has an alarm clock.
Maybe iOS's native alarm is better, but the native alarm clock on Android is significantly less powerful than I would like. It lacks the ability to:
- Schedule alarms more than a week in advance (no, I don't want to use a calendar for that)
- Delete alarms immediately after they go off
- Snooze alarms for variable rates of time per-alarm (there's just a global setting)
- Select music/sounds randomly from a list (very helpful for ADHD, consistent sounds get filtered out, so I have to constantly vary what my alarms sound like).
- And a couple of other things, including the ability to easily export/import alarms, etc...
Again, maybe iOS is a lot more powerful in that regard, I don't know.
----
> The cross-app tracking, the prohibition of which has (so very delightfully) made Facebook extremely upset? Unenforceable without review.
It's funny you bring this up, because this is absolutely enforceable in a browser and is already enforced in Safari. Firefox also has fantastic support for domain separation (Chrome as usual is the exception). Facebook was upset that Apple was bringing the native app up to vaguely similar standards to what Safari already has.
Seriously, the reason why Facebook tries to get you to install a native app is because native apps are easier to track and insert advertising into. If the web was easier to track, Facebook would offer you a PWA. I don't understand where people get this idea that the web is easier to track than native, I don't think that's ever been the case at any point, including on iOS. The best argument I can make on this is that making PWAs impossible to use on iOS means that Apple can personally vet all of the code that runs on your device, and that's just not a good security model. It doesn't scale well, as much as Apple would like to say that it does.
Yes, Apple can't manually go after web apps that fingerprint you (well, they could, it just would be very obviously tempting antitrust attacks). But even so, I want to make this very clear -- even if you are on iOS, do not install Facebook. Don't install Twitter. Use their mobile website through iOS Safari. And install an adblocker; I don't think Safari's adblocker API is powerful enough to block ads/trackers on Facebook in specific, but it will work on a number of other webapps that you use.
And bonus points, when apps are annoying you on the web, you can do something about it. You can intercept and block/modify app behavior. Sites like Facebook will make that hard, but... I mean ostensibly you're worried about spam from ordinary sites, and anti-annoyance blocklists work fine on them.
Look, I like the privacy stuff that iOS is doing. I like that notifications here require you to install the PWA, that's a good decision. And I love that iOS is adding more permission structures; better file portals are great, more app separation is great, I love the work they're doing around permission prompts. But iOS is catching up to where the web is, it is not surpassing it. The web is a terrible minefield of tracking, and native ecosystems are worse, and iOS is now very notably and very impressively catching up to where the web is. But if you think a company wants to track you (Twitter/Facebook/whatever) even if you're on iOS, you should not treat the native app as safer than the website.
I agree, every random site will almost certainly be vying for notification screen space via PWA install, which will make these banners practically omnipresent on the commercial web.
It wouldn't surprise me if the trend we've been seeing in iOS where notifications are deprioritized continues in iOS 17, including some kind of mechanism that deprioritizes notifications from the spammiest apps and sites unless the user has explicitly marked them as important.
Uuuuugh the last thing I want is notifications becoming like email, where it's so spammy and impossible to deal with that automated tools have to start categorizing spam and affecting message visibility, and then important messages start to get lost in the shuffle.
That seems like the unfortunate but inevitable outcome of any unregulated channel between devs and users once it's passed a certain popularity threshold. Time to move on from push notifications to whatever the next thing is to enjoy a decent signal:noise ratio there for the 2-3 years before it catches on with the masses.
