[HN Gopher] Web Push for Web Apps on iOS and iPadOS
___________________________________________________________________
Web Push for Web Apps on iOS and iPadOS
Author : tech234a
Score : 383 points
Date : 2023-02-16 18:36 UTC (4 hours ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| diebeforei485 wrote:
| What are the anti-abuse features built into this? Can Apple
| disable push notifications if the website gets hacked and is
| actively stealing people's info?
| Etheryte wrote:
| On iOS you get asked the first time an app tries to show you
| notifications and it's very easy to disable them after the fact
| too. Since PWAs are just apps you add to your homescreen
| nothing will change in this regard.
|
| As an aside, how would a notification steal your info?
| arepublicadoceu wrote:
| > As an aside, how would a notification steal your info?
|
| How about:
|
| "Hey dear user you won {amount} of money please click here
| and fill this totally safe form"
|
| This was me thinking for a solid 3 seconds, imagine if
| someone put some effort into the message.
| Etheryte wrote:
| This is not a threat model that's unique to PWAs though,
| nor in any way enabled by what's seen here. Installing a
| PWA is practically equivalent to installing an app and a
| malicious app or an app that had their OneSignal or similar
| credentials compromised could do the exact same thing.
| cuttysnark wrote:
| > Can Apple disable push notifications if the website [] and is
| actively []
|
| No, and previously you could add a hacked website to your
| homescreen and Apple couldn't stop you from doing so. Not
| speaking for the other features, but the webpush api provides
| no mechanism to steal info as much as it provides a way to
| alert a user who previously installed the app and allowed
| notifications that the app is sending them a notification.
|
| Now, if _after_ the user installing and allowing, the site gets
| "hacked", the hacked site operator could send push
| notifications that invite the user to interact with the
| compromised web site/app. Apple has no recourse; the pressure
| would have to be applied to the hosting service to shut down
| the site. That's a tall order for your average web user.
| dhalwani wrote:
| Any demos of these capabilities on GitHub ?
| bradeeoh wrote:
| The goal was to make it so sites that already support standards
| based Web Push work out of the box.
|
| We'd expect most sites that support standalone mode when added
| to the Home Screen _and_ support Web Push to Just Work(tm)
|
| 3 real world examples are lichess.org for Chess fans, elk.zone
| for Mastodon fans, and twitter.com for those that still
| actively use Twitter.
| [deleted]
| jakear wrote:
| If you're comfortable with a little `npm i && node server.js`:
| https://github.com/JacksonKearl/push-simple. This is based on
| Mozilla's example here, with some modifications to make it work
| standalone (and ask for permissions on-user-interaction, else
| it gets blocked by the browser):
| https://github.com/mdn/serviceworker-cookbook
| toastal wrote:
| But please no demos from other code forges, blogs, the spec, or
| the web in general? Code exists everywhere. Git is
| _distributed_ version control--not centralizing code a feature.
| You didn 't need to specify a specific place.
| jakear wrote:
| Strongest plausible interpretation doctrine would have you
| read this as "any git-accessible self contained minimal
| samples available"?
| slugiscool99 wrote:
| Kudos to Apple for doing this. It's honestly very cool of them
| metayrnc wrote:
| I think this is a good step. However, there is still many things
| that Apple can implement easily to show that they care about Web
| Apps. One simple example is that you cannot lock the rotation of
| a Web App like a regular app. There is plenty of stuff like this
| that would make Web Apps feel native. I hope they improve upon
| these things.
| Sheepsteak wrote:
| I think they've added this too. At the bottom it says they're
| adding the ScreenOrientation API and it seems to be able to do
| this.
|
| https://developer.mozilla.org/en-US/docs/Web/API/ScreenOrien...
| danShumway wrote:
| Oh hey, bullying companies with threats of antitrust works. We
| should do that more often.
|
| ----
|
| This is a really big deal, but it's also a little bittersweet,
| because Push Notifications very heavily motivate developers to
| introduce serverside components to apps that don't need them. Web
| Push is a standard where I can really see Google's influence, and
| I think it influenced the standard for the worse. It's a standard
| built around the way that Google and large companies build
| products, it's not built around indie development or hobby
| projects.
|
| You can send a notification to whatever server is registered and
| it gets delivered to the phone, great. In contrast, there is no
| way for a PWA (unless something has changed since I last looked,
| in which case _PLEASE_ tell me) to schedule a notification for
| the future without contacting a server. It 's a bad direction to
| go for PWAs, given that the whole point is for them to be able to
| work offline.
|
| And yes, sometimes you do need a serverside connection for things
| like message notifications, but there are a lot of uses for
| notifications where you know upfront what the notification needs
| to say and when it needs to be shown -- and that's not supported.
| In my opinion because Google doesn't really think about that kind
| of architecture and the idea that you wouldn't contact a server
| alongside every user action is foreign to them.
|
| There was effort for a while to get offline alarms, scheduled
| notifications, even scheduled actions working through web
| workers, but as far as I know that stuff has all died off. It
| stinks, because I regularly run into scenarios where I could
| probably flat-out replace an app on my phone with a website, and
| I can't even on Android, because I'm unwilling to set up an
| account system and start tracking a bunch of data. I'm happy we
| have something, but I'm still remembering the parallel world we
| lost, where it would have been possible to have a much broader
| push towards completely offline PWAs that never transmitted user
| data anywhere. The idea of being able to replace native apps with
| a static Netlify page is very appealing to me.
|
| And maybe that'll change? But I'm not holding my breath; it seems
| like a lot of companies have decided that push notifications are
| good enough and that they were going to require user accounts
| anyway.
| miohtama wrote:
| I was curious about this and looks like you can do
| notifications with Web Workers, based on this Mozilla post
|
| https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
| danShumway wrote:
| Unfortunately, not schedulable as far as I know, the
| notification needs to be sent while the web worker is
| running. Again, I'd very much love be wrong about that, but I
| don't think there is any way for, just as an example, a habit
| tracking PWA to say "ask the user at 10:00AM every day if
| they've gone for a morning bike ride."
|
| But you can get that behavior... if you set a web server and
| force the user to make an account and then log all of their
| habits in your server and then send out the notification
| yourself. Because... it's unfair for me to blame Google in
| this instance, I don't know it's their fault, but I do blame
| Google and I suspect it's their fault. I could be wrong
| though.
| xfalcox wrote:
| > In contrast, there is no way for a PWA (unless something has
| changed since I last looked, in which case PLEASE* tell me) to
| schedule a notification for the future without contacting a
| server. It's a bad direction to go for PWAs, given that the
| whole point is for them to be able to work offline.
|
| Looks like this effort died because of Android:
| https://bugs.chromium.org/p/chromium/issues/detail?id=891339
| danShumway wrote:
| Yeah, that was my impression as well. Every once and a while
| I check back to see if it's been picked up.
|
| I really think Google made the Web Push standard worse, in
| multiple ways.
| supermatt wrote:
| > Since the first iPhone, users could add any website to their
| Home Screen
|
| And ever since Apple have actively tried to destroy the
| advancement of local web apps.
|
| Now the writing is on the wall with regulation of their App Store
| they are finally pretending to embrace PWAs.
| [deleted]
| aeharding wrote:
| Wow, it's actually happening! Providing the notifications API
| behind "add to home screen" is exactly what I've been hoping for.
|
| https://news.ycombinator.com/item?id=33816700
| abxytg wrote:
| there is no good reason to have notifications on the web. its
| just for ads.
| EMIRELADERO wrote:
| Time to repost my comment from a past thread:
|
| I don't know anything about WebKit development processes or
| community management, so please forgive me if I say something
| wrong. Isn't it interesting how the engine has been implementing
| new features and generally running on a lot of steam
| coincidentally since the EU's Digital Markets Act (which will
| force other web engines on iOS) went into effect?
|
| Or maybe the dev process and community interactions has always
| been like this, in which case disregard what I just said and feel
| free to correct me.
| [deleted]
| pvg wrote:
| It's almost certainly not time for that:
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
| LeanderK wrote:
| I have been waiting for this for years! Now the only thing that's
| really missing is an install prompt. I wonder how long we have to
| wait, the install prompt is crucial, but I view Apples reluctance
| to implement the install prompt as politically driven. They want
| to favour their AppStore and make installing Web Apps
| unnecessarily hard.
|
| Edit: It's been three years since I have last dabbled with PWAs.
| What has been the recent experience?
| xfalcox wrote:
| It's been great. Web Share, Web Share Target, Notification
| Inline replies, Contacts API, are useful in the app I work on.
| SllX wrote:
| One other thing is necessary too, but this is iOS specific: I
| need a way to dump these to my App Library off my Home Screen.
| I searched out a few PWAs to see what the current experience is
| like, and even if I wanted to keep any of these around, I don't
| want them on my Home Screen per se.
| jaywalk wrote:
| You can put them on a hidden home screen. It's a pain, but
| it's the only way to keep the app but not have it on your
| home screen.
| SllX wrote:
| I had a response typed out, but I think I'm missing
| something. What is a hidden Home Screen on an iPhone? I
| have a one page Home Screen, after that it's the App
| Library.
| coder543 wrote:
| If you add a second page of apps, go into jiggle mode,
| tap the page indicator dots at the bottom to enter the
| overview mode, then uncheck a Home Screen. It will still
| exist, but it will be hidden.
| WorldMaker wrote:
| Focus Modes can also hide/show different Home Screens
| depending on Focus Mode, which is also one of the handy
| reasons to use Focus Modes.
| SllX wrote:
| Okay I'm really glad I asked because I did not know about
| that feature at all, and it does the job even if in an
| awkward way (adding a second PWA creates a third page
| when the second one is hidden). The PWA I was using to
| test iOS/PWA interactions now shows up in the App Library
| and Spotlight among the app results.
|
| It's not great, but as compromises go this one is
| basically reasonable, though Apple should still just let
| me dump them straight to the App Library. Thanks!
| wartijn_ wrote:
| You can have multiple home screens (you've got 2 or 3 on
| a fresh installation). If you drag an icon to the right
| you'll see that you'll get an extra screen.
| SllX wrote:
| Hi, thanks! I know this and thought this is what was
| being referred to too, but coder543 had the real answer
| up above and it's pretty good. You should check it out.
| wartijn_ wrote:
| Ah, I didn't know about that. Interesting.
| Turing_Machine wrote:
| > I view Apples reluctance to implement the install prompt as
| politically driven
|
| I agree. See also: the way you can't directly open an HTML
| document from Files (you essentially get a blank screen, even
| if all the JS and CSS is located in the HTML file).
| yamtaddle wrote:
| Ugh, no. It's bad enough they can pop "THIS SITE IS BETTER IN
| THE APP" shit. The last thing we need are more ways for a site
| to shove things in front of me to make my day worse.
|
| Keep it user-driven.
| saurik wrote:
| OK, then the mechanism that let's websites prompts to install
| apps should be removed so apps are on the same level as web
| apps. Otherwise, the situation is part of the anti-
| competitive lock-in. If that won't be removed--and we know it
| won't be--then this feature needs to be added _and will not
| make the situation worse_ : it will just mean that there is a
| hope that some of these websites prompt you to install a
| website instead of an app. If you want to stop getting
| prompted to install anything at all, then you need to either
| remove support for push notifications from apps--which
| obviously will never happen--or add support for push
| notifications to random "uninstalled" websites. (And if you
| don't like being prompted to activate push notifications for
| things, there should be a global switch to disable that
| feature... as they say: this isn't rocket science.)
| yamtaddle wrote:
| I'd love that, 90% of the ones I see are just from forum
| sites that use software that automatically provides some
| terrible "app" that no-one in their right mind would want,
| anyway.
|
| IIRC (and I may be mis-remembering) they mostly just added
| that in the first place because sites were hacking in their
| own (which, on its own, might be fine), and other sites
| were abusing that dynamic for phishing or otherwise scummy
| purposes (not fine), since there was no standard look &
| behavior for those prompts. As long as installing PWAs
| requires user initiation with actions in the browser
| chrome, and can't be initiated by a link in site content,
| that _shouldn 't_ be a problem with PWAs.
| coder543 wrote:
| > As long as installing PWAs requires user initiation
| with actions in the browser chrome, and can't be
| initiated by a link in site content, that shouldn't be a
| problem with PWAs.
|
| And that's all anyone is asking for, which would make
| PWAs equal to native apps in that regard.
|
| Your fervent opposition higher in the thread seems like a
| different position.
| yamtaddle wrote:
| I don't want INSTALL THE PWA spam-prompts everywhere.
| But, I like being able to open app store links from the
| browser. My ideal world is _not_ terribly friendly to
| PWAs. I might use them, but I _do not_ want them to be
| able to prompt installation actions in the browser. My
| persona UX is best if they cannot, but if "real" apps
| can. Second-best would be if neither can (and that's not
| _that much_ worse--I 'd be OK with this). Worst, by a
| long shot, is if both can.
|
| If both require "share -> install app" or "share ->
| install web app" (depending on what the site offers) that
| would be probably my single most-favored solution.
| Totally fine, both on equal footing. I _do not_ want PWAs
| to be able to trigger prompts or provide links that
| initiate PWA installation, even if native apps continue
| to be able to do so, "fairness" be damned (fairness, in
| this case, harms my UX because this functionality is
| _guaranteed_ to be spammy--the "install the native app"
| prompts are already spammy enough, I don't need more of
| that). That would definitely make the mobile web even
| worse than it already is.
|
| What I'm opposed to is letting PWAs prompt for
| installation. That would be bad, no question. Removing
| native apps' ability to do so is fine too, IMO, but would
| also require removing the ability to link to the app
| store _at all_ to not open up other potential issues. If
| that 's the cost of keeping PWAs from being able to
| prompt, cool, go for it. But please no PWA "click to
| install" prompts. No no no.
| coder543 wrote:
| To be clear, this is all we're talking about: https://dev
| eloper.apple.com/documentation/webkit/promoting_a...
|
| There is no shouting in these Smart App Banners. The
| entire user-visible experience is _completely_ controlled
| by Apple. It is just a passive bar at the top of a
| webpage that informs the user of the option, which they
| can dismiss. It isn't jumping up and down, it isn't
| playing loud sound files at the user screaming at them to
| click it.
|
| What really sucks is when websites like New Reddit
| provide their own custom modal prompts that cover the
| webpage and push you to the app, and they're extremely
| hard to dismiss and oftentimes these half-baked
| implementations are broken even if you accept their
| suggestion to open the app. _That type of prompt is not
| relevant to this discussion, at all._ They can do that no
| matter what you think and no matter what Apple
| implements. The way you have been talking about these
| things makes me believe you think those prompts were what
| is under discussion. They're _not._ Smart App Banners are
| not shouting "INSTALL THE APP!"
|
| I'm personally surprised that Apple doesn't offer a
| setting for Safari to disable Smart App Banners, which
| would be a simple way to stop annoying the few users who
| are bothered by them. I see at least one safari extension
| which claims to do this, but since this passive banner is
| extremely unobtrusive, why bother?
|
| I'm immensely bothered by all sorts of ads and anti-
| features, but just knowing if there is an app is a
| legitimately useful thing, so this does not bother me.
| Even calling it a "prompt" is a stretch since it does not
| require any action to dismiss. It is a very light "call
| to action", of course. If I'm browsing a website I don't
| care about and they use this feature, I can ignore it or
| hide it. It doesn't get in the way. I'm fairly certain
| you can even scroll down and the Smart App Banner will
| automatically scroll off the top of the screen, resizing
| the website to fill the entire screen.
| Someone wrote:
| > OK, then the mechanism that let's websites prompts to
| install apps should be removed so apps are on the same
| level as web apps.
|
| AFAIK, such prompts are regular HTML with links to the
| AppStore. If so, how do you suggest Apple make it
| impossible to add those to a site?
| l72 wrote:
| It's actually tied to meta tags and the manifest.json. If
| you have the correct tags, Safari automatically shows the
| prompt if you don't have the app installed or the open
| with button to open in the already installed application.
|
| For Chrome (desktop or mobile), if you have similar
| attributes in your manifest.json, then Chrome will show
| the 'Install' button to install the webapp to your home
| screen.
| rablackburn wrote:
| For PWAs you could simply not expose a hook to the
| developer that initiates the install process? It would be
| like if App Store pages didn't have URLs. Have the
| install functionality added to the browser UI instead.
|
| If PWAs weren't arbitrarily restricted there'd be no
| reason to link to the app store because...you're already
| in the app.
|
| Spamming users to hit the install button would be like
| spamming users to bookmark your website. That doesn't
| seem to be a problem (though that's probably because
| people don't keep their bookmarks on their home screen)
| coder543 wrote:
| > AFAIK, such prompts are regular HTML with links to the
| AppStore.
|
| The ones under discussion are not: https://developer.appl
| e.com/documentation/webkit/promoting_a...
|
| Apple controls the experience. The developer just tells
| Apple which AppID is connected to this website, and Apple
| chooses how to present this information.
|
| Smart App Banners also react to whether the app is
| currently installed or not, which random websites
| obviously should not be able to determine for privacy
| reasons.
| lxgr wrote:
| I mean, given that we already have "GO GET OUR APP NOW OR
| ELSE" prompts, would PWA prompts make things any worse?
|
| And very often I'd actually prefer a PWA, e.g. if I know that
| I'll be using a given site/service exactly once. Common
| example: A flight or train ride with a carrier I know I won't
| be using again anytime soon, but still would like to get
| notifications relevant to my trip.
| yamtaddle wrote:
| 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.
| danShumway wrote:
| > 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._
| yamtaddle wrote:
| 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 wrote:
| > 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 wrote:
| > 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.
| kitsunesoba wrote:
| 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.
| yamtaddle wrote:
| 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.
| kitsunesoba wrote:
| 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.
| hn_throwaway_99 wrote:
| What do you mean by the "install prompt"? (Sorry if this
| obvious, not an iOS user).
|
| I thought it was fairly straightforward to add an "add to home
| screen" overlay to a webpage with javascript.
| coder543 wrote:
| > I thought it was fairly straightforward to add an "add to
| home screen" overlay to a webpage with javascript.
|
| On Android, yes. On iOS, users have to click "share" and "add
| to Home Screen", which practically nobody knows how to do,
| and it presents the user with a rather confusing prompt for
| them to choose the name of the PWA they're about to install.
| The website could tell you to do that, of course, but then it
| only works in safari at the moment, and it is very clunky.
|
| iOS allows websites to show a banner that will help them
| install the equivalent app from the App Store, but there is
| no similar functionality for PWAs.
|
| Some people speculate that Apple relies on the PWA install
| process being confusing to help push developers into the App
| Store.
| WorldMaker wrote:
| Rather than a separate PWA "Add to Home" prompt, it would be
| nice if they added simple PWA support to the App Store
| directly. Microsoft's app store supports developers just
| dropping a URL to their web app manifest as pretty much the
| only thing needed to add a listing to the Store. (It also
| supports providing previous package IDs to migrate older apps
| to PWAs. Microsoft's Bing crawler will also sometimes pick up
| web app manifests and add basic listings in the app store when
| the manifest has enough information to do so.) Android app
| stores are in various stages of supporting similar things.
|
| It would great if Apple similarly supported PWAs as first-class
| citizens in the App Store. It would also make a lot of sense:
| it would still favor the App Store as the "primary" or "best"
| way to install apps, and users would keep a lot of familiar
| experiences in choosing to "install" apps (much more familiar
| than Share > Add to Home, as other comments around here point
| out). Apple can even still try to curate the listings to keep
| them looking nice and staying informative (and whatever quality
| insurance checks they like to run). The users don't need to
| know or care that an "app" in the App Store is a PWA or not.
| Same with all the normal "Install Our App" and "Find this App
| in the App Store" links and prompts and modals (and "paywalls")
| those can/should all be the same experience whether the app
| itself is powered by Swift (or anything else) or powered by a
| PWA. Users that install PWAs via an App Store think they are
| still sommewhat locked into that app store's moat because they
| still think of that app as originating from that App Store.
| It's something of a win-win for Apple, I feel.
|
| Not as a replacement for a general option like Share > Add to
| Home, because there will always be PWAs with no interest in
| submitting things to App Stores (and users will always want
| nice home screen bookmarks even for non-PWAs), but as a way to
| unify the install experiences for PWAs that do care about
| install metrics and app-like branding the best thing Apple
| could do (both for users and themselves) would likely be to
| allow developers to just submit their web app manifest URLs as
| the only "application code" in an App Store listing.
| cientifico wrote:
| My experience is similar.
|
| While Apple don't invest in PWA, PWA is doomed from a
| commercial point of view.
|
| It is a really sad situation because the user experience of PWA
| is match better than installing apps from the store (with
| higher install rate than native).
|
| Twitter is (or was) one of those examples. It took months until
| I realize that I was using a PWA than a native app.
| yamtaddle wrote:
| > the user experience of PWA is match better than installing
| apps from the store (with higher install rate than native).
|
| People have A/B tested "click this app store link to install"
| and "click this to install this webpage as a web-app" and
| found the latter gets more installs?
| bobthepanda wrote:
| That's not really surprising. More clicks = more friction =
| more people not making it to the end.
| yamtaddle wrote:
| Is installing a PWA one tap instead of two (it's two, for
| iOS native apps), on Android?
| kelthuzad wrote:
| Why do you think PWAs are doomed? Is it because you suspect
| that Apple will continue to sabotage them regardless of
| likely fines by regulators?
| threeseed wrote:
| > Twitter is (or was) one of those examples. It took months
| until I realize that I was using a PWA than a native app.
|
| Something is very wrong if you can't tell the difference. The
| difference is night and day on iOS.
|
| PWA app has significantly lower responsiveness, constant mis-
| touches on buttons, loading screens for every click etc.
| hn_throwaway_99 wrote:
| > PWA app has significantly lower responsiveness, constant
| mis-touches on buttons, loading screens for every click
| etc.
|
| That's certainly not inherent to every PWA, e.g. there is
| no need to have a "loading screen for every click".
| nvrspyx wrote:
| Not to mention that the opposite is also true where a
| large number of "native" apps are really just wrapped up
| web apps and many suffer these same issues.
| yamtaddle wrote:
| Part of the reason I'm not more bothered by Apple making
| PWAs viable is that they've failed to crack down on apps
| that don't meet their performance standards, anyway,
| letting those apps get away with just being terrible-
| performing, non-native-feeling web-app wrappers. That
| whole class of trash-tier "app" may as well be a PWA, I
| guess.
|
| I'd rather they kick out every app with an unjustifiably-
| long launch time or with janky non-native behavior in
| places where it has no reason to be so, but since they're
| evidently not gonna do that, may as well have PWAs.
| bobthepanda wrote:
| Right.
|
| Ultimately, it's a business decision, because paying for
| 3x the people or 3x the time to implement one feature on
| web, iOS and android is not something that people like to
| do, let alone the headache of coordinating feature parity
| and release timeline with said teams.
| kitsunesoba wrote:
| The twitter web app is such a mess. Only slightly better
| than "new" Reddit, which is probably one of the single
| worst offenders in the world of bad SPAs.
| djbusby wrote:
| Are these WebKit improvement driven by the EU regs? Isn't that
| why iOS will soon allow an alternate rendering engine? So, now
| WebKit finally has to keep up?
| seanabrahams wrote:
| Dreams do come true
| (https://news.ycombinator.com/item?id=22687913). Even more:
|
| > You do not need to be a member of the Apple Developer Program
| to use it.
|
| Wow.
| Alifatisk wrote:
| That is incredible. I guess PWA is getting closer to success.
| cronix wrote:
| I'm pleasantly surprised by this news. I never thought Apple
| would do this and have been quite critical of them over the years
| due to it. For years they've really been holding up progress with
| PWA. I think a majority of the apps we see are really just
| glorified wrappers around websites anyway, or not needing more
| resources/tech than a website would, except bloated up to 100megs
| for each app because we can't just use the web browser already
| installed and all of the time and money wasted getting it into
| the app store when it should be just freely accessible via the
| web.
| cma wrote:
| Meta's PWA announcement was pretty shocking: they are going to
| take a 30% cut from PWAs and require they go through their
| Quest store.
| sublinear wrote:
| > should be just freely accessible via the web
|
| Yes this is a significant hammer blow against native apps on
| iOS, but I don't think this would reduce cost for the consumer.
| I might be misunderstanding what you mean by "freely
| accessible" though. Definitely is more convenient for the same
| web app to be available everywhere.
| nine_k wrote:
| Freely accessible as in not vetted by Apple. No approval
| process, no need to pay $100/year, no need to buy a Mac.
| (Also, gone would be the 30% Apple tax on "in-app" payments.)
| geysersam wrote:
| No need to maintain multiple versions of applications for
| different platforms.
| [deleted]
| ffritz wrote:
| Let's see if they still do want your $100 by requiring it
| for their Push Notifications API.
| yamtaddle wrote:
| You'll need an app-specific cryptographic key to connect
| to the push service, unless that's changed. And you'll
| need some system for registering and de-registering push
| tokens (unless that's also changed).
| [deleted]
| WastingMyTime89 wrote:
| > I'm pleasantly surprised by this news. I never thought Apple
| would do this and have been quite critical of them over the
| years due to it.
|
| The EU is forcing them to allow side loading so they are racing
| against the clock to try to bring WebKit to a point where
| everyone is not just going to switch to Chrome overnight when
| that happens.
| fabrice_d wrote:
| In general yes, but web push is kind of the exception there
| because this API needs OS level support to wake up apps.
| Switching to a blink based browser would not help with that.
| yoavm wrote:
| Why not? If you run Chrome (or Firefox) on iOS, can't the
| app ask for notification access using the normal OS API? It
| will then "lend" this functionality to websites, so that
| when they have an update you'll get a notification from
| Chrome saying "Website X: Hello world".
| yamtaddle wrote:
| That'd require a whole other push system operating on top
| of the normal iOS push system. Web app users would have
| to go through some Google-hosted push clearinghouse that
| wrapped some new format within the existing Apple push
| protocol, and it'd _only_ work for Chrome.
|
| [EDIT] Web app _developers_ , that is--users of the push
| system. And it means when end users have 20 sites sending
| them pushes that they don't want, they'd have to figure
| out how to disable them in Chrome's settings, rather than
| their normal system push settings. It'd be a total mess.
| jonny_eh wrote:
| > because we can't just use the web browser already installed
|
| True on Mac, not on iOS. Apple doesn't let you ship custom web
| renderers. You need to use the system's built-in one. This
| applies to browsers such as Chrome and Firefox too!
| throw03172019 wrote:
| I believe they are goi g to allow custom engines going
| forward.
|
| Source: https://www.macrumors.com/2023/02/07/mozilla-
| developing-non-...
| heygarrison wrote:
| This is awesome!
| least wrote:
| I'm already dumbfounded by the number of notifications I see pop
| up on relative's screens, this can only add to it. My default is
| to not allow notifications unless the application has a very good
| reason for needing it, and even then if they abuse that the
| notifications get turned back off.
|
| It's one of many moves Apple is making in what I'm assuming is to
| assuage antitrust concerns. I think it's an overall good because
| having choice is good, but I do suspect I'll start seeing even
| more spam on people's notifications as a result.
| tech234a wrote:
| It requires adding the app your Home Screen first.
| lxgr wrote:
| I completely agree about notification spam being an issue, but
| why should native apps get a head start over PWAs here?
|
| There are many native apps on my phone that abuse notifications
| for spamming (often by not having an option that disables
| marketing while keeping e.g. delivery notifications active,
| which means blocking everything is sometimes not an option),
| but at the same time, there are some websites where I'd really
| like getting notifications (and notifications are in fact the
| only reason I have their app installed!).
| thewebcount wrote:
| The difference is that Apple has rules about what can going
| into App notifications, and if developers don't follow the
| rules they can kick the app out of the App Store. (Not saying
| they couldn't be better about this, but it's at least an
| option even if it's not perfect.) But they'll have no control
| over what notifications from web pages you've put on your
| home screen show. It will make notifications a worse
| experience for users all around.
| jaywalk wrote:
| Apple doesn't even follow their own rules on this.
| KyeRussell wrote:
| Apple has rules surrounding using push notifications for
| marketing uses, yes. They haven't enforced them for a
| decade. Apple's own apps are guilty of blatant rule
| violations. Not to say that there's any expectation that
| Apple would follow their own rules. Rather that the company
| doesn't see the value in following them. So. In the
| hypothetical universe where they still cared, sure. But we
| aren't in that universe.
| lxgr wrote:
| Unfortunately, these rules primarily serve Apple, not me as
| a user.
| Turing_Machine wrote:
| > The difference is that Apple has rules about what can
| going into App notifications,
|
| They aren't very effective, then. I'd love to have a way to
| let (e.g.) food delivery apps tell me when my food is
| arriving, without letting them spam me 30 times a week with
| "special offers".
| ntauthority wrote:
| > But they'll have no control over what notifications from
| web pages you've put on your home screen show.
|
| They own the browser. They can theoretically maintain a
| list of bad origins just as much as they can block an app
| from the App Store.
| least wrote:
| > I completely agree about notification spam being an issue,
| but why should native apps get a head start over PWAs here?
|
| They shouldn't, which is why I think this is an overall
| positive change. It's mostly that when you add ways people
| can receive notifications, it can only increase the amount of
| notifications you can get, not reduce it, and notifications
| for most applications have at best dubious utility for the
| end user.
|
| Web apps are also not beholden to the app store rules, so I
| think they at least have slightly higher chance of being
| abused, not that the app store prevents companies like Uber
| from spamming you with advertisements and bundling them with
| delivery notifications, like you mentioned.
| om2 wrote:
| Good news! You'll only get notifications if you save a web app
| to your homscreen and then explicitly give it permission. And
| then you can choose to limit it to only badging, as with native
| iOS apps. Or you can use focus modes to manage which
| notifications you can get in different situations, as with
| native iOS apps. We've been careful to minimize the risk of
| notification overload as much as we can.
| least wrote:
| I'm glad that there's controls in place to help minimize the
| issue, but I also know that companies do a good job of making
| people think that they need to enable settings on their
| phones that they don't.
|
| That's of course not in Apple's control, it's just a
| meaningful downside to opening up push notifications to web
| apps on iOS. The utility for the few apps that can really
| benefit from this probably outweighs the downsides, but I've
| _seen_ other people 's phones and know it will also, and
| possibly mostly, only contribute to more spam.
| fundad wrote:
| they thought of everything huh?
| jacobp100 wrote:
| It's good to see this happen. It'll improve the perception of
| Safari for developers.
|
| It always was always treated pretty unfairly. It's easier to
| parrot 'Safari is the new IE' rather than consider cross
| compatibility when you're writing websites.
| awinter-py wrote:
| I recently imp'd web push for an internal admin tool, tested on
| android
|
| AFAICT it only works if chrome has been started recently, and you
| have to turn off background throttling for chrome maybe.
| (guessing this is _highly_ vendor, version, and device specific
| though). But it was fine for something I check daily anyway
|
| Python library support for sending this is present but shaky --
| guessing apple's endorsement will improve the ecosystem for this
|
| Not sure about consumer space, but for communicating with
| technical users who know you well, this is so much of an easier
| rollout process than an app -- literally 'hours vs months'
| comparison
| jeroenhd wrote:
| AFAIK notifications should come in as long as Chrome's daemon
| is running. This should run on boot, unless Chrome has been
| manually force killed, or if Chrome has crashed.
|
| It's possible extremely aggressive battery savers or extreme
| power saving modes will kill these services as well and require
| Chrome to start, but you shouldn't need to launch Chrome
| manually in most cases (or Firefox, or any other browser).
|
| There's simply no way to fix this restriction, not on the web
| nor on native apps.
| osrec wrote:
| I can't believe they've finally added this. Been waiting at least
| 8 years.
| jonny_eh wrote:
| Some of us have been waiting 15 years.
| computing wrote:
| some of us have been waiting for 29 years.
| alexklarjr wrote:
| [flagged]
| mvac wrote:
| Web Push is probably the worst feature ever introduced to the
| web. I see way too many spammy notififications on PC's of my non-
| technical friends and parents. Glad that Apple has decided to
| only allow Web Push for websites added to the home screen.
| msoad wrote:
| An important detail that you might miss without reading the
| article is that these capabilities are not available to any
| website a user visits. The user must add the website to the their
| Home Screen before the website can ask for notifications
| permissions.
|
| As an iOS user I actually like this restriction. Can't imagine
| what the browsing experience would've looked like if any website
| could take their chance on sending me notifications
| nvrspyx wrote:
| Now if only they'd create a separate folder for web apps in the
| App Library to put them in instead of _requiring_ that they be
| on the Home Screen.
| Someone wrote:
| You can get close: put them in a folder on your Home Screen.
|
| Disadvantages:
|
| - cannot hide that folder in the App Library
|
| - limited number of shortcuts per folder
| alwillis wrote:
| > Now if only they'd create a separate folder for web apps in
| the App Library to put them in instead of requiring that they
| be on the Home Screen.
|
| Could be a feature of iOS 17, which will be available to
| developers at WWDC in June.
| KyeRussell wrote:
| Yes, like it is every year. Shovelware blog tier
| speculation.
| thekingshorses wrote:
| And reinstall it like native apps on factory reset or
| transfer like native apps to a new device.
| duxup wrote:
| Yeah absolutely this has to be a limitation.
|
| I do not want to have to go chasing "where did this annoying
| notification come from" game... ever.
| wartijn_ wrote:
| Desktop browsers don't have this limitation and I never have
| to play that game. It's just a stetting where you can choose
| to allow websites to ask for notification permission, or
| block it from every website.
| waboremo wrote:
| Part of the problem for desktop browsers (except for power
| users) is that they've never opened the settings option,
| not once. They might have opened Mac's system preferences
| or Windows Settings app but other than that they have no
| idea they can toggle a plethora of options for their
| browser.
| duxup wrote:
| For you and me no problems.
|
| Other people I think it is an issue.
| kube-system wrote:
| Exactly, which is why things like this used to happen:
| https://i.stack.imgur.com/82hWm.jpg
| [deleted]
| yamtaddle wrote:
| Check in with the average user of desktop browsers. You may
| find a lot of them have accidentally accepted web pushes
| and have no idea how to make them go away.
|
| I'd be shocked if the vast majority of "use" of the
| "feature" weren't exactly that kind of spammy, unwanted
| messaging.
| KyeRussell wrote:
| It's certainly the majority of times I've been prompted
| to enable it for a website.
| dmonitor wrote:
| it's constantly abused by spam trying to masquerade as the
| browser because the prompt extends below the line of death
| taude wrote:
| I'd have expected no less, since Chrome already protects the
| notification noise by default, too. You have to opt in to
| notifications. Sounds like a slightly different implementation
| for iOS, which is interesting in that they're assuming any app
| you add to Home Screen means your opting in to the
| notifications, or is there another opt-in? I see myself putting
| a few apps on my home screen that I want to click on often, but
| maybe not wanting the notifications to go with it?
| mbreese wrote:
| _> Chrome already protects the notification noise by default_
|
| Does it though? I still get asked to opt-in for notifications
| on websites regularly, including those I've already said no
| to. A simple opt-in question still makes me answer the
| question routinely (with the default "Sites can ask to send
| notifications" setting).
|
| This puts a much higher bar on the notification opt-in game.
| taude wrote:
| I get asked, but once I say no, I haven't gotten prompted
| again.
|
| And if you accidentally click yes, it even has a section in
| the 'safety check' section that will have a list of sites
| sending you too many notifications.
|
| Also, there's another setting where you can toggle between:
| ask permission, block all; and some other silent blocking
| them....
|
| I wonder if it remembers my settings better because I have
| a google account that my chrome is logged into for syncing
| these things?
| barkerja wrote:
| _A web app that has been added to the Home Screen can request
| permission to receive push notifications as long as that
| request is in response to direct user interaction -- such as
| tapping on a 'subscribe' button provided by the web app. iOS
| or iPadOS will prompt the user to give the web app permission
| to send notifications. The user can then manage those
| permissions per web app in Notifications Settings -- just
| like any other app on iPhone and iPad._
| yamtaddle wrote:
| Oh thank god. I was worried it'd let sites ask without the user
| first taking some action to permit it. Sites being able to pop
| "allow notifications?" without the user first indicating they
| might want that, on desktop, is a menace.
| spandrew wrote:
| Ya. It's safe to assume if someone is opting to add a website
| to their homescreen they are interested in it; notifications
| may make sense. Random websites asking me to enable desktop
| notifications are annoying. This prevents that for mobile.
| hbn wrote:
| Good. Web push is such a mess. The amount of people with
| Android phones like my grandma that accepted push notifications
| on some spam site, either by accident or because users are so
| conditioned to just click "ok" to make popups go away, it's
| absurd.
| maicro wrote:
| FYI, you can disable the ability for Chromium-based browsers
| to even ask the user if they want to allow notifications - on
| my Android phone in Chrome, it's under Settings, Site
| settings. There you can set "Notifications" to "Blocked" (and
| if you're paranoid like me, turn most others off as well).
| starik36 wrote:
| I doubt his grandma would find this option.
| zakki wrote:
| I don't know if they'll accept this solution. The other
| camp just want: "It works automatically like magic". I just
| want to point out that we have to be familiar with the
| tools we used.
| mrtksn wrote:
| Very sensible limitation, otherwise we would just have another
| dialog to deny or accept on every website.
| pier25 wrote:
| It's a good restriction although I wish Apple helped a bit with
| the installation of web apps to the home screen.
|
| Not install prompt banners like in Android* but right now you
| have to use the Share screen. It almost feels like Apple is
| hiding that functionality so that users don't find it.
| Installing and sharing are two very different actions.
|
| * I'm an android user and I agree these are bad.
| throwanem wrote:
| "Share sheet" is a bit historical in my opinion, and has been
| for some time. In practice it serves as more of an OS-level
| context menu that happens to put the "send to frequent
| contacts" and "open in another app" options first.
|
| In theory Safari's tab context menu would be a better fit,
| but given it iconifies as a "change text size" tool, I don't
| know if that would really address your concern at all.
| Gigachad wrote:
| For people who haven't used iOS, the Share screen is the ios
| junk draw where every option they couldn't find a better
| place to put something goes. Things like Find on page are
| located there too.
| banashark wrote:
| This is great for the progress of PWAs
| dariosalvi78 wrote:
| great, now give me web bluetooth and I'll never develop an app
| ever again...
| jeroenhd wrote:
| Native Chrome is coming to iOS. Soon enough you'll be able to
| show users screens like "your browser is not supported, upgrade
| to iOS 16 and download Chrome" if you want to use Chrome
| exclusive features like those.
| Alifatisk wrote:
| This is shocking
| fleddr wrote:
| No work webkit does on PWA-like features matter for as long as
| the install journey is as intentionally user-hostile and non-
| discoverable as it currently is.
|
| For the record, on Android it's also shitty, but not this shitty.
| [deleted]
| CBarkleyU wrote:
| A bit off topic, but worth a shot: I'm working on a rather simple
| web-based game and I'm struggling with how to test it for
| iOS/Safari/Webkit without having to go out and buy an Apple
| device?
| aeharding wrote:
| Browserstack. Free for FOSS
| Sammi wrote:
| https://www.browserstack.com/
|
| Not afiliated.
| jeroenhd wrote:
| You can rent virtual/remote iOS devices. Those are the only
| realistic alternative I know of and you'll probably need to
| expose your dev server to the internet somehow for it to work.
|
| There are also open source webkit builds like GNOME Web (though
| they're quite different from Safari in many ways).
| mirkodrummer wrote:
| Finally! Can't be more excited if not that it's super hard for
| the common user to add web apps to their homescreen. I'm against
| an install prompt api, the web is already a shit show of banners,
| like other commenters pointed out. But something like a little
| badge on the address bar that once tapped tells you the web app
| is installable would be great imo
| cal85 wrote:
| Unless I've misunderstood, this a quite a big event in the
| history of the web platform. Apple's quiet refusal to support
| this part of the PWA standard has for years been quietly
| maintaining a significant situation: that if you wanted to make a
| viable digital product that involved notifications, you basically
| had no choice but to make a dedicated iOS app, along with either
| a PWA or an Android app. If iOS Safari fully supports PWA
| notifications, with no funny business, that is no longer the
| case. Suddenly it is viable to make a single version of your app
| for every phone.
|
| This also has big implications for the hegemony of the App Store
| and Apple's control over the web platform. I don't fully
| understand why they are finally giving up this power they have
| held onto for about 8 years, but I'm glad they are.
| [deleted]
| scarface74 wrote:
| It came out in the Epic Trial that 80% of all app store revenue
| comes from games and in app purchases.
|
| The difference that web push notifications will make is
| infinitesimal.
| threeseed wrote:
| > This also has big implications for the hegemony of the App
| Store and Apple's control over the web platform
|
| No it doesn't. It will make zero difference.
|
| Because developers have been building web based mobile apps for
| nearly 15 years now. And they never took off not because it
| lacks push notifications or some other minor feature. It's
| because the end user experience is terrible.
|
| And I've yet to see anything that addresses the difference is
| latency, responsiveness, feeling etc that you get between
| native and web apps.
| trevcanhuman wrote:
| > No it doesn't. It will make zero difference
|
| I'm pretty sure it does, at least with purchases. PWAs won't
| need to pay for apple's app store 30% cut.
| kristiandupont wrote:
| I don't know what the percentage of "native" apps that are
| really web views and/or javascript underneath, but am certain
| that it's a lot. In fact, I wouldn't be surprised if it's
| more than 50%.
| phreack wrote:
| I once made a chat app that had significant traction on
| Android, and many users wanted to try it on iPhone but there
| was no way to do so without web push, and it was
| fundamentally banned by the app store guidelines and without
| side load there were no alternatives. This is a game changer
| for those kinds of apps!
| joenathanone wrote:
| I build a PWA currently in use by around 130 people, no one
| can tell its not native.
| threeseed wrote:
| I assume you have a native app as well and have benchmarked
| both with users.
|
| Because when you compare native/PWA with mainstream apps
| the experience is significant.
| jasonlotito wrote:
| > I assume you have a native app as well and have
| benchmarked both with users.
|
| Yes, I can speak for them. They compared their native
| implementation with the one that exists. The users enjoy
| using the web app compared to the current native app.
|
| Why? Because it doesn't exist. Because creating a native
| app doesn't solve the problem. Because when you say
| "native", do you mean iOS or Android? Or Mac? Or Windows?
| Or Linux? Or whatever else there is?
|
| Yes, eventually, there might be a desire to build out a
| native app if it's needed. But the assumption that
| everyone needs a native app is absurd. Not everything
| needs a native app, and can work just fine without.
|
| As for this persons users? Yes, they enjoy the PWA,
| because without it, the "native" app wouldn't work for
| some of them.
| threeseed wrote:
| If it's a choice between PWA and no app then of course
| PWA has a use.
|
| But if you think it will upend the industry then that is
| frankly delusional. PWA apps are worse than native in
| every single way for the user. Great for developers.
| Terrible for users.
| intrasight wrote:
| Developers trying to satisfy their users are not trying
| to upend the industry.
|
| And as users can't tell, why is it terrible for users?
| All kinds of apps can suck and be user unfriendly. That's
| a different dimension than native vs web.
| elforce002 wrote:
| This 100%. Amazon web app is awful. Same goes for any
| ecommerce pwa I've used on my phone.
| jstummbillig wrote:
| > And they never took off not because it lacks push
| notifications or some other minor feature.
|
| Actually, that is precisely why they didn't take off: Without
| push notifications a lot of mobile applications are simply
| not feasible. If something is not feasible, most people will
| have no reason to invest in ux. It's self-fulfilling.
|
| However, with push api, cache api, being installable (and
| maybe some additional apis that elude me right now), I don't
| see any specific thing that would not allow carefully crated
| web apps to have great ux on mobile.
| geysersam wrote:
| Yes absolutely. People will learn a new way of interacting
| with webapps. Currently nobody installs a pwa. But maybe
| that'll change. Going through the web browser is
| inconvenient for some apps (unnecessary extra menu on top).
| After installing however, the experience is very similar.
| threeseed wrote:
| Download the Twitter and PWA apps. Compare the two.
|
| If you think the only difference between them is push
| notifications and one click install then of course you will
| think PWA will be a success. But a lot of us can easily see
| the difference.
|
| And based on the last 15 years of real world experience
| there are enough users like us to sink the hopes of PWA
| apps.
| jstummbillig wrote:
| When you have a strong reason to not optimize one of two
| ways of building your mobile app, you are not going to
| optimize one of two ways of building your mobile app. Not
| having push notifications - for years on end, with no
| inkling if that might ever change, because the platform
| makers have strong reason to sabotage it - is a pretty
| strong reason, specially when your measure of success is
| literally how often users get distracted pulled into your
| app.
|
| In 2023 there is absolutely nothing that would
| technically not allow us to build a buttery smooth 90fps
| experience in any mobile browser running on a recent-ish
| phone. Of course that is not to say it's particularly
| easy. But then again, so isn't building a performant
| native app.
| scarface74 wrote:
| And what about the 80%+ of app revenue that are from games?
| laingc wrote:
| I am genuinely curious about this. I prefer native apps to
| web apps, but I have notifications disabled for every app I
| install except those that my wife and parents use to
| contact me. I'm sure I'm not alone in this behaviour - I
| hate notifications and any workflow model based around
| them.
|
| Is my viewpoint very uncommon? Are notifications generally
| used and loved by users? Do app developers have good stats
| about this?
| jstummbillig wrote:
| Thinking as a fellow notification disabler, and having no
| data, just intuition: People want their attention to be
| tapped. I am not exactly sure why that is (although I am
| sure that it can't be good) but notifications are a tap
| on peoples attention.
|
| Building certain apps without notifications seems like it
| would simply not be acceptable to must users. Most phone
| apps still vibrate or ring - that's basically a
| notification. I would go as far as saying its uniquely
| distracting notification is the primary feature of the
| phone app but, at the very least, a phone without one
| would be something very different. And since messengers
| basically compete with phone apps now, for most people
| that would probably not work.
| wsc981 wrote:
| Isn't there a push by some legislators in some countries for
| Apple to allow alternative app stores on iOS devices in the
| near future? That might have something to do with this perhaps
| ...
| freedomben wrote:
| Exactly, I think that's what this is about. either no need to
| allow sideloading cause PWAs, or it's an olive branch to
| iterate closer to prevent the big hammer from dropping. Also
| of course possible that Apple just supports it, but given
| then long history of evidence against that I don't consider
| it likely.
| stevenkkim wrote:
| Wow, I've been waiting for this for years and honestly thought it
| would never happen.
|
| Does anyone have any sense of how long it might take for this get
| out of beta and widely supported by iOS/iPadOS devices?
| zxcvbn4038 wrote:
| I think this is a good development. I'd rather my "app" be chunk
| of wasm running in a browser window then have to deal with all
| the drama that comes with dealing with the various app stores.
| Its not a universal solution but it would work for a lot of apps.
| Most of the non-game apps seem to be just a web widget anyway.
| tompetry wrote:
| With the (controversial) incentive for Apple to move away from
| PWA's and toward native apps, this has to be welcome news and
| useful for developers and consumers alike. Their fine balance
| between being anti-competitive and providing just enough tools to
| keep users from switching to Android continues.
|
| Their previously leaked internal debates about openness and
| iMessage for Android in particular is fascinating. Would love to
| see it on this topic.
| afavour wrote:
| There's a huge caveat here: it only works for webapps you've
| installed to your Home Screen, which is a Byzantine process few
| work out organically.
|
| It's progress, I'm happy to see it, but Apple are still behind
| the curve here. It should be much, much simpler to install an app
| to the Home Screen when huge features like this are locked behind
| the gate.
| olliej wrote:
| You mean random websites can't spam you with notification
| requests unless you've taken a step to indicate that it's a
| special app?
|
| I'm also curious how badging would work for non-home screen
| apps?
| buildbot wrote:
| Clicking the share icon and then add to home screen is
| byzantine?
| afavour wrote:
| Ask any average user how they'd go about installing a web
| site to their Home Screen and they'll just stare at you
| blankly.
|
| I guess Byzantine is the wrong word. It's not discoverable
| because no one knows what they're even looking for.
| monkin wrote:
| I think that more likely no one cares about this beside few
| tech-savvy users and they don't need a guide to do it.
| afavour wrote:
| I don't think anyone cares, no, because to them it's a
| meaningless technical distinction.
|
| They shouldn't have to care. I think they want to install
| an app. If it were equivalently easy to install a webapp
| vs native most users would be happy with either. But
| native is a two-tap process, web is a mess.
| intrasight wrote:
| PWA is also a two-tap process - and with less cognitive
| dissonance. No reading reviews, terms of service, privacy
| docs. No "onboarding" workflow.
| sedatk wrote:
| You lost the user at "Clicking the share icon".
| nine_k wrote:
| Is it harder than clicking on App Store icon?
|
| _Especially_ if you put a nice large animated instruction
| right on the web page.
| sedatk wrote:
| Yes, it's way harder because "share" is semantically
| incompatible with installing an app.
| [deleted]
| happytoexplain wrote:
| Absolutely, yes - and this is a great example of how out of
| touch most software-experienced people are with how
| stupendously confusing/non-discoverable most UI is for most
| users.
| boucher wrote:
| Byzantine is a bit much, but it's not particularly
| discoverable if you don't already know what you're looking
| for.
| lxgr wrote:
| It's completely non-discoverable!
|
| The only way to even find out if a website actually offers a
| PWA (assuming you know what that is, which is probably not
| true for >90% of users at this point) is to add it to your
| homescreen and then see if you get essentially just a
| bookmark, or an actual PWA.
| recuter wrote:
| If you offer a PWA can't you just have a wee css popup with
| a big arrow floating at the bottom of the screen pointing
| out exactly how to install it?
| jonny_eh wrote:
| Yes, I've seen sites do this, such as https://post.news
| afavour wrote:
| The instructions to install vary by device, OS version,
| etc. etc.
|
| It should just be equivalent to native apps. A link to an
| App Store URL takes the user directly to an install
| screen. It was clearly seen as enough of an issue that
| they implemented that, so there's no reason web apps
| can't be the same.
| recuter wrote:
| As far as I'm aware since iOS 1 the instructions have
| always just been "click share button => Add to home
| screen" on all of their devices.
| afavour wrote:
| If you think the bulk of users even know what "share
| icon" is you're kidding yourself. If you think they find
| that modal window intuitive you're kidding yourself. Even
| then, you're sharing... to the home screen? "Share to the
| Home Screen" is not the way anyone thinks about
| installing an app. The whole concept is a mess.
| [deleted]
| recuter wrote:
| I don't.. that's why I asked if a giant " click here"
| floating thingie might help. (HN strips them out:
| https://emojipedia.org/white-down-pointing-index-dark-
| skin-t...)
| afavour wrote:
| That's what I'm saying about device variation: that
| downward pointing arrow would be incorrect on an iPad
| because the share button is in the top right. Exactly how
| far from the right depends on OS version, whether the
| screen is portrait or landscape, whether you have a
| larger text size enabled in accessibility settings...
|
| And _all_ of this is ignoring the fact that Android also
| exists. Half the point of using the web is to be able to
| do stuff cross platform, once you start sniffing user
| agents and screen dimensions you're creating something
| doomed to fail in the long term.
| gempir wrote:
| Will they ever allow chrome or other browsers to add PWA Apps to
| your Homescreen? That's what's missing for me.
| teichmann wrote:
| It's mentioned in the article, see "Third-party browser support
| for Add to Home Screen".
| tomasf wrote:
| [dead]
| alberth wrote:
| > "A web app that has been added to the Home Screen can
| request..."
|
| Home Screen dependent.
|
| Just for clarity, sounds like this functionality only exists for
| web apps added to your Home Screen.
|
| (Which I think is fair, but just pointing this out since I don't
| know how common it is for people to add web apps to their Home
| Screen)
| bnt wrote:
| I strongly dislike this. My grandparents are on Android and they
| are driven mad by every site pushing them notifications, 24/7.
| We're talking about non-tech people, 70+ years old. I ended up
| turning off notifications for them altogether because I couldn't
| find a fix. On iOS this is easy, Safari won't have access to
| notifications on my phone.
| jefftk wrote:
| This is only for websites you intentionally add to your
| homescreen, though?
| smashed wrote:
| You have to add the web app to the home screen, then the app
| needs to ask permission on a click event, the user needs to
| grant the permission and then focus mode, etc can still filter
| them out.
|
| In many cases, you have a perfectly functional web app and the
| only feature you would gain from publishing a native mobile app
| would be push notifications. Apple used to gate this feature
| behind its app store/developer program. Now you have an
| alternative, and I think it was long overdue.
| lelandfe wrote:
| This is just for "Home Screen web apps", aka PWAs. No data for
| this one, but I'm comfortable saying grandparents largely do
| not install PWAs.
| hajile wrote:
| > Added support for WASM SIMD.
|
| This is huge for the progress of WASM
|
| > Added support for growable SharedArrayBuffer.
|
| Not a headliner feature, but a pretty important one for JS/WASM
| interactions.
|
| > Added support for AVIF on macOS Monterey and macOS Big Sur.
|
| > Added support for the AV1 codec in the MediaCapabilities API.
|
| > Added WebRTC support for hardware AV1 decoding on supported
| device configurations.
|
| Could this be the first indication of Apple warming to AV1?
|
| > Added support for the Notification API in dedicated workers.
|
| > Added support for Service Workers and Shared Workers to the
| Permissions API.
|
| > Added support for the termination of nested workers.
|
| Nice to see web workers finally getting some love
|
| > Added support for CSS Typed OM.
|
| A great feature and should help with performance from not having
| to do constant number->string->number
| fayazara wrote:
| Great addition.. I hope they soon add the install prompt and
| remove the stupid border dragging/pulling from safari.
| Maxburn wrote:
| Going to be great for web based podcast apps that do live
| broadcasts like Curiocaster; https://curiocaster.com
| tech234a wrote:
| It's great to see additional capabilities being added to Safari
| on iOS; the bottom of the article also mentions additions of the
| Screen Lock, Screen Orientation, User Activation and Web Codecs
| APIs.
|
| The idea of limiting some APIs to apps added to the Home Screen
| makes sense; I hope in the future web apps can use other features
| such as the Vibration, Bluetooth, Screen Capture, NFC, and Share
| Target APIs.
| sccxy wrote:
| Web Push is meh for me, but Screen Wake Lock and Screen
| Orientation APIs are super!
|
| I work with custom web map apps, so it is great that iOS is
| moving little bit closer to Android.
|
| PWA install prompt would be great like in Android. Share - Add
| to HomeScreen is too difficult for many users.
| gdeglin wrote:
| This is a tremendous announcement. Web Push is such a superior
| channel to SMS and Email for many websites" There's a standard
| opt-in and opt-out process, it's real-time, and it's free. Yet
| the adoption has been severely reduced by the lack of iOS
| support.
|
| The homescreen requirement is a small hurdle in the grand scheme
| of things. Now websites can finally implement Web Push once, and
| know that it will work for all of their users.
|
| This is especially useful for media sites and others that have
| historically struggled to get people to go through the whole app
| store to app install process. It will level the playing field and
| create much better user experiences.
| lxgr wrote:
| This is much appreciated, but it also comes at an interesting
| time, given that true alternative browsers on iOS are probably
| only a few months away at this point.
|
| That said, I wonder if alternative browsers will actually get
| access to the "add to homescreen" API?
| dimal wrote:
| > In iOS and iPadOS 16.4 beta 1, third-party browsers can now
| offer their users the ability to add websites and web apps to
| the Home Screen from the Share menu.
|
| If it's available for webkit-based third-party browsers now, it
| seems like it would probably be available for non-webkit
| browsers as well. Maybe not, but at least the door is open for
| it. It would be hard to justify the limitation.
___________________________________________________________________
(page generated 2023-02-16 23:00 UTC)