Hacker News new | past | comments | ask | show | jobs | submit login
Push Notifications, WebXR, and better PWA support coming to iOS (firt.dev)
254 points by carlycue on Feb 1, 2022 | hide | past | favorite | 90 comments



I'm excited to see support for Web Push. I realize that most people associate it with spammy sites asking for permission to send you notifications you don't want, but I think it hasn't really been given a chance because it lacks iOS support.

Some things that it enables:

- Low-friction asynchronous turn-based games (think “Words with Friends” but you don't have to install an app)

- Single-purpose alerts (like CamelCamelCamel) or stock alerts without cluttering your email inbox

- Easily scriptable notifications from your own code (I run notify.run which provides an HTTPS-to-WebPush bridge so you can send yourself a push notification from curl)


Just to add:

- Getting notifications from websites I want notifications from

This should not be impossible just because there are 5 trillion websites I don't want notifications from.


Exactly, why can't there be presets to set the trust level on websites?

- Hey, it seems like you want to use our notification feature, and we are delighted. For us to be able to push you messages, you need to set out trust level to "App", to do this...

I mean, nobody will open a menu and click on 3 things for a spammy website, but many people will do it for their favorite 3 sites.

- Clicking on this button will trust this website (example com) as an [App] and give it the ability to store information on your device, and send you notifications. Please don't do this for the sites you don't trust. [Cancel] [I trust this website]

Our grandparents can run random executable from the internet and with some common-sense training and scary popups from anti-virus and UAC, it is still risky but tolerable. This is way more secure and easier, why cant this work?

- You already trust this app (example com) and it can already store information on your device and send you notifications. Clicking on this button will add it to your trusted apps and allow it to ask for files stored on your device by other apps, and also allow it to ask to access your contacts. These permissions will be only available when you are actively using the app. [Cancel] [Add example com to trusted apps]

Please some browser implement this.


Edge exactly did that.

It collects feedback from users. If a site got rejected by literally every user. It will be put into the `don't even bother prompt the users` list.

And start from this point.

No edge user will be prompt actively by that site (There will still be a icon on the url bar. If the user really really want to enable it, he can click it himself).


FYI, that just buckets you into the "false-prompt" or "prompt-to-prompt" pattern.

eg: https://blog.hurree.co/blog/ios-push-notification-permission...


Do we know which sites are in that "no prompt" list?


Sounds like a ripe for abuse on a competitor’s site. How does Edge identity the reporting users?


Make it even simpler. If the website is installed as a Web App on your iPhone home screen (it has an icon), it can ask for and send notifications. It appears in your list of apps in notifications in Settings and can be fine-tuned that way.

You remove it from your home screen and the notification permission disappears.

The bugs related to notifications currently seen in the beta are due to this user interaction not yet being implemented I'd bet.


Except make it wayyyy more fine grained so I can give the app permission to store files but not send notifications or to access the files of one other app but not another. Something like Apple's fine-grained photos permissions would be good.


The problem is, that you can always "force" the user to allow you notifications or cannot proceed. And $GREEDY_MEGACORP would abuse their power and send you a "verification code" through the push notification, else you cannot process the signup etc.

The good thing about the Apple Appstore, that promotional/marketing push notifications are forbidden and will get your App banned from the Appstore. Just allowing generic WebPush on PWAs will result in companies requiring it with dark patterns, just to increase your "engagement" with their product (read: send you spam).

I have mixed feelings about webpush, I myself as a developer want it for my users, but I see the history of the web and how everything nice got destroyed eventually by spam.


As others point out, promotional pushes are allowed on iOS.

A site can refuse to give you content if you don't allow push notifications but in practice that doesn't happen because the incentive of the site is to have more traffic. Android has had this capability for an eon and I have never experienced a site try to force you to accept push notifications.

I have also never observed a site try to use push notifications as a "verification" method. Do you have an example of this in the wild?

And you can always control your allowance of push notifications after the fact, either at the moment you receive the offending notification or from the site settings. Android specifically has a fantastic way to do this without even leaving your notification area. Not sure how Apple's system works in that regard.


rottentomatoes is an example site that blocks if you have ads or tracker blockers


Plenty of sites lock you out if you have an ad blocker, here we're talking about locking you out because you have not granted them permission to send you web push notifications...


The argument IIRC is sites want eyeballs and wouldn’t block content if you don’t grant notification permissions. Blocking for Ad/trackers is not so dissimilar


They don’t make money if they don’t have ads and trackers. Push notification is just to get you to visit more often. Why would they want to serve the site to freeloaders


> that promotional/marketing push notifications are forbidden

Not anymore they’re not. It wasn’t enforced when it was on the books; last year the rule was removed. Even Apple advertise their own services via push now.


This problem is not a problem if you have incoming information filters, which email had for ages. You don’t have to have mixed feelings, just split it in two parts and have clear feelings of each.

The real problem is that corporations treat all users as idiots who can’t control their software. But a big part of them are not. These talks about users unable to setup their devices (or to get help from someone who can) is nonsense they want us to believe in. And I see signs everywhere that most of software-versed people already believe in it. Feels like seeing sophisticated math proofs, all based on 1+1==3 for some reason.


Can you though? Wouldn't it be enough to create interface that would let you view notifications of currently opened tab without giving it permission to show them through OS interface in background?


> The good thing about the Apple Appstore, that promotional/marketing push notifications are forbidden and will get your App banned from the Appstore.

Lol, no it won't.

Apple do promotional notifications themselves even.


I just wish that “web applications” were more clearly distinguished from regular web sites.

I hate that a regular website I may tap on a search result would ever want to send me notifications. But, if a site that is clearly more of an “application” to me (like an online spreadsheet or chat app, etc) wants to send me notifications, that could be a useful feature.

If there were a more clear delineation between the two, I could just avoid tapping anything that is labeled as an “app” in search results (or just ban them from my search engine), and restrict myself to “plain old webpages” only when searching. And “plain old webpages” would be even further restricted than they already are: No notifications prompts, no ability to see my accelerometer, no offline storage available, etc etc.

It’s nice that the web has turned into a viable app platform, but it doesn’t mean I want every page I visit to be allowed to have “app-like” capabilities. In an ideal world 95% of the web would just be plain old documents accessed over HTTP(S) and the “apps” would be distinguishable as such.


A great heuristic would just be only granting notification prompt permission after you’ve installed the PWA to your Home Screen. That shows clear interest by the user in a longer-term relationship with the app, and they could grant other expanded prompt permissions based on that also.


This will probably be the way it's handled honestly. I think it's the best option.


how it is handled, on modern devices, for years.


Most users never add a shortcut to the home screen and yet use plenty of web apps.


Apple could certainly do more to help people understand that they can install web apps to their home screen. Right now, it is an option that few users are aware of, buried in the menus as it is, and even fewer think about it.

When a related app is available in the App Store, Apple will show a big banner at the top of the web page encouraging you to install it... but they won't do anything for a PWA.

I think requiring "installation" of a PWA is a great way to balance the concerns people have about getting spammed with requests to spam you with notifications you don't want... but I also wish Apple would support PWAs better in general, so I can see it both ways.


I would find this type of differentiation useful as well. “Plain” sites are generally faster to skim through for what I’m looking for, (no gauntlet of spinning loading wheels and dialogs or JS gumming up functions like Find in Page) so it would be nice to be able to prioritize those in search results.

One way to do this would be for the crawler to compare the content of JS-enabled and JS-disabled states and if they differ dramatically, the web destination gets tossed in the “web app” bucket.


Interesting idea, but it sort of falls down in my mind when I think about forums. I want notifications for some forums that I join. And I certainly don't want to remove forums from search results. They're the only place you can get decent product reviews right now.


Hate to break this to you but even a website that consists of nothing but HTML (no CSS/JS) is still an "app". It's still being executed in the runtime environment of your browser when you load it. Just because the website chose to limit it's use of the features to just one (HTML) doesn't mean it's not an app (when executed in a web browser).

If you read that HTML in a text editor then yeah, that's not an app but if you're reading it in a web browser you're "running it".


I’d love to have a chrome person comment on the actual stats of web push usage because no non-developer I’ve interacted with has ever intentionally accepted push spam.

I think all developers think that their site is somehow unique in the value of their notifications, despite all evidence to the contrary.


I hope the prospect of iOS support will prod Google into finally fixing Web Push on Android. It is fundamentally broken right now. Notifications are routinely delayed somewhere between 10 minutes and several hours and there is no workaround. This doesn't really change its effectiveness for spam, but it totally destroys any utility for actually useful applications like messaging or timely alerts. Which is why you have only seen spammers using it so far.


>- Easily scriptable notifications from your own code (I run notify.run which provides an HTTPS-to-WebPush bridge so you can send yourself a push notification from curl)

The article speculates that it might not be freely available like push notifications are for firefox/chrome.

>Maybe we have to register the origin with the Apple Developer Program, similar to the Safari Push Notification program for macOS. If this is the case, the developer will have to pay the annual Apple Developer Program fee to send push messages to their web users.

In that case you're probably better off installing a notification app from the appstore to handle it, eg. pushover/pushbullet.


I don't get push notifications. If I don't have time to poll your service, I don't have time to respond to a notification. Besides, I'd rather not have my priorities determined for me.


That really depends on the service. If it's a messaging app, then I'm not exactly going to poll a service until a new message arrives. Or any other type of app that I'm not checking if there's no updates.


I suppose async communication with another person makes sense.


If Apple do do this, which I'm not certain they will, I imagine they'll be very restrictive on the permissions. Can only prompt to be enabled from a direct user action (eg a button click), and the latest iOS notifications prompt quite often if you want to keep them or stop them.


It does not work right now and probably will require Apple whitelisting your website.


So, once this is integrated clicking a link will have the following experience:

1) Tracking preferences overlay that will have a wall of text with "Accept all" and "Customise" buttons that would not be clickable the first few tries.

2) Then you will have a modal that asks for your e-mail address so you can receive the newsletters from the website that you are trying to understand what is this all about.

3) And now you will have a prompt that asks you if you like to receive notifications.

4) Once you are done with all this, half of the page will be covered with links and menus to the other parts of the website and when you scroll menus and overlays with call with action will appear and disappear

5) The rest of the website will be ads.

6) Hopefully somewhere there will be an image or paragraph, you will be able to find it if you still remember why you click on the link

7) if you scroll a bit too much the screen will be blacked out and a call for action(sign up for a newsletter, create account, download the app or buy something) will appear and will have hard to identify close button that won't be working the first few taps.

My point is, the Web is not a garbage because Safari lacks notification or something like that and it is not salvageable without finding a new business model.

Wouldn't be great to have a notification once the new Wordle of the day arrives? Sure. But the business model of it appears to be selling it to the people who love all the steps from 1 to 7 listed above. I don't blame the creator of the game, it's just a testament of the state of the Web business.

I prefer apps for that reason. They also seem to be riddled with full screen ads(especially the casual games are horrible) that make your phone warm BUT you get yo see a high quality screen(App Store, Google Play etc.) where you can read reviews, description and see screenshots before committing into installing the app(Unlike the web apps where you first "install" the app and then you are on your own to figure out what is this all about).

Besides the questionable practices of Apple/Google, there's barely any reason to have browsers with PWA capabilities. I would love it if the web browsers had JS off by default and load JS only when the user explicitly requests it.

Most of the noise comes from Web technologists don't want to learn anything beyond JavaScript.

I hope Apple doesn't cave and if they do, I hope they implement it in a way that improves the experience of the USER. If I wanted an Android experience, I would have used an Android phone, let's keep the iPhone experience like a iPhone experience.


> Most of the noise comes from Web technologists don't want to learn anything beyond JavaScript.

I agree with a lot of what you wrote, but not this. PWAs are the only path for allowing open publishing of apps that is not gated by a large tech firm. While I completely understand the value proposition of app stores, there are tons of app scenarios held back by them. Two instances are small web[0] and situated software[1] as app stores keep people from publishing apps meant for small audiences by their very definition. Both of these fall under your desire to maximize the user experience.

Furthermore, PWAs are the closest thing we have to a “universal” platform. Personally, if I could write an app that worked on all mobile devices and the web in COBOL, I’d be thrilled to write “PROCEDURE DIVISION” every day.

The web is a mess because it is open. The web can be scammy because some people are scammy. Restricting PWAs doesn’t mitigate scamminess - it just restricts openness.

[0] https://ar.al/2020/08/07/what-is-the-small-web/ [1] https://www.gwern.net/docs/technology/2004-03-30-shirky-situ...


I wouldn't call PWAs universal platform when they are very dependent on Google being nice with Chrome. Also, browsers already have integrated blocking mechanism that is supposed to block out phishing sites etc. but that's only the case because so far the browser infrastructure operators(Mozilla, Google, Apple) are acting nice. The Push notification infrastructure is also possible only because the browser infrastructure operators are being nice so far.

At any point Google or other browser makers can choose not to be nice or can be compelled to follow regulatory orders.

The only universal thing about PWAs is the availability of Google Chrome to all major platforms and that's up to the courtesy of Google. They may choose not to do it at any time, they may choose to discontinue their push notification backend just like that.

Browsers are not standalone apps anymore, they are dependent on the backend services of the browser company. That's especially important when they need to run PWA.


> very dependent on Google being nice with Chrome

Replace Apple/Safari+Google/Chrome with Google/Gmail+Microsoft/Outlook and you currently describe e-mail. That situation is still preferable to the tons of messaging walled gardens. And the web is getting new feature albeit slowly and unevenly in a way that mail is not.


> Wouldn't be great to have a notification once the new Wordle of the day arrives?

Nitpick, but for that specific example, not really, since it's always at local midnight according to your device's time setting (for certain values of "arrive", since all past and future wordles are always present in the page source).

[EDIT] Oh and:

> Besides the questionable practices of Apple/Google, there's barely any reason to have browsers with PWA capabilities. I would love it if the web browsers had JS off by default and load JS only when the user explicitly requests it.

I think the biting of the apple, if you will, for the web, was allowing Javascript to ever initiate requests on its own, or modify e.g. post request content or URLs pre-flight without user review and explicit OK. It's fucking absurd that clicking a link to a site means it gets to track your mouse movements and send them, live, to some server somewhere, and that disabling that means wrecking most of the web and making it a pain to use. No transmitting data without explicit user action and review, I say.


I really want to see PWAs become a viable option for distribution, but you do have a point. I sometimes end up on websites using my iPad where I can't even read the content. I wonder why the company would publish a site so poor that it seems like they didn't even try it on an iPad and then I remember they've already gotten my ad impressions, so they've gotten everything they want and don't care if I get to read the content.

I don't think those sites get penalized much either. I arrived via search or a link and they don't get demoted in search or have that link removed. I can't flag them as being a bad site or "take back" my view. I find it very frustrating.


Sounds almost too good to be true, but here is hoping for the best.

> Opus audio decoder (enabled)

Considering the track record of codec support, I bet it only works when packaged as CAF, singed by QuickTime, and played during the daytime to a limited audience... I joke, but the amount of gotchas I encounter while working with WebAudio API is mindboggling and reminiscent of good ol' days of IE6. Would you guess that despite all three browsers declaring support for audio recording (MediaSource API) and all three supporting opus on paper, there is no way to produce the same opus file in all three? Safari only supports playing opus in <audio> tag, no recording; Chrome doesn't support ogg, and while both Chrome and FF allow you to record opus in webm container, the resulting file is not seekable... There are of course third-party solutions, but it's just sad to watch in the century of the fruitbat.


I just spent the weekend banging my head against the wall trying to record and upload audio in Safari. Chrome and FF were relatively easy. Know of any good open source examples or documentation on how to do this?

It really is sad that something so simple is so hard. I refuse to pay 10 cents a minute to a third party.


In the end, I went with this library for now: https://github.com/chris-rudmin/opus-recorder

There are issues reported with the latest iOS, though.


> in the century of the fruitbat

Off topic, I know, but what in the world does this mean? I did a quick search and couldn't figure it out.


A common reference to the modern (ergo enlightened) age in Terry Pratchett's Discworld series: https://wiki.lspace.org/Century_of_the_Fruitbat

Sorry for the confusion, I'm high on caffeine.


It's a Terry Pratchett/Discworld reference.


It's lovely to see Safari on iOS getting some attention, but I would love it if they fixed some of the long standing bugs such as the incredibly annoying text selection / caret issues with scrolling.

If you have a textarea or input inside a `overflow:scroll` and scroll it out of view or have a `position:fixed` element over it, the text caret or text selection hi-light remains visible outside/above other elements. It's incredibly frustrating for developers of PWA and apps built will frameworks touch as Ionic - it result in text carets and selections being rendered over the top of toolbars and menus.

Effectively the text caret and selection hi-light are drawn above all elements on the page with no detection as to if they should be hidden behind an element or are outside a visible scroll area.

https://bugs.webkit.org/show_bug.cgi?id=138201

http://openradar.appspot.com/18819624


my transactional emails aren't rendering correctly in Gmail on iOS. there's no stylesheet, no floats, no grids. just some vanilla ass 1999 html and inline styles and they are still fucking it up with their embedded WebView


Funny enough, apps were supposed to be just for Apple. The original conception is that 3rd party tools, games, etc. for the iPhone would just be webapps. (https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-..., etc.)

A few adjustments to the model and here we are with lots of native code and big money... but still, folks requesting updates to the the browser to support more app-ish functionality. I'm glad; the browser can do a lot and we kind of miss that in many mobile contexts.

I also think the elusive "run almost anywhere" is viable in many cases when the browser gets powerful enough. (Of course, I said that about the JVM years ago, so what do I know?)


It was also kinda weird because when they announced "the solution is web apps!" they made a big deal that developers could make their web apps just look exactly like native apps. But they never actually released any SDK, stylesheets, or anything to achieve that. In reality everyone had to mimic the look through CSS on their own, and even write absurdly complicated JavaScript libraries to emulate the scrolling.


I guess the main difference is JVM didn't have a workable UI vs the web?


You had to install the JVM. It often broke or bugged you to update. UI usually felt off or janky, and unresponsive. At the time, Java applets were huge compared to typical web pages, and had crap performance. By the time hardware and connections improved enough to make the last two things less of a problem, JavaScript could do most of the useful things the JVM could with fewer security risks (and hardware was fast enough that that wasn't also so slow that no-one would tolerate it, as it would have been earlier).

[EDIT] Oh, and it had to compete with Flash and Shockwave, which had (barely) fewer issues with plugin breakage, very nice authoring tools (still unmatched, AFAIK?), and, despite having crap performance, still performed better than Java applets. Plus a whole lot more fun things used them so normal people had a motivation to install them.


You could do a working GUI with the JVM. But most people demanded Windows desktop apps, and for Windows only you could use .Net and C# for a better experience. Linux community was in big part against Java or Mono because of license and FUD so Python was the winner for the higher level language there.


Firstly let me state that yes, you could make a GUI with Java but it would suck because the GUI toolkits available at the time were just downright awful (and they still are!). Want an app that's super bloated and looks awful (no native controls)? Use Java!

Also, the Linux community wasn't against Java per se (not until Oracle bought Sun anyway) it's just that writing Java was a huge/complicated undertaking compared to say, Python and managing JREs was a huge pain in the ass. The old joke was, "By the time you have Eclipse open I will have completed the program in Python."

Lastly, mono was enormous (and still is)! Talk about bloated! When mono was being most actively pushed on the Linux community back in the day there was just no benefit: For smaller things you had shell scripts and Python. For larger programs you had C/C++, Java, and... Python :D. Why would you go through the hassle (and it was a huge hassle) of using mono when those other languages provided better performance with much lower friction/barrier to entry? It didn't have much of a "selling point" as it were.


From my memory there were anti-mono communities, and anti mono packages that would force a conflict with mono to help people not install mono by mistake. It was not "use Python over C# because Python is better" the message was "Do not use C# because the language is open but the .Net frameworks is not open" and this is true, Mono implemented non open stuff and Microsoft did not offered a guarantee that they support Mono and won't cause troubles from companies using it. Fuck MS, they had a good language and a decent platform in .Net and Silverlight but they had to prioritize what Windows team wants to we are now stuck with JS and Electron.

Sure Java apps start slower then C apps but I am talking about Pro apps, an app you start in the morning when you start your job and close it when you are done, I don't care is a bit slower. I am also playing games in Wine and when I have foudn modding tools in Java that work natively in Linux I thank in my mind the dev that he was not a Java hater.

But yes, Linux communities most of the time did not care to have theyr apps to work or look native in Windows. So today if I would like to make a quick and dirty Linux app with a simple GUI I am not sure what to use, maybe Electron it would probably give me less issues as a dev(but this is personal opinion since I dislike Python syntax and I don't like to go low level if I don't have too)


why would the JVM be involved?

Literally the expectation was you'd be a web app - html + js.

Everyone said that wasn't acceptable so they added native apps, and now everyone says native apps are terrible and everything should be web apps. It seems like apple can't win.


Given how quickly the App Store was introduced (just one year later) I’m betting that they never had the intention to go web-app only. They probably only needed extra time to figure out the experience for both developers and users (from native APIs to permission model to monetization)


Actually, incorrect. According to court documents released from lawsuits, Apple in fact did not plan for the App Store initially, just like Steve Jobs said on stage. It was not until a few months after the iPhone was released that some internal employees convinced Steve to let it go ahead and release an SDK. I can't find the tweet containing a copy of it, but the actual email where Steve gave the SDK a go is on the public record.


And what Steve said at the time remain true to this day, there will be two type of Apps, those that get on the App Store with Native performance, and HTML5 Apps without the need of Apple Approval. That was actually asked in an interview in D8 about the power of App Store, before smartphone was ubiquitous. And yet somehow no one at Apple knew what to do after his death.



I was going to write 10 years too late, but I decided to look it up.

I'm proud to announce i was wrong. It's actually 15 years too late, since it was promised in 2007.

https://en.m.wikipedia.org/wiki/Progressive_web_application

I suppose increased regularisation worldwide has something to do with it to announce it again.

I'm curious which features they will lag now...


I really hope the WebXR API stuff will come with support for VR headsets in Safari on desktop, and that whatever Apple's rumored VR headset end up being will also support it.

WebXR has been great for my app at work, but we're basically locked into the Quest 2 right now because Mozilla dropped the ball on WebXR support. Oculus is the only one doing significant VR work with WebXR in their Oculus Browser, which is a Chromium build that they keep proprietary.


Agree - WebXR is mostly off peoples' radars, but if at least two vendors end up adopting it well, it will have massive long term consequences (good ones) for the democratization of VR and AR.


There is also no mention yet on Apple support for glTF file types which is important to keeping an open web based XR ecosystem.


There's really no need for that. WebGL and WebGPU have no concept of file types. Whether it's Wavefront OBJ or COLLADA or glTF or some jankasaurus of JSON loaded out of a database, WebGL isn't going to and shouldn't have to understand it natively. It's on the app developer to translate that to vertices, texture maps, etc. And that's going to change a lot depending on what sort of abstraction layer you're using on top of WebGL, e.g. Three.js or Babylon.js or whatever. If anything, having native support for specific 3D interchange formats would constrict and over complicate the available options to app and 3D framework developers.


glTF can be rendered by the libraries, I think native glTF support only matters if you want to display it isolated and natively in the browser with nothing else, like an image. Which is not really a use case for VR.


On the one hand, web push is a welcome sight and I really hope they gate it a little (only allowing if you installed the pwa, explicit permission et ) and had some solid spam reporting for end users tied to apple dev. credentials to keep it a pleasant ux for customers and not a spam channel.

On the other hand, not jazzed to have debug what they managed to break in indexedDB this time round...


Honestly, it's about time we got push notifications in Safari. It was a really annoying missing feature, and meant I had to pay Twilio to notify the iOS users of my web app. Hopefully that'll soon come to an end.


As a user, I hope Apple doesn't just enable notifications as it is. I tried Android recently for 6 months and permission popups on each site were really annoying!


Given Apple, it'll probably be limited to PWAs on the home screen, aka. only if the user goes to the share sheet and hits "add to home screen", where then it'll pop up the permission for sending notifications.


That would be awesome! But given Apple, they wouldn't want people to circumvent their App Store. Push is probably the biggest reason people still make apps.


They know they're losing the App Store dominance, so they're going with the flow.


As someone who "hate" notification on web site. This is something I have been crying for 5 years on HN. Voices finally heard. Nice.


which actually makes sense, as there is a fundamental difference between "installed as an app" vs some random website spamming users.


I've waited years for push notifications to come to iOS Safari. This is wonderful news.


Same. I'm beyond excited. I thought we would never get them since Apple wants their App Store cut. Today is a good day


I really can’t see many use cases for web notifications apart from annoying sites trying to bug me. So I’m happy Apple haven’t supported it.


100% of "use" of it I've seen on the desktop has been spammy sites no sane person would ever want to receive notifications from bugging me to enable them because I made the mistake of clicking them in search results, and my wife accidentally enabling notifications from random sites, getting spammed, and having no idea how they've managed to do that or how to disable it. That's why I've hoped Apple'd never support them on iOS, and wished they'd never supported it on desktop.

As someone posted elsewhere in the thread, I hope Apple restricts requests to sites you've added as an "app" already. And I hope they find a way to keep sites from being able to tell you've "installed" them, so actually-useful sites or ones that I have no choice but to use (work, kids' school stuff) can't refuse to operate until I do that (I dunno, maybe they already do, I never "install" sites)


It makes [0]PWAs much more viable. Not having push notifications was a major blocker to make "almost native" PWAs. I'm excited

[0] https://web.dev/what-are-pwas/


Do you have notifications turned off in every native app you also use? The reason scummy linkspam websites are the "only" ones using web notifications these days is specifically because it's not a reliably useful feature. App developers who want to make a good user experience around notifications are instead pushed to making native apps instead.

Personally, I don't use the native Twitter app anymore. I use the web version of Twitter, installed as an app, complete with shortcuts in my launchers. I have web notifications turned on and the experience is nearly identical to the native app. But there are little details that I think make it a better experience, like haptic feedback on mobile when clicking the Like button, or being able to select subsections of text on the screen. I have this on my Android phone, my Linux laptop, my Windows desktop, and my Mac Mini. It's exactly the same interface, everywhere, whereas the native app is ever so slightly different from the web app.

I have a lot of sites that I've installed as apps on my computers and it's great: SoundCloud, LiChess, HBO Max, NetFlix, Azure Portal, TeamWork, a couple of different WebGL games, my own management interface for my app at work. It's all basically just a shortcut to the site, without the URL bar chrome. I like it a lot more than using tabs.


My users would like to be informed when they receive messages/notifications from my platform's PWA, so there's that.


I really want it supported, but I would also use it on most sites just like the pop-overs, cookie permission prompts, auto-play (and hover) videos, and paywalls—ie, to determine that I really don't care to use that site.


Is these enhancements limited to the safari browser? What about 3rd party ios browsers like chrome and edge? Also why does these 3rd party browsers not have extensions like safari recently got? Is Apple locking all these features down so they are safari only or is it edge/chrome that haven't implemented these features yet?


So we can hack AR in JS, in the browser, with a reasonable support in both Android and iOS ecosystems?



TLDR: there's broken/non-functioning push notification support in iOS 15 beta... and its disabled by default.

Nothing to be excited about yet.


Yes, but it is a major change of direction or a major accident for them to even put this in a beta build if they still have no intention of adding it.


Yet to use/enable web notifications on iPhone. It's not something I have been missing. Probably we will see the dreaded web notifications popups even on iOS




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: