[HN Gopher] Web Push for Web Apps on iOS and iPadOS
___________________________________________________________________
Web Push for Web Apps on iOS and iPadOS
Author : tech234a
Score : 800 points
Date : 2023-02-16 18:36 UTC (1 days 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.
| diebeforei485 wrote:
| Apple can disable push notifications from a compromised
| app.
|
| It's unclear if they can do it for a compromised website,
| which was my question above.
| 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.
| 1-6 wrote:
| Can't wait... Literally, I can't wait. 16.4 can't come quickly
| enough. I just installed 16.3.1 yesterday.
| 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"?
| toastal wrote:
| But feeding into a proprietary product isn't good for us.
| Using Google and Photoshop as verbs isn't great as is, but
| Git by its nature as a DVCS it becomes even more important
| we don't have our language drift in a way that centralizes.
| Specifying that it is Git is even of questionable value.
|
| "Are there any samples with the source available" is a
| better phrasing (minimal and self-contained aren't implied
| by naming a platform).
| slugiscool99 wrote:
| Kudos to Apple for doing this. It's honestly very cool of them
| s-xyz wrote:
| Any good documentation on how to implement this? Eg a react site
| with Python backend?
| 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.
| twism wrote:
| Google Firestore?
| danShumway wrote:
| Am I missing something? Firestore is an online database that
| requires setting up a Google account. It's sort of like
| responding to "I wish I didn't need to include a serverside
| component" with "Linode".
| 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.
| fuglede_ wrote:
| I don't know how fine grained you want your notifications
| to be, but you can get pretty far without storing user data
| by splitting notifications by topic on the queue, or by
| filtering client-side in the service worker itself.
|
| But even then, the UX seems pretty bad; when I first
| created an app with web push, a few years ago, there was
| zero guarantee that notifications would ever show up, and
| they seemed to fall through very often, when the client (at
| least with Firefox Android) sits in the background;
| https://stackoverflow.com/q/60809681
|
| i can't tell if the situation has improved recently --
| anecdotally it seems like it's a bit better now -- but
| depending on what sort of notifications you want to push,
| that quickly becomes a complete showstopper.
| danShumway wrote:
| > there was zero guarantee that notifications would ever
| show up, and they seemed to fall through very often, when
| the client (at least with Firefox Android) sits in the
| background
|
| That could also be a longer conversation, but yeah, that
| was also my conclusion, and again... I don't have _proof_
| that this is Google 's fault, but it stands out to me
| that notifications as they're built today are primarily
| useful for spammy advertisements and engagement requests
| and are extremely unreliable for everything else.
|
| If your primary use case for notifications is telling the
| user that your blog published a new article or reminding
| them to check into their account or advertising a sale,
| then notifications are great; and you don't really care
| about reliability in that instance.
|
| If you want notifications to be something the user can
| really rely on, ie calendar appointments, sign-in
| attempts, etc... they don't seem like they're trustworthy
| enough to do that.
|
| Of course, we need those OS-level restrictions around
| notifications to stop abuse and spam, but that's only
| because it's super-easy to start spamming the user in the
| first place. And my pet conspiracy theory is that Google
| on some level looked at notifications and said "it's more
| important that it be easy for a blog to get somebody to
| click yes on this, than it is for us to build a
| transparent process to the user that would allow us to
| make the delivery more granular and more reliable."
| Instead of making it harder for websites to get
| notifications permissions in the first place, Google made
| them less reliable; the model is that you will have a
| bunch of sites that can spam you but they'll spam you
| unreliably.
|
| Again, I can't prove that, and maybe things have
| improved, but it's just weird how the entire spec seems
| designed around advertisements/spam, even to the
| detriment of everything else.
| kevincox wrote:
| You don't need an account and you can encrypt the message
| before queuing it on the server. Silly stupidity
| inefficient and won't work offline but it is quite easy to
| make a generic push message scheduling server that just
| pushes around blobs as requested by client-side code.
| danShumway wrote:
| That's an interesting point. It's still pretty messy and
| inefficient, but you're right, you could at least get
| away with not exposing user data, even if you're still
| transmitting it around.
|
| That's a good suggestion, I should play around with that
| some time.
| 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.
| nevernude wrote:
| Unfortunately a number of those APIs are still not available
| on iOS and have seen little to no traction[1]
|
| 1. https://bugs.webkit.org/show_bug.cgi?id=194593
| 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.
| MBCook wrote:
| I think that's the only reason this exists, as a side
| effect of Focus modes. I can't see Apple adding it
| purposefully otherwise.
| WorldMaker wrote:
| My understanding is that being able to hide Home pages
| predates Focus modes as it was the poor (and hard to
| discover) solution to what the Apps Library became (for
| apps that you needed installed but didn't care to see all
| the time).
|
| But yes, Focus Modes definitely elevates it to another
| level when you've got Mode-specific pages.
| 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.
| lxgr wrote:
| I just have all PWAs (that I don't need shortcuts for) in a
| folder towards the end of my last home screen page.
|
| I's long overdue to have them treated as first-class apps,
| though (i.e. allowing having them only in the app library and
| treating the home screen as an optional short cut only)!
| barnabee wrote:
| There should absolutely never be a prompt to install PWAs.
|
| If the site wants to tell me I can install the PWA by adding it
| to my home screen and remind me how to do so, it's welcome to,
| but no unwanted popups/prompts.
| latexr wrote:
| > 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.
|
| I keep seeing this touted as fact, yet no one has ever provided
| any evidence. I have the feeling everyone who says it is just
| mad at the feature not being there and they ascribe to Apple
| the most damming justification they can come up with.
|
| Apple is greedy, especially under Tim Cook, but that doesn't
| mean every decision is primarily motivated by it. Sometimes the
| people at Apple truly believe something is the right choice for
| the majority of users. Maybe you've been lucky to have never
| seen a relative's device full of spammy web push notifications
| they don't know how to turn off, but that is not rare. You can
| find reports of it among the other comments.
| 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.
| presentation wrote:
| How about a system preference of "don't show me these"?
| encryptluks2 wrote:
| The install option on Chrome isn't in your face nor
| interrupting. It is a small icon and text on the URL bar.
| Vinnl wrote:
| The crucial element here is that this indeed needn't be
|
| > more ways for a site to shove things in front of me
|
| The prompt can be provided _by the browser_ , at a moment
| of choice for that browser, in a standardised way, and with
| the option to be disabled globally. For example, a browser
| could choose to only show the option once for websites you
| use often and provide a manifest file, and/or when you
| bookmark them, and/or just show an icon in the address bar.
| So many ways to do this in a nonobtrusive way, that still
| makes sure that people who _would_ be interested in adding
| it to the home screen (i.e. a subset of the people
| installing an app today) actually _know_ they can do that.
| dbbk wrote:
| It should probably be surfaced when you go to bookmark a
| site.
| 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.
| charrondev wrote:
| The smart app banners are actually part of the browser.
| You add some meta tag to your HTML indicating your app ID
| and Safari shows a prompt outside of the web page to
| install or open it. Infuriatingly it can't be disabled,
| and since it's not part of the HTML I can't use a content
| blocker to hide it.
|
| Now there are a couple nice things:
|
| - if an app is not installed you can dismiss for a
| particular site and you will never see it again. The
| website has no way to trigger it, the API is more like
| "Hey Safari I have an app" than "trigger a prompt". -
| unfortunately if the app is installed you can't dismiss
| the notification to open in the app. This I quite dislike
| because many sites have certain pages on their site with
| no equivalent in the app. Sometimes I have an app and
| just want to visit the site without being nagged.
| Someone wrote:
| Thanks for the info, _charrondev_ and _coder543_
|
| I still don't see why _"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."_.
|
| Web sites drive this, and can choose whether they let iOS
| show a "download the app" or a "install on home screen"
| option. It's not Apple making that choice.
| coder543 wrote:
| I'm fairly sure _most_ people would prefer that Apple
| offers a version of the Smart App Banner that gives users
| a simpler install experience for PWAs. I think saurik was
| just humoring yamtaddle's perspective that PWAs should
| not be able to prompt for installation ever, and pointing
| out that it would only be fair to apply their restriction
| to websites offering native apps too.
|
| Right now, the install process for PWAs is needlessly
| obtuse compared to what users experience with a Smart App
| Banner.
|
| I saw someone elsewhere comment on the number of taps
| required with both methods, and I would point out that
| not all taps are equal. The simple, guided flow that the
| Smart App Banner gives users is tremendously easier for
| users to figure out than the "Add to Home Screen" flow
| that currently exists.
| jsnell wrote:
| It'd be Apple artificially giving native apps a boost /
| penalizing PWAs, like they've been doing for 15 years.
| Sites _want_ to get on the home screen. If the only
| viable way to get to the home screen is to make a native
| app, the site will either be forced to implement a native
| app for no reason or be at a disadvantage.
|
| Apple pretty obviously can support a similar UI for PWAs
| as for native apps. If they don't, it's just them doing
| the bare minimum required by regulators while still
| keeping PWAs as an uncompetitive second class citizen.
| And if the argument is that these banners are bad UX and
| will be abused (because that's always Apple's argument
| for why something should not be allowed in browsers),
| then they should own up to it being bad UX for native
| apps too and remove it.
| 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.
| danShumway wrote:
| > Well, a lot of sites that probably would spam an app if
| they had one, don't, because they don't have one, for one
| thing.
|
| This is my contention; the apps that want to spam you
| about this have resources to build apps. The people who
| don't are the people you see complaining on HN -- they're
| not companies.
|
| > It's not about tracking, it's about every single site
| on the web popping yet another annoying prompt nobody
| wants.
|
| Then I don't get the problem, because this only applies
| to PWAs you install. If you're worried about prompts
| asking you to install a PWA, then... that also is a UX
| problem, it has nothing to do with capabilities. Both
| Android and iOS I believe include mechanisms to block
| websites from over-spamming about PWA installation. The
| mechanisms could be better, but that's down to the fact
| that both Android and iOS have kind of a bad starting
| model for how permissions should work; apps shouldn't
| really be able to ask for anything without user
| prompting.
|
| ----
|
| > In practice--input latency, rendering performance,
| memory use, idle processor use, load time, and battery
| life, are between noticeably and hilariously worse in
| practically every case.
|
| If you say so? My feeling is that most overhead for most
| apps is the result of background logic. I'm not sure that
| how quickly you can render a DOM list matters much for
| battery life on average. Which is part of why background
| scheduling is so important, so you can get stuff to stop
| running in the background.
|
| I'll also point out that most of the native apps on most
| people's iPhones include webviews already; they're good
| enough performance to use natively. Yes there are apps
| where you might really care about this, yes there are
| apps that I don't want running in a webview. But again,
| think of some examples here. Is it really a problem for
| you that Wordle isn't a native app? Do you think that's
| impacting your battery to any noticeable degree? Do you
| boot up Wordle and get frustrated by the input latency?
|
| I don't know that I would use a webapp to replace Emacs
| (although I'll point out that Emacs also suffers quite a
| lot of latency problems because of its
| threading/rendering model and because of how it handles
| syntax highlighting, so I'm not sure it is actually
| competitive with web performance). But the point is,
| that's an environment where I'm doing programming on a
| keyboard. For a notetaking app on a phone? Is keyboard
| latency even going to be noticeable to you if you're
| using a swipe keyboard that sends input word-by-word?
|
| ----
|
| > I'm also a little confused about the alarm clock thing.
| My phone just... has an alarm clock.
|
| Maybe iOS's native alarm is better, but the native alarm
| clock on Android is significantly less powerful than I
| would like. It lacks the ability to:
|
| - Schedule alarms more than a week in advance (no, I
| don't want to use a calendar for that)
|
| - Delete alarms immediately after they go off
|
| - Snooze alarms for variable rates of time per-alarm
| (there's just a global setting)
|
| - Select music/sounds randomly from a list (very helpful
| for ADHD, consistent sounds get filtered out, so I have
| to constantly vary what my alarms sound like).
|
| - And a couple of other things, including the ability to
| easily export/import alarms, etc...
|
| Again, maybe iOS is a lot more powerful in that regard, I
| don't know.
|
| ----
|
| > The cross-app tracking, the prohibition of which has
| (so very delightfully) made Facebook extremely upset?
| Unenforceable without review.
|
| It's funny you bring this up, because this is absolutely
| enforceable in a browser and is already enforced in
| Safari. Firefox also has fantastic support for domain
| separation (Chrome as usual is the exception). Facebook
| was upset that Apple was bringing the _native app_ up to
| vaguely similar standards to what Safari already has.
|
| Seriously, the reason why Facebook tries to get you to
| install a native app is because native apps are easier to
| track and insert advertising into. If the web was easier
| to track, Facebook would offer you a PWA. I don't
| understand where people get this idea that the web is
| easier to track than native, I don't think that's ever
| been the case at any point, including on iOS. The best
| argument I can make on this is that making PWAs
| impossible to use on iOS means that Apple can personally
| vet all of the code that runs on your device, and that's
| just not a good security model. It doesn't scale well, as
| much as Apple would like to say that it does.
|
| Yes, Apple can't manually go after web apps that
| fingerprint you (well, they could, it just would be very
| obviously tempting antitrust attacks). But even so, I
| want to make this very clear -- even if you are on iOS,
| do not install Facebook. Don't install Twitter. Use their
| mobile website through iOS Safari. And install an
| adblocker; I don't think Safari's adblocker API is
| powerful enough to block ads/trackers on Facebook in
| specific, but it will work on a number of other webapps
| that you use.
|
| And bonus points, when apps are annoying you on the web,
| you can do something about it. You can intercept and
| block/modify app behavior. Sites like Facebook will make
| that hard, but... I mean ostensibly you're worried about
| spam from ordinary sites, and anti-annoyance blocklists
| work fine on them.
|
| Look, I like the privacy stuff that iOS is doing. I like
| that notifications here require you to install the PWA,
| that's a good decision. And I _love_ that iOS is adding
| more permission structures; better file portals are
| great, more app separation is great, I love the work they
| 're doing around permission prompts. But iOS is catching
| up to where the web is, it is not surpassing it. The web
| is a terrible minefield of tracking, and native
| ecosystems are worse, and iOS is now very notably and
| very impressively catching up to where the web is. But if
| you think a company wants to track you
| (Twitter/Facebook/whatever) even if you're on iOS, you
| should not treat the native app as safer than the
| website.
| yamtaddle wrote:
| OK, really good info, thanks for helping understand where
| you're coming from (seriously).
| 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.
| donbrae wrote:
| You can auto-populate the name field by specifying its
| value in the manifest.json file, eg
| https://github.com/donbrae/tripods-
| web/blob/e2fade06991a83ae...
| coder543 wrote:
| On my phone, when I click "Add to Home Screen", it
| immediately focuses the name text field and pops up a
| keyboard. As a user installing an app, I expect to see
| the name, the icon, possibly a description, and a big,
| obvious "install" button. I _do not_ expect to suddenly
| be presented with a keyboard letting me edit the name of
| the app. When a user changes the name, it is _far_ more
| likely to be a mistake than an intentional action, unless
| the PWA did a phenomenally poor job of naming itself. On
| Windows, when you install an application, do you expect
| it to _start_ by highlighting the app shortcut and
| entering edit mode so you can choose the name of the app?
| No, that would be bizarre, and it is bizarre here too.
|
| Regardless of it being auto-populated, I think being
| immediately presented with the option to choose the name
| will inevitably confuse many users. If the user
| accidentally hits any keys, that will mess up the name...
| then they have to try to fix it themselves, if they even
| notice before they hit the "add" button. That just
| doesn't seem like a great user experience.
|
| Talking about the "add" button, it is not called
| "install", unfortunately. The "add" button by itself may
| confuse users into wondering if they clicked _bookmark_
| by mistake. In fact, the interface is nearly identical to
| the bookmark interface in Safari, except that the
| bookmark interface uses the word "save" instead of
| "add", and the bookmark interface shows you which folder
| you're saving into. How clear and simple!
|
| The "add" button is also a small button in the top right,
| which is completely different from how the "GET" button
| with a vivid blue background is presented in the App
| Store. Renaming and restyling the button to match the one
| in the App Store would make the experience more
| consistent for the user.
|
| None of this matters to technical users like us either
| way, but making PWAs more accessible to all users
| requires making the process as easy as possible,
| smoothing out weird rough edges like this. The option to
| edit the name would make more sense under the Settings
| app or maybe an additional "Edit" option in "jiggle mode"
| on the home screen, if it should even exist at all. I
| can't edit the name of other apps on my phone. From a
| technical perspective, someone might ask "why can't I
| edit those names too?" But, it should be consistent
| either way, in my opinion.
|
| Those are my opinions on the current interface, anyways.
| I don't think Apple has meaningfully changed it for over
| a decade, and if they have decided to care about PWAs,
| they really should polish this interface up.
| manmal wrote:
| I honestly think you are overthinking this. Many users
| would actually prefer to customize the displayed name.
| Discoverability of the installation process is IMO the
| real issue.
| coder543 wrote:
| Then why doesn't iOS ask users to customize the displayed
| name of native App Store apps before installing them? As
| I said, I think it should be consistent, and I don't
| think that's a hugely controversial opinion.
|
| Also, why don't Windows or Android ask you to name apps
| before you install them? Why doesn't Steam? This is just
| not how installing apps works. At a minimum, I would like
| it to avoid popping the keyboard up by default. If a user
| wants to edit the name, tapping on the name themselves
| shouldn't be a problem.
|
| > Discoverability of the installation process is IMO the
| real issue.
|
| I agree this is certainly the biggest issue.
| hn_throwaway_99 wrote:
| > On iOS, users have to click "share" and "add to Home
| Screen"
|
| Thanks very much for your detailed explanation. Man, more
| and more I don't know how people can continue to praise
| Apple for better usability. So much shit on an iPhone these
| days is in completely hidden, non-obvious gestures or
| swipes - e.g. why TF would anyone think "add to home
| screen" would be in the share menu?
| 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.
| holoduke wrote:
| Actually not bad. We are converting all our native apps to
| either webapps (still available in the store) and as a PWA.
| Performance was always an issue, but nowadays we are convenient
| that performance is good enough. Developping in web is soo much
| easier, cheaper and much much faster.
| 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?
| bobthepanda wrote:
| To an appstore link, its at least three on ios
|
| Once to get to app store
|
| Once to click install
|
| A double tap to verify after face/touch/passcode on ios
|
| (I use iOS.)
| yamtaddle wrote:
| Ah, forgot about the double-tap to verify.
|
| I'd _hope_ PWAs on Android take at least two actions to
| install (though perhaps not three). One-tap is how you
| end up with every user having tons of apps installed they
| never intended to.
| 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.
| [deleted]
| 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.
| toastal wrote:
| I often forget how unusable Reddit is without old.reddit
| and a native, FOSS app like Infinity to make it
| acceptable.
| kitsunesoba wrote:
| If it weren't for Narhwal and later on, Apollo (iOS
| reddit clients) my usage of Reddit would be somewhere
| between 0% and 10% of what it's been the past several
| years.
| dmitriid 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.
|
| I can't believe people keep saying this with a straight face.
| It's as if they've never seen an proper native app before
| (any of the third-party clients to Twitter come to mind
| before they were axed). Or haven't seen actual good fast
| implementations like the one Twitter actually bought and
| surprisingly still kinda maintains (see on desktop,
| https://tweetdeck.twitter.com/)
| tuxone wrote:
| I wonder when you people will stop thinking with your
| marketing/growhacking/SEO/spam brain and start being on the
| user side. If you want low value visitors just go and buy ad
| clicks, thanks!
| izelnakri wrote:
| I strongly disagree that what he is asking is user hostile,
| just like asking microphone or camera permissions aren't user
| hostile. You also didn't need to lecture anyone like that on
| hacker news, thanks!
| tuxone wrote:
| What they are asking would be used as an annoying tool
| against the user in the same way today sites ask for user
| location or push notification (on other OSs).
|
| Websites are not randomly asking for mic or camera because
| that would be creepy and visitors would just run away.
|
| I am not lecturing, I am giving my feedback on the matter,
| like everyone else here. If your product is good, users
| will save your site in their home, don't worry about that.
| LeanderK wrote:
| lol, this was a project I did for a friendly event free of
| charge. I choose PWA because it's only useful for three days
| and nobody is going to install an app for this, you want it
| working right away. I was getting good results but the
| experience was just way smoother on android. A good
| prompt/banner/whatever that the app is installable felt
| essential when viewing the users behaviour because it's
| "drive-by" usage.
| 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.
| dmitriid wrote:
| > Yes this is a significant hammer blow against native apps
| on iOS
|
| Funny how this significant blow never happened on the world's
| most dominant OS where all the restrictions that HN loves to
| whine about don't exist.
| 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.
| robertoandred wrote:
| 99.9% of people would not switch to Chrome overnight. They
| don't know or care what a rendering engine is.
| fragmede wrote:
| 4.47% of them don't have to - they're already on Chrome on
| iOS.
|
| https://techjury.net/blog/web-browser-market-share/
| WastingMyTime89 wrote:
| They don't need to know. They just need to click on the
| banner which will be on every Google search result pages.
| How do you think Chrome got its market share on the
| desktop?
| robertoandred wrote:
| There's nothing stopping that from happening now. Chrome
| has been available on iOS for a long long time.
| dagmx wrote:
| I really wish I could get google to shut up about logging
| in to my Google account and/or download chrome.
|
| When I use safari on my work device, I don't want to sign
| in. I don't want to download chrome.
|
| They're so incessant with their pushing of the browsers.
| It's easier to just give in than to deal with their
| pestering.
| 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.
| Eduard wrote:
| Are you talking about Apples walled garden app store or are
| you talking about the Aplpe-enforced webkit browser monopoly
| in iOS?
|
| Or are they Effectively dependant on each other?
| 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-...
| varenc wrote:
| Digression: The language in this post seems to straddle the line
| between an official Apple Press release and an open source
| project update. While it mentions new features added to WebKit,
| it also references new iOS APIs. Additionally, the term "third-
| party browsers" is used, even though on iOS all those browsers
| are simply using WebKit. From the perspective of the WebKit
| project, I don't view these browsers as "third-party" as they too
| are utilizing WebKit. Not really complaining, just something I
| noticed.
| heygarrison wrote:
| This is awesome!
| gloosx wrote:
| Finally. This is the reason most ugly Flutter-style app-site
| chimeras existed. Now it's slightly better.
| somethoughts wrote:
| Great - just what I need for my productivity in 2023 - a
| Hackernews PWA icon on my iPhone's home screen with
| notifications!
| 1-6 wrote:
| Finally, my short llll.com domains and site can compete with Apps
| on the App Store again!
| 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.
| neither_color wrote:
| I'm like you I disable almost all notifications by default. For
| some pesky apps that try to be cheeky about it, like Uber Eats
| requiring notifications but then not letting you opt out of
| promotional ones, I turn them on only for the duration of my
| order.
| 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!).
| rahoulb wrote:
| However with a native app, you've _chosen_ to install it, so
| you 're at least partially interested in its notifications.
| With a website, you may just have browsed to it and have no
| intention of ever returning again. So the point of having to
| "install" the PWA to your home-screen mimics that first stage
| of intention.
|
| The key issue (as many others have noted) is that the
| "installation" step is still somewhat arcane.
| 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.
| JimDabell wrote:
| That isn't true. Here are the rules:
|
| > 2.5.3 Apps that transmit viruses, files, computer code,
| or programs that may harm or disrupt the normal operation
| of the operating system and/or hardware features,
| including Push Notifications and Game Center, will be
| rejected. Egregious violations and repeat behavior will
| result in removal from the Apple Developer Program.
|
| > 2.5.16 App Clips, widgets, extensions, and
| notifications should be related to the content and
| functionality of your app.
|
| > 2.5.18 Display advertising should be limited to your
| main app binary, and should not be included in
| extensions, App Clips, widgets, notifications, keyboards,
| watchOS apps, etc.
|
| > 3.2.2 Unacceptable: (ii) Monetizing built-in
| capabilities provided by the hardware or operating
| system, such as Push Notifications, the camera, or the
| gyroscope; or Apple services, such as Apple Music access
| or iCloud storage.
|
| > 4.5.3 Do not use Apple Services to spam, phish, or send
| unsolicited messages to customers, including Game Center,
| Push Notifications, etc.
|
| > 4.5.4 Push Notifications must not be required for the
| app to function, and should not be used to send sensitive
| personal or confidential information. Push Notifications
| should not be used for promotions or direct marketing
| purposes unless customers have explicitly opted in to
| receive them via consent language displayed in your app's
| UI, and you provide a method in your app for a user to
| opt out from receiving such messages. Abuse of these
| services may result in revocation of your privileges.
|
| -- https://developer.apple.com/app-
| store/review/guidelines/
| 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.
| Eduard wrote:
| But it's bad news!
|
| I can think of so many valid and proven use cases for
| notifications.
|
| Requiring to first save a web app locally in order to
| actually benefit from its full feature set is bad UX. Apple.
| sercand wrote:
| I am wondering what is the use case for a website that
| sends notification to the user who didn't install the PWA
| to home screen.
| om2 wrote:
| Going by this thread, more people seem grateful than upset
| about this UX.
| 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.
| MBCook wrote:
| Sadly I don't think it will change anything. It's different
| from Chrome so it lacks the feature of the week and needs
| "special fixes" because it has a different rendering engine.
|
| It seems to be doomed to persona-non-grata for a lot of
| developers. At least until the Chrome worship dies.
| 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.
| CodeIsTheEnd wrote:
| A personal gripe with progressive web apps: they cache the
| website!!
|
| A lot of people have requested that I make a progressive web app
| for https://plaintextsports.com. I've looked into it, but it
| fundamentally doesn't work, because it caches the home page. My
| website doesn't load any data via JavaScript; it just relies on
| the HTML page updating every 30 seconds, so when the home page is
| cached, the website just stops working.
|
| I don't want this service worker nonsense. In most cases offline
| access isn't useful; people want the live scores. (It'd be
| moderately useful for viewing schedules offline, but I think most
| people use it for live scores.) I just want the website to show
| up as its own app in the app switcher, and basically _nothing_
| else to change: I still want the swipe-to-go-back gesture to
| still work. I still want the address bar with the manual refresh
| button. But I can 't do that.
|
| It's frustrating that they've provided a way to make a certain
| style of websites into first-class apps, but it doesn't work for
| the most basic websites!!
|
| Side note: this is partially a the-best-way-to-get-a-question-
| answered-on-the-internet-is-to-say-something-wrong post. If
| there's a way to make it a PWA and not have all the pages heavily
| cached, please let me know! I would love to be wrong on this.
| (Unfortunately my noprocast just triggered though, so I won't be
| able to edit this post or respond for the next three hours.)
| coder543 wrote:
| It has been awhile since I've personally tried creating a PWA,
| but I don't think iOS does any form of extra caching for PWAs.
| I think it is more likely that you copy/pasted an example
| service worker that was caching things you didn't expect it to
| cache. Some info about PWA caching here[0].
|
| That page also talks about "What to Cache" here[1], and it
| _specifically_ suggests that most apps will want to cache the
| main page 's HTML.
|
| Now that iOS will supports push notifications in PWAs, I
| definitely plan to try out the developer experience again soon.
|
| > I still want the address bar with the manual refresh button.
| But I can't do that.
|
| Yeah, I mean... you're meant to provide an app-like experience
| if you're doing a PWA. You could certainly build your own
| stylized, floating bar that only shows up in PWA mode, or think
| about new ways to let users control the way the page updates.
| Alternatively, you could just automatically refresh the page
| with a setTimeout?
|
| I'm not sure how much you want to invest in experimenting with
| the technical foundations of your app, but I wrote out a few
| ideas that occur to me:
|
| - Your Cache-Control header is kind of weird. `max-age=15`. I
| would expect to at least see a `public` or `private` directive
| in there to specify how this data is supposed to be handled by
| intermediate proxies. Something like your website is a prime
| candidate for caching in a CDN layer, and I think you generally
| want to specify `public` for CDNs to do anything useful. Maybe
| they default to `public`? I've honestly never felt the need to
| try. Beyond the `public` / `private` discussion, `stale-if-
| error` could be useful so the CDN could serve the most recent
| info even if your application is having a brief outage. If
| you're _not_ using a CDN... probably something worth checking
| into.
|
| - As cool as just serving self-contained HTML document is, your
| page is still transferring 6 kilobytes each time it refreshes.
| If the goal is to lower that as much as possible, I would start
| by pointing out that you don't _need_ to send your JavaScript
| snippet every single time the page loads. It looks to be
| several thousand bytes uncompressed, although I 'm not sure
| exactly how much it is affecting your compressed payload size.
| You could separate that into an _aggressively cached_
| JavaScript file that is served separately from the HTML. (As
| usual, best practice is to have a file hash in the name of the
| javascript file, that way the cache time can be infinite. If
| the javascript needs to be updated, the hash would change, so
| the browser wouldn 't have that cached, and would fetch the new
| file immediately, as soon as the refreshed HTML file requests
| it.)
|
| - But then after that... the next logical step is to render the
| actual score interface client-side, since the score data is
| significantly smaller than the HTML needed to render the score
| data. This would also allow you to handle refreshing more
| elegantly from the client by just fetching the data route that
| returns a JSON blob, and re-rendering the HTML. At this point,
| the HTML representing the empty app shell could be cached too,
| but it would probably be best to limit the cache duration
| depending on your preferences. The right value for HTML caching
| would likely be somewhere between a few minutes and a few days.
| Now, opening the app would load the locally cached HTML and
| JavaScript, and then the JavaScript would just fetch the tiny
| blob containing only the scores and nothing else. Of course,
| you could cache this information locally so that when the PWA
| is opened, the user can _always_ see the last information (and
| when it was fetched) even if they don 't have an internet
| connection, while the PWA can continue trying to fetch the
| updated scores.
|
| - Taking this to the extreme, the _maximally efficient_ design
| for something like this would probably involve an SSE (server
| sent events) endpoint that the client would subscribe to.
| Whenever the scores actually do change, the server could push
| that straight down to the client. This would reduce the latency
| from your current 30 second target, and it would also use even
| less data since people aren 't refreshing and receiving the
| same stale data multiple times. (I will note that a good
| implementation of this would still send a tiny ping from server
| to client every minute or two just to ensure the connection
| doesn't get silently dropped by any weirdly configured
| firewalls along the way.)
|
| - If you were really going all-in on features, well... this
| whole HN discussion is highly focused on push notifications, so
| you could always let people subscribe to specific teams, and
| send them a push notification when scores change for those
| teams.
|
| [0]: https://web.dev/learn/pwa/caching/
|
| [1]: https://web.dev/learn/pwa/caching/#what-to-cache
| m5r wrote:
| Your service worker dictates what the browser should cache. You
| could cache static assets only and let the browser hit the
| server for document requests. As for the refresh button, mobile
| users are now used to pull to refresh so you might not need an
| actual refresh button.
|
| As an aside, I dig the design! It reminds of teletext haha
| 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.
| dmitriid wrote:
| The big limousine disappears...
| 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.
| LeanderK wrote:
| I don't get why apple does not take a similiar path on mac.
| Some websites are really apps for me (stuff like overleaf). I
| would gladly add them as apps and use this to unlock all those
| advanced functionality. But so far, at least on safari for mac,
| all those web-push websites are mostly spam. I only have a few
| where it is useful but I use them, again, like normal apps, and
| would be fine of adding them to my library.
|
| Nobody uses the mac app-store anyway, so why bother? Why not do
| it?
| postalrat wrote:
| Web push or the notifications API? They both do about the same
| thing but web push can happen even if your browsers are closed
| and the phone is locked.
| smoldesu wrote:
| Sounds like this is the motivation Apple needs to bring their
| notification-handling into the next century. I'd love for Apple
| to give me a way to disable "Try the New Safari!" notifications
| without opening my terminal.
| 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
| extra88 wrote:
| I don't think there is a limit to how many apps icons can
| be in an iOS folder, they're paginated. Right now, I have
| 27 in an "Apple" folder, spread over 3 pages. If I add
| another icon, it adds another page.
| 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
| interpol_p wrote:
| I dislike the desktop implementation of push permission
| request in macOS Safari
|
| It presents a modal popup asking for permission. A few
| times I have accidentally clicked "Allow" only to have to
| hunt through my notification settings for the offending
| website to remove it
|
| Web sites should not be allowed to present modal, native UI
| that can interrupt the browser. They should be contained to
| their window
|
| A better implementation would be to allow the browser to
| show a bell or other icon in the main UI indicating the
| website offers push notifications. Clicking on that would
| inform and allow the user to opt-in
| [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
| barnabee wrote:
| My desktop browsers get denied permission to show
| notifications at the OS level and are set to block them for
| all sites without asking.
|
| I can't think of a single valid use case for them. There
| are only a handful of desktop apps (literally 4 or 5 apps
| like MeetingBar) that I allow to use notifications on
| desktop. For essential messaging app, etc. that I need
| notifications on, I configure them to be only on my phone,
| which I can just turn over if I don't want to see them.
|
| This new iOS functionality therefore fits perfectly with
| how I use notifications: if I install the website like a
| mobile app, it can maybe get notifications, otherwise
| websites can't bother me even with requests to show them.
| arendtio wrote:
| Does this affect Firefox on iOS too? Just yesterday I tried to
| add a website to my home screen but couldn't find the button.
| PossiblyKyle wrote:
| My mother has an Android phone, and she's not really tech
| savvy. Her notifications are absolutely bombarded with garbage
| from various websites, and her lock screen displays ads. I'm
| moving her to iOS, as I'm quite sick of constantly being the IT
| guy.
| philliphaydon wrote:
| Oh I can relate to this. Bought my mum an android phone when
| my daughter was born so I could share photos and do video
| calls.
|
| It was such a hassle doing support over the phone (She lives
| in NZ and I was in Singapore, and now Taiwan)
|
| Bought her an iPhone 12. Apple support helped her set it up
| over the phone. 2 years and I haven't played IT guy once!
| 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?
| bakje wrote:
| I believe adding a site to your home screen isn't opting in
| to notifications, but opting in to allowing the site to
| request notifications, which would then require another opt-
| in.
| 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._
| cyanydeez wrote:
| The web has a standard we push API.
| 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.
| achairapart wrote:
| I guess websites will start asking users to add them "to the
| home screen", so they can later start asking permissions for
| push notifications...
|
| But this is a different kind of problem and no reason to slow
| down the Push API standard.
|
| I'm very happy that they also finally implemented things like
| Screen Wake Lock API so developers will no longer be forced to
| do silly things like play a fake video loop in the background
| to keep the app in focus.
|
| Looks like Apple is finally going to give PWAs some love and
| it's a good thing overall.
| bioemerl wrote:
| It's actually pretty difficult to do something like that
| since an install is done through the OS and the app can't set
| off the process. I think it's too clumsy for most sites to
| try it.
|
| Chrome does let you do it though.
| camhart wrote:
| This seems very unintuitive though. Why not just add a button
| somewhere that says "enable notifications"? Apple loves these
| super unintuitive approaches. Blows my mind that anyone
| actually believes the marketing that they're "easier to use"
| than any other platform.
| fiddlerwoaroof wrote:
| I think that's this is because the "add to Home Screen"
| workflow is how you install PWAs on iOS and they want to
| restrict these APIs to PWAs.
| 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.
| makeitdouble wrote:
| Can't she revoke it from the notification screen when she
| sees a spammy one ?
|
| Sure it's still better to never subscribe to unwanted
| notifications, but removing them isn't much of a hassle in
| the current system IMO
| ocdtrekkie wrote:
| Nobody who doesn't work in the industry knows how to do
| this. Browser site permissions are basically the absolutely
| most incomprehensible UI ever to ordinary users. It's why
| implementing these features without an app install is user
| hostile.
| spondyl wrote:
| My parents are in the same boat. Revoking it assumes the
| user even has a mental model of what a notification is.
| That is: Something that you can opt out of or even
| necessarily that they gave permission in the first place. I
| suppose it's viewed a bit like receiving junk mail or
| advertisements on TV. That might seem absurd on the face of
| it like of course it's your device but not everyone is
| necessarily aware that they even have any agency (or are
| interested in learning yet more "computer nonsense")
|
| I'm being a bit over the top here but I consider it much
| the same problem as how you might use a car without
| understanding any of how it works. In the same way, plenty
| of people own mobile phones without any understanding of
| cause and effect.
|
| I'm pretty sure my parents don't even "see" permission
| prompts, they just sort of have this "thing" in the way of
| the "screen" and tap at it to go away rather than y'know,
| some sort of two way consent dialogue.
| makeitdouble wrote:
| I might be misremembering, but I think android (at least
| Pixels) have a prompt to ask if you want to get rid of an
| app's notification if it pops up too often, and/or show
| you the current settings for the notification for review.
|
| I wonder if a similar approach could be used: just as
| users might half blindly push "OK" on a request for
| notification permission, it could be counter balanced by
| a check on new notifications in the kind of "Do you want
| to stop this app from sending you more of these messages
| ? you can always change your mind in the XXXXX screen
| <link to said screen>"
|
| To be honest, I don't wish for more people to have to
| comb their notifications screens and have a deep
| understanding of what's happening. I'd prefer the OS to
| better surface to the user they just need to push a
| button to get rid of the crap.
| danShumway wrote:
| > My parents are in the same boat. Revoking it assumes
| the user even has a mental model of what a notification
| is. That is: Something that you can opt out of or even
| necessarily that they gave permission in the first place.
|
| My feeling is that if a user doesn't know how to disable
| a permission, then they were not giving informed consent
| about enabling the permission. Being able to turn _on_ a
| permission is an imperfect but ultimately better
| indicator that they likely know what the permission is
| (it 's not completely bullet-proof, but it's better).
|
| Clicking "yes" just means that they clicked "yes", it
| doesn't mean anything more than that.
| postalrat wrote:
| Are all the notifications from native apps fine? Or just the
| web notifications that are bad?
| sneak wrote:
| I regularly get spam notifications from major/famous iOS
| apps. It's always an instant uninstall for me.
|
| IIRC this used to be against Apple App Store rules but I
| guess they got relaxed for spamming existing customers.
|
| Fastest way to lose me as a customer, TBH, is to disrespect
| my fiercely-guarded attention span with prompts to spend
| money while I'm busy being focused on making it.
| latexr wrote:
| > IIRC this used to be against Apple App Store rules
|
| It was.
|
| > but I guess they got relaxed for spamming existing
| customers.
|
| Apple themselves have sent notifications of that kind.
| The rule has since been dropped, I doubt it was ever
| enforced.
| runarberg wrote:
| Good question. I think the main difference is that it is so
| much easier to visit an annoying website then to download
| an annoying app. And your GP mentions how a good compromise
| is to grant this access only to websites you install to
| your home screen (which I think is a comparable action to
| downloading an app).
| faizmokhtar wrote:
| Last I checked, the push notifications that are
| masquerading as native popup asking user to install
| "antivirus" are all on web.
| 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.
| maicro wrote:
| Absolutely fair, but that's why I set that on all
| browsers I configure for family, and recently had to walk
| my sister through on her phone when she accidentally
| allowed notifications from some website that started
| spamming her with various scam attempts.
| babypuncher wrote:
| You can do this in Firefox as well.
|
| However, nagging the shit out of users should not be the
| default behavior. They knew that this feature would get
| abused by every sleazy webmaster on the planet as soon as
| it was supported in popular browsers. The feature should
| have been properly designed in the first place. Now I'm
| content with letting it die.
|
| I appreciate Apple's willingness to more or less ignore
| open standards that hurt the user experience more than they
| benefit it.
| 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.
| brigandish wrote:
| I wonder, does setting this stop one from getting or
| subscribing to notifications on sites where they're wanted?
| maicro wrote:
| As I understand it (I never want notifications so don't
| have any experience with it), it's only blocking new
| sites from asking to send notifications. So if you find a
| site you want notifications from, you can change that
| back to "Ask" temporarily, allow for that site, and then
| change back to "Block" for all sites by default.
|
| Note that that behavior might be different on mobile vs.
| desktop browsers, but again, I don't really know how to
| test, sorry.
| solarkraft wrote:
| The request mechanism is so broken. There shouldn't be a pop-
| up at all. The website should declare a notification source
| and you should be able to subscribe to it _if you feel like
| it_. Somewhere in the overflow menu. The website shouldn 't
| even get the option to natively bother you about it.
| dwighttk wrote:
| I mean then they'd just have pop ups that told you how to
| turn on notifications and make it seem like you have to to
| continue... wouldn't be as successful but it would still
| suck.
| solarkraft wrote:
| It would at least be harder. It's a lot easier to sell
| "click ok to make the pop-up go away" than "go into the
| overflow menu, then click 'subscribe to notifications'".
|
| Since users tend to choose the path with the lowest
| friction, they'll probably prefer to find a way to close
| a pop-up. The instructions also make it very clear what
| the user would sign up for.
|
| Bonus: Don't even let the web app know whether the user
| has subscribed to make it impossible to force.
| ocdtrekkie wrote:
| That's the right way to do it, but then the Chromium team
| that implemented it doesn't get good numbers to use for
| their promo packets.
|
| And there's no understanding among a lot of web standards
| people that popups for site permissions are widely used by
| malicious actors. Apple consulted the community and thought
| about security, and that's why this implementation is
| refreshingly better.
| danShumway wrote:
| It's not just Web Push, most permissions should be user-
| prompted, not site-prompted.
|
| If the user doesn't know how to enable those permissions,
| then they also very likely don't know how to disable them
| either, which is a problem. If they don't know those
| permissions exist, they also probably don't know what the
| implications are of turning them on. Giving them a bunch
| of yes/no dialogs to click through doesn't change
| anything about the obligation to educate users about
| their device permissions, and if they are educated
| properly then they can set those permissions themselves.
|
| Google (and browser manufactures in general) kind of
| taught people that the way we do permissions is that apps
| ask for them and the user says yes/no, and the app
| responds. It's not entirely only their fault, but it's
| the wrong way to think about it in my opinion. I'm not
| even sure I like the word "permissions". Most permissions
| should be better thought of as "capabilities" and they
| should be something _granted_ by the user, not requested
| by the app, and the app shouldn 't be able to tell the
| difference between a phone/platform that doesn't support
| those capabilities at all and a phone/platform where the
| user has denied those capabilities.
|
| A lot of issues about how permissions aren't scalable or
| how they don't work stem from the way we think about
| permissions as if the default UX for them should be that
| they're handed to the user like a EULA to sign.
|
| ----
|
| I'm still bitter over the fact that Chrome blocks
| webaudio behind a user action and literally breaks the
| website audio if you accidentally set it up when that
| permission isn't granted yet, and then disables all of
| those protections whenever you navigate pages within a
| domain. It's ridiculous; what should have happened is
| that by default, tabs in Chrome should just be muted
| globally, and audio code should just continue to work
| normally so that a massive number of web games don't just
| immediately break, and the user can untick the mute
| button and turn on sound for the very, very few websites
| where most users want sound.
|
| I'm bitter that they made all these justifications about
| how blocking the audio was important because it would
| save mobile data, and actually what happens is all of
| these sites just mute the audio by default, stream the
| video on mobile data anyway, and then unmute the video as
| soon as the user clicks anywhere. It's a bunch of bad
| justifications for a UX that makes it easier for websites
| to abuse users. We could have had more user-friendly
| behavior and not broken the entire web, but Chrome wanted
| to try out some weird statistical model for
| blocking/allowing audio playback instead of adding a
| button.
|
| The "spamming requests for things the user doesn't care
| about" problem is a lot easier to deal with if you invert
| "permissions" into something the _user_ requests and not
| the site.
| mhdhn wrote:
| What you describe around audio
|
| > mute the audio by default, stream the video on mobile
| data anyway, and then unmute the video as soon as the
| user clicks anywhere
|
| sounds like exactly like how Instagram app works.
| danShumway wrote:
| It's become really common on websites, and it's one of
| the primary reasons why I block JS by default on my
| phone. I assume a lot of mobile apps work the same way,
| but I haven't checked. I don't think you could pay me to
| install Instagram on my phone.
|
| To be more specific about why the Chromium model is so
| messed up, it's based on the idea that you should only be
| able to start audio playback in response to a user
| action.
|
| But what counts as a user action is:
|
| - highlighting any text on the page
|
| - clicking anywhere on the page
|
| - pressing any key on the keyboard
|
| - basically anything you do on a web page.
|
| And then the web page can play any audio it wants for the
| entire duration of the page visit. So in practice,
| blocking autoplay _only_ makes things more inconvenient
| to devs and breaks a bunch of websites. It doesn 't help
| the user at all.
|
| Firefox's implementation is slightly better because it's
| more predictable (Firefox doesn't have Chrome's weird
| algorithms about playback), but it's still mostly broken.
| I wrote a giant article about this back in 2018, and 5
| years later the demo that I made works just as well today
| as it worked back then:
| https://danshumway.com/blog/chrome-autoplay/demo/ (link
| has autoplaying music)
|
| Nothing ever got fixed, and autoplaying audio is still a
| problem.
| ocdtrekkie wrote:
| Indeed, I agree with everything you said here.
|
| One of the things that excites me about Apple's approach
| here in particular is that it's very easy for people to
| understand: Users intuitively know they can install apps
| to do things on their device, and uninstalling the app
| will make those things go away/not happen. While still
| using web app technology, it embraces a much more
| classically understood concept. I hope the other browser
| companies follow suit.
|
| The site permissions model feels more empowering and
| narrow-scoped to power users, but it's absolutely
| baffling to everyone else. Install and uninstalling is
| simple.
| danShumway wrote:
| I kind of dislike the app/website distinction that people
| make sometimes, but even I feel like this is a pretty
| decent line between the two: "a thing I 'install' means
| that I want it to have more capabilities than something
| that I want to be transient." I agree, it's good UX.
|
| And similarly, it's great to tie that to the app list --
| it means if you want to get rid of those permissions, you
| now have a really easily viewable list of every site
| that's sending you notifications (I'm assuming that iOS
| revokes push notifications if an app is unpinned from the
| homescreen).
|
| There are ways in browser to get lists of every site that
| can send you notifications, but nobody outside of tech
| circles will ever find them. In contrast, this is reusing
| the same UI that you'd use for any other cleanup action.
| Everything that can send notifications is in the same
| place. That's something I can explain to a non-technical
| user.
| WirelessGigabit wrote:
| And yet they allow auto play. I wish they hid that behind
| a permission. It's god-aweful. Looking at you Ars
| Technica. Go burn someone else's mobile data.
| danShumway wrote:
| It's wild to me that we all recognized autoplay was a
| problem, Google broke a bunch of websites, there was a
| big stink around it, and so 5 years later... we still
| haven't solved autoplay. Nothing has changed, we just
| stopped talking about it.
|
| I made a demo showing how easy this was to circumvent in
| 2018 and it works just as well today in both Chrome and
| Firefox as it did in 2018, nothing has improved since
| then: https://danshumway.com/blog/chrome-autoplay/demo/
| (link has autoplaying audio).
| WirelessGigabit wrote:
| When I click that link it doesn't autoplay. I need to
| click something on that page for it to work!
| danShumway wrote:
| Right, that's the point. How often do you browse a web
| page and never click on anything or highlight any text?
| If you're interacting with a SPA like Twitter or
| Facebook, it's impossible for you not to have a user
| action by the time you run into a video. It's fairly
| common for web articles to put everything except the
| first two paragraphs behind a "click to expand" button.
| What that does is force you to invisibly give them
| permission to autoplay audio.
|
| Chrome introduced a solution where in practice, videos
| still all autoplay (the demo doesn't show this, but if
| you start a video muted you're still allowed to autoplay
| it), and then 15 seconds into browsing the page you still
| get hit with a blast of music. And in the process of
| doing that, they also broke a substantial number of web
| games.
|
| And, also, the restrictions don't apply if you're
| browsing within a domain, so if you click on a CNET
| article and then click a link to another CNET article,
| now the second article has permission to play even
| without a user gesture. "In response to a user gesture"
| is such a weak protection. Highlighting text counts as a
| user gesture.
|
| My preference would have been for Chrome to just auto-
| mute that tab as soon as audio started playing, and allow
| the user to unmute it themselves not as a gesture that
| "implies" consent, but by explicitly clicking the unmute
| button.
|
| I don't think the current solution solves anything at
| all, I think it's worse then what we started with.
| Particularly on mobile, it's extremely easy to
| accidentally tap on a website. In my opinion, it's
| effective the same thing as just allowing autoplaying
| audio, I feel like they might as well have changed
| nothing.
|
| _Edit: I 've got a longer article I wrote in 2018 that
| goes into more problems, but a lot of them are orthogonal
| to the current conversation and are mostly focused on the
| impact to web games and criticizing Google's
| communication with developers, so I tend to just directly
| link to the demo when talking about it nowadays
| (https://danshumway.com/blog/chrome-autoplay/)_
| account42 wrote:
| If it was just Chrome that made these user-hostile
| decisions then I wouln't care that much, but for some
| reason Mozilla decides to copy most of them.
| ocdtrekkie wrote:
| Eh, in most cases it is just Chrome. WebUSB, Web Serial,
| a dozen others, Chrome has implemented despite both
| Mozilla and Apple saying they won't because the risk of
| malicious use is too high.
|
| I would argue (and have argued before), if placed behind
| a well-understood consent concept like "installing" the
| PWA, it would be safer to implement these sorts of APIs.
| mrtksn wrote:
| Very sensible limitation, otherwise we would just have another
| dialog to deny or accept on every website.
| babypuncher wrote:
| I agree. None of this stuff should even be requested before the
| user makes it clear they are actually interested.
|
| I like that I didn't have to permanently disable push
| notifications in Safari to stop those awful popups asking if I
| wanted them. Apple knows that people will say "no" 99.9% of the
| time. It makes more sense to make the user jump through hoops
| the one time they actually want it than to incessantly nag them
| every single time they make the mistake of visiting a new web
| page.
| 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.
| donbrae wrote:
| I've long been hoping for something like the Smart App
| Banners[0] that native app developers can use to link to
| their app in the App Store.
|
| It's relatively unobtrusive and easy for users to dismiss.
|
| [0] https://developer.apple.com/documentation/webkit/promotin
| g_a...
| LeanderK wrote:
| yes! Smart App Banners are really great and I just wished
| they would be available for PWAs
| 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.
| layer8 wrote:
| It's more like what would be the context menu in a
| traditional desktop GUI.
| tomduncalf wrote:
| FYI you can just type in the address bar and a "find in
| page" option appears in the autocomplete list if that text
| is on the page, no need to use the share screen
| gregoriol wrote:
| This is even more hidden than the one in the share screen
| sosborn wrote:
| More hidden maybe, but definitely more logical.
| Someone1234 wrote:
| More logical to use a textbox typically reserved for
| navigating away from the current page, to instead search
| that page?
| gregoriol wrote:
| Thanks, was going to answer the same: nor the "address"
| text field nor the "share" button indicate actions to be
| performed inside the page; the logical idea is that first
| one is to go to another site, the second one is to
| transfer the current page to another app/person
|
| I have to admit I don't see where to put the "search
| inside the page" feature, definitely some ux trick to be
| found
| makeitdouble wrote:
| The worst part of this is it's the last item in the
| autocomplete list, and will often be under the keyboard,
| off screen until we scroll to it. It also hides the
| current page behind the list of course.
|
| All in all, text selection and search is still such a
| second class experience on iOS.
| [deleted]
| isametry wrote:
| You're not wrong, however they've actually been cutting
| down on that lately -- moving the items which aren't really
| "sharing" in any sense to a kebab / ellipsis.
|
| The best example is Photos, where the Share Sheet would
| have a LOT of unrelated junk -- Duplicate, Hide,
| Slideshow... But as of one or two major versions ago,
| there's now an ellipsis menu to keep those options instead.
| Notes got the same treatment.
|
| In current Safari, the "aA" menu is an equivalent of that.
| In my opinion, "Find on page" is really the _only_ option
| on that Share Sheet which doesn't really belong. All the
| others make sense, as they're an "Export" of the page in
| some way or another.
| fiddlerwoaroof wrote:
| I disagree, the "share screen" is the logical place for
| actions that operate on the object you're currently looking
| at. Adding a new banner or something for installing PWAs
| would just clutter up the UI and make it less consistent.
| Gigachad wrote:
| I don't think it's strictly bad to have a junk draw menu,
| but calling it a share menu doesn't really describe what
| it is.
| saagarjha wrote:
| Its official name is not the share menu, if that helps.
| testTED wrote:
| DRAWER, it's a drawer.
| rahoulb wrote:
| Somewhat off-topic but as someone who used to be a very
| heavy iPad user (the M1 Mac has kind of obsoleted it), I
| think of the share sheet as the equivalent of a Unix
| pipe. It takes your current view or output and makes it
| available to another process - and if you use Shortcuts,
| you can actually see the data and its transformations
| along a literal pipeline.
|
| So, back on-topic, it does kind of make sense in that
| you're taking the current URL and sending it to the
| Springboard.
| pprotas wrote:
| A perfect menu already exists for this. If you click the
| "Aa <puzzle piece" button, a bunch of website-specific
| settings pop up. "Search on Page" or "Install on
| Homescreen" would fit in perfectly here. Maybe under
| "Translate Page".
| fiddlerwoaroof wrote:
| This is close, but it's not ideal: the drawer is an OS-
| wide feature, that puzzle menu is a relic of when the
| drawer didn't exist. And its symbol suggests that it's
| about text options.
| ursuscamp wrote:
| This is really great news for the Lightning network, if that is
| your thing. There is a Lightning wallet, called Mutiny Wallet
| (https://mutinywallet.com) which is an entirely web-based
| Lightning wallet/node (using WebAssembly, etc) under development.
| A Lightning wallet PWA is a great boost to censorship resistance
| because no one can be cut off from their money because of
| oppressive government or App Store policy.
|
| One of the challenges of Lightning usability on mobile wallets is
| sending payments when there is no guarantee that the user's
| mobile wallet is getting the CPU time necessary to receive the
| payment without having the app directly open. Allowing push
| notification for PWA is a potential way to make sure that a
| user's wallet gets some CPU time for incoming payments!
| 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...
| JimDabell wrote:
| Web Bluetooth is not a web standard. It's something Google
| implemented by themselves that no other rendering engine wants
| to adopt. Both Firefox and Apple have explicitly rejected it.
| 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.
| donbrae wrote:
| Even if/when we get the Blink rendering engine in iOS Chrome,
| I think Apple will still prohibit access to certain features
| like Bluetooth if they consider it a security or privacy
| threat. Are Web Bluetooth, Web USB etc. even considered part
| of Blink, or are they part of Chromium?
| 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).
| MatthiasPortzel wrote:
| Linux builds of WebKit provided from
| https://WebKit.org/downloads.
| 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
| chrismorgan wrote:
| > _Just be sure to allow URLs from *.push.apple.com if you are in
| control of your server push endpoints._
|
| Wait, why would anyone be doing any sort of whitelisting? That
| seems a disastrously bad idea that utterly ruins
| interoperability. I could understand checking that the IP address
| the URL resolves to isn't private, but what they've written
| suggests something much broader.
|
| Am I missing something, or have they gone off the deep end, or
| are they reacting to implementers that have gone off the deep
| end?
| 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.
| joenathanone wrote:
| Is isn't noticeable at all if the app is built correctly.
| My app is used by health care professionals to log their
| hours and patient charting. Everything is instant when
| clicked and the app also has limited offline
| functionality. It's snappier than most mainstream native
| apps. Everything is native HTML 5 & CSS with very minimal
| javascript to handle logic and validate inputs.
| 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.
| threeseed wrote:
| Users can tell.
|
| That's the whole reason for why the last 15 years of
| trying web based apps have failed.
| 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.
| IceHegel wrote:
| This starts very defensively, pretty clearly hitting back at the
| idea that iOS has been intentionally holding back the web.
| 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?
| MBCook wrote:
| Compared to other OSes people update iPhones _really_ fast.
| Apple really encourages updates (new emojis!), including
| automatically updating things unless you stop it.
|
| Given this is public beta one we may see the release near end
| of March (total guess on my part). Point releases don't tend to
| have too many betas. And Apple ID itching yo get the HomeKit
| new architecture bug fixed soon and that's in 16.4.
| 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.
| pacomerh wrote:
| It's not intuitive and most users won't find it. I honestly
| didn't think Apple wanted the web to succeed, so I was
| surprised when Jen Simmons joined but it seems like she's
| moving the needle!.
| 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]
| musictubes wrote:
| In Apple parlance I believe they call it the action button
| not the share button. If understood that way adding to Home
| Screen is easy to find. The fact that so many people on HN
| keep calling it the share button means that Apple hasn't
| communicated the concept very well.
| intrasight wrote:
| I Google "ios action button" and find nothing. I google
| "ios share button" and screens full of the button we're
| talking about. So regardless of "Apple parlance", this is
| the "share button".
| 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]
| nlitened wrote:
| So you're saying that you'd like to send web
| notifications to users who aren't "technical enough" to
| add a website to their home screen? Surely then they are
| also not technical enough to unsubscribe from these
| spammy popups. I am glad that Apple protects my mom from
| this nightmare.
| afavour wrote:
| How is any of this different to native apps, though?
| 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)
| JustSomeNobody wrote:
| Is there a complete example app that demonstrates all of this?
| 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.
| laurencerowe wrote:
| It's a shame Safari on Mac still does not support web apps at
| all. I'd really like to have Gmail and a Twitter web apps that I
| can separately command-tab to.
| spectre3d wrote:
| Does Fluid[1] work as a solution for you?
|
| I'm on an older OS with an older version but I love it for
| creating single-site apps.
|
| [1] https://fluidapp.com/
| exoque wrote:
| I recently switched to an iphone, the state of PWAs on iOS is
| just pathetic. While I don't care about web push, I'm really glad
| they're trying to make some progress in this area.
| wackget wrote:
| Sorry but this is basically worthless until there's a MUCH easier
| and more visible way to add websites to your home screen.
|
| In a perfect world you could submit your PWA-based site to the
| App Store where it would appear alongside native apps and be
| discoverable in search results etc.
|
| But that'll never happen because Apple has way too much to lose
| from allowing developers to create genuinely cross-platform
| solutions. They need developers to be absolutely married to their
| ecosystem so that the users will be too.
| leadingthenet wrote:
| Ah, I was waiting for the first goalpost shifting comment. I
| had to scroll uncharacteristically far for an Apple thread to
| find one, and you're the lucky first!
| 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
| BluSyn wrote:
| > Added WebRTC support for hardware AV1 decoding on supported
| device configurations.
|
| Currently no Apple device has hardware AV1 decoding, so why
| support it in Safari iOS Beta? Perhaps next CPUs (A17 and M3)
| will have dedicated AV1-decoding hardware? Either way I think
| this is a hint it may be supported soon.
|
| Great news!
| [deleted]
| MBCook wrote:
| They may still be able to offer optimized decoding with
| hardware support on older devices. Not a full hardware path
| but a very well optimized CPU + hardware combo.
| latexr wrote:
| > Could this be the first indication of Apple warming to AV1?
|
| That was half a decade ago, when they joined the Alliance for
| Open Media: https://9to5mac.com/2018/01/04/apple-alliance-for-
| open-media...
| fuckelonmusk wrote:
| [dead]
| brrrrrm wrote:
| > huge for the progress of WASM
|
| HUGE! 4x speedup for anything parallelizable. This should bring
| around ~45GFlops out of the box in the iPhone browser, which
| isn't much but easily enough for basic neural networks (think
| object tracking, background segmentation, face feature
| tracking). For comparison, WebGPU would get that to ~1000GFlops
| hajile wrote:
| This is huge for CPU workloads that need intermittent
| parallel processing.
|
| A great example would be JSON parsing in WASM apps where SIMD
| algorithms result in massive speedups.
|
| Another example would be a WASM software decoder could allow
| AV1 playback content on iOS browsers.
| fayazara wrote:
| Great addition.. I hope they soon add the install prompt and
| remove the stupid border dragging/pulling from safari.
| astlouis44 wrote:
| Amazing, about time!
| MBCook wrote:
| Web push, badging, saving to the home screen from other browsers,
| and lots more.
|
| I can't wait to hear 6 months from now how the goalposts have
| moved again and some other feature no one ever complained about
| is now what Apple is using to destroy PWAs that would be ultra-
| popular if Apple would _just add support_.
|
| It happens every time.
| quitit wrote:
| Something which developers have widely refused to embrace
| despite being pushed by Steve Jobs himself during the iPhone
| keynote. Yet somehow it's always Apple holding it back with
| their magical minority market share.
| MBCook wrote:
| There have certainly been functions that were necessary for
| _some kinds_ of apps, but there are possibilities for kinds
| of PWAs that would have worked for years on iOS (and Android
| /desktop) but they barely exist if at all.
|
| Unless some (unknown to me and possibly everyone) change
| happens and PWAs explode in popularity... there's going to
| have to be a reckoning that end users just don't seem to
| care/want them.
|
| They can still be useful but the dream of abandoning the app
| stores (due to PWAs) just doesn't feel realistic to me.
| JimDabell wrote:
| People have forgotten what a big deal that keynote was and
| what it meant for the mobile web. Go back and pay attention
| to the "desktop class web browser" stuff. Apple almost
| singlehandedly changed the mobile web from something almost
| nobody wanted, into something actually useful and mainstream.
| And Steve Jobs was there right from the start telling
| everybody if they wanted to build applications for the
| iPhone, they should be mobile web applications. It was
| everybody else demanding that iPhone applications be native,
| not web-based.
|
| Before the iPhone was released, a typical mobile web
| experience was a separate site that barely worked and didn't
| use any normal browser technologies. Along come Apple, who do
| a tonne of work to make their open-source WebKit work well on
| mobile, and virtually overnight all smartphones adopted
| WebKit to catch up with them.
|
| Anybody who doesn't think Apple has done more to advance the
| mobile web than practically any other organisation should be
| forced to build WAP/WML mobile sites until they repent.
|
| They didn't do it _alone_ of course - WebKit was originally
| based upon KHTML, and I believe Nokia also had a WebKit-based
| mobile browser. But Apple put a tremendous amount of work
| into it and the dramatic shift from "the mobile web is shitty
| and worthless" to "the mobile web is actually useful"
| happened almost straight away as a direct result. Nobody
| wanted mobile websites / mobile web applications before the
| iPhone came out, then all of a sudden it was a normal
| requirement for a site to work well on mobile.
| BeFlatXIII wrote:
| > magical minority market share
|
| This phrase is far more prescient than most people think.
| Yes, it's a numeric minority. However, they have a near-
| monopoly on _profitable_ users. 13% of the global market and
| >50% of the profits.
| 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.
| mertens wrote:
| Good to see Apple finally making some effort to support PWAs, but
| as a user it's still very cumbersome to actually add a Web App to
| the homescreen (compared to Android).
| 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.
| SllX wrote:
| At this moment of time, there aren't any non-WebKit browsers
| available in the App Store, so "third-party browsers" in this
| context means "WebKit browsers".
| MBCook wrote:
| Yeah but 3rd party engines would be a _huge_ deal.
|
| Apple would never let that slip in a WebKit update post.
|
| It would get a 'real' announcement somewhere. Keynote
| slide, iOS features page, App Store rules update, flat out
| press release, etc.
___________________________________________________________________
(page generated 2023-02-17 23:02 UTC)