3 ms·

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 b

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.

danShumway 4y ago
> 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.
- yamtaddle 4y ago
  > 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.

danShumway 4y ago

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

yamtaddle 4y ago
> 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.