Originally published at: https://tidbits.com/2020/07/16/fig-brings-ios-push-notifications-to-discourse-forums/
Discourse-based discussion forums have become increasingly common, but until now, there has been no way to map Discourse notifications to iOS push notifications. Fig, a free Discourse client for iPhone and iPad, now provides that feature, along with a browsable catalog of Discourse communities and a unified inbox for your notifications.
This is very nice, but does anybody know if push notifications for iOS browsers will be a thing in iOS 14? If not, is it a feature that Apple is principially opposed to?
I don’t believe (nor have I noticed) any change in iOS 14 with regard to Web push notifications. I suspect Apple is opposed them on the grounds that such a feature should be limited to apps, perhaps because Apple limits what app notifications can do in some way that affects privacy or security. But that’s just a guess.
Far more likely because it would hurt their bottom line. If it’s really privacy or security related, then the fact that they let it happen on the Mac means they are not protecting privacy or security on the Mac.
If web apps were allowed to be full-featured, many companies that feel it necessary to have an app in the Apple app store wouldn’t feel the need anymore. Apple makes money by preventing people from seamlessly switching to Android. Native apps as opposed to web apps help prevent that. Apple makes money from apps being on their store. Web apps would allow people to bypass Apple to charge for app features. Apple even makes money from developers and companies paying their annual dev fee. Fewer people and companies would need to pay that if they could just use web apps.
I don’t mean to imply that native apps aren’t superior in some ways or that the ideal would just be web apps. I just mean that Apple has a huge vested interest in hamstringing web apps, and they have been doing so for years.
Push notifications are important for mobile devices, but much less so for desktop/laptop systems.
Why?
On a desktop/laptop system, it’s no big deal for an application to open a TCP socket and keep it open for an extended period of time. A remote service can write data to the socket at any time and the system of IP hosts, servers and routers that comprise the Internet will ensure that the data is reliably delivered to its destination.
On a mobile device, this is a very bad way to design an application. In order to maintain a TCP connection over an extended period of time, the device pretty much can’t go to sleep. One of two things will happen. The app will manage to keep the device awake and with its network hardware operating, resulting in high power consumption and reduced battery life. Or the operating system will force the app to sleep, causing the TCP connection to timeout - and data won’t flow if the socket is closed.
A workaround might be to switch from a “push” to a “pull” model where the app periodically connects to a remote server to see if anything happened. This works, but it wastes CPU cycles and battery if there is rarely any data to read. And if a lot of apps are doing this at once, it will keep the network hardware running constantly, resulting in battery drain.
And both of the above solutions can waste data (running up a customer’s bill) when connected to a metered network (like most cellular systems).
Apple’s push notification system is designed to avoid these problems. Notifications reside on an Apple server somewhere. That server collects notifications intended for a user and bulk-alerts apps about the data using a single message. I seem to remember reading that it uses the text messaging system internally where possible, in order to take advantage of the fact that the cellular modems in phones are already maintaining a persistent connection to the phone network, so it won’t create a significant additional power drain.
Anyway, this bulk delivery mechanism allows the Apple server to send one message to one system process. This process can then bulk-read the notifications from the server, cache them locally, and deliver them to their respective apps at appropriate times (e.g. when they’re not asleep).
It’s a great system, and its one that allows modern smart phones to work efficiently, given their extreme power and network limitations. But on a desktop/laptop computer where batteries are much bigger, AC power is often available, and network bandwidth (Ethernet or Wi-Fi) is usually plentiful (if not unlimited), it’s harder to make the argument that all the added complexity is necessary.
So the modern Android phones that have excellent battery life without crippling the browser are using witchcraft?
Wrong.
This means the only time code is run for a push notification (in other words, the only time the battery is used) is when the user interacts with a notification by clicking it or closing it.
Why the hostile-sounding response?
I never said a thing about Android. I never said Apple was the only company to have solved this problem. And I never said my understanding of Apple’s solution is the only possible way to solve the problem.
Based on the (extremely limited) description in the article you liked to, it looks like Google’s solution is doing something very similar to Apple’s - they are also forcing all notifications to arrive through a single common system process, which in turn dispatches it to applications only when the app is awake to receive them (possibly as a result of user interaction with the popup notification object)
The question is why doesn’t Apple allow notifications in web apps. I have an opinion. I think the answer is money. You presumably have an opinion, too. I thought I knew what it was. I thought your answer was “to improve battery life.” Apparently I was wrong.
At any rate, battery life is not a reasonable answer to the question.
I wasn’t talking about web apps at all, but in terms of native apps running on desktop systems. But since that’s what you really care about, here’s my thought on the matter, which is only tangentially related to Apple.
Implementing push notification for web apps has one serious problem - it needs to be cross-platform. You can’t require a web server to use one notification API for Apple devices and another for Android. You therefore can’t require the use of any kind of central notification-delivery server. You also can’t leverage the cell phone network, because the app needs to work on desktop systems and Wi-Fi-only mobile devices.
The Google link you shared is very short on details about how they solve this problem, assuming they did. I suspect they require use of a Google API that shunts everything through a single Google-hosted server pool whose identity is well-known and built-in to Android. This may be fine for Google supporting their own web apps, but it clearly can’t work as a web standard.
In general, Apple has been very strict about conforming to web standards. There are many cases over the last 20 years where Apple has deliberately chosen to not include popular browser features because they are not standards (e.g. proprietary features from Microsoft, Google or Netscape/Mozilla). My personal suspicion is that push notifications for web apps is one of these.
There is an IETF RFC for push notification on web pages, but it is based on a draft W3C API that has not yet been approved as a standard.
The IETF solution requires establishment of push servers that can act as a broker for notification delivery to browsers, much like what I described with respect to native apps.
But this approach doesn’t scale well. A standards body like the IETF or W3C is not going to mandate a single server (or pool of servers) for the entire Internet. They are (correctly) going to allow any number of service providers to establish their own notification servers which web apps may choose to use.
But when your browser starts using them, it (or the OS’s notification service) is going to need to maintain a network connection to each server used by each app. If users subscribe to notifications from many different apps and the apps all use different push servers, then you’re back to multiple persistent network connections. Again, this is not going to be a real problem for desktop/laptop systems, but it creates real problems for mobile devices.
This is actually a very hard problem and I don’t think the web development community has actually solved it. There are some proprietary solutions (like Google’s), but Apple has never been one to jump on the bandwagon. The only proprietary solutions they promote are their own.
I personally think Apple will roll out push notifications only after the W3C completes the standardization process so the spec will no longer be a moving target. Then they’ll implement something that conforms to that standard, whether or not it is compatible with Google’s services. Very much like they did when they refused to allow Flash (a proprietary Adobe product) on mobile devices and ended up forcing most web apps to move to HTML5 (a W3C standard).
No. This is a solved problem, and your suppositions about how it works are wrong. I run a website which (just like this one) offers push notifications to every browser on every platform except iOS. Apple simply doesn’t allow push notifications to iOS devices.
Edited to add: It’s been a completely solved problem for about 5 years now. Apple added it to Safari on the Mac even longer ago, back in 2013. No problems with centralization. No reason it would hurt battery life. For the best possible spin on why Apple is still refusing to allow it, you can read (an overly optimistic and generous post, in my opinion) here:
Edited again to add: Meanwhile, the “solution” is for us to create a native app for our website. But Apple refuses to allow native apps that are only a wrapper around a website without adding additional functionality. The only functionality we want to add is push notifications, but Apple doesn’t consider that enough of a reason to allow an app. So… Apple has completely blocked us from sending push notifications to our members. We can’t do it from our website, and we can’t do it from an app.
Since you are clearly an expert in this area, and you believe that everything I wrote is wrong, please educate me on how it really works.
What services are you implementing? What IETF and W3C standards do they comply with? What push servers are you using? Do you run your own or do you lease someone else’s? If you run your own, how do you avoid the problem of the browser needing to maintain persistent connectionns to your app server?
Basically, the company that wrote the browser runs the messaging servers. The messages are encrypted before being passed to them by the website. More here.