Keep Reading
If you enjoyed the post you just read, we have more to say!
Let's begin this discussion by unpacking the phrase “web push notifications”.
Push
Typically, on the web, information is provided to the user on-request. That is to say, it relies on a pull based protocol - the user (i.e. the ‘client’) “pulls” the information in when they want it.
A push based protocol is different. The server, not the client, determines the timing of the information transfer. WebSockets are an example here. They make features such as instant-messaging possible, preventing the need for the user to keep refreshing the page in order to see the latest state of the chat. So long as the user has the page open, the UI will reflect the current server state thanks to the server pushing updates as and when they occur, rather than waiting for the client to ask for them.
Push notifications
Push notifications are the natural choice of UI for when 1) there is time-sensitive information in the user’s interest that hasn’t been explicitly requested, and 2) the user doesn’t necessarily have the application UI open in order to see the live updates come through. So long as time-sensitive information requirements exist, and so long as your users have other things vying for their attention than to stare constantly at your application UI, notifications will be a necessary form of communication.
Notifications are arguably a more natural form of communication on mobile than on desktop. The key justification for carrying a device in your pocket around everywhere you go is in order to stay receptive to timely information. Otherwise you would leave it at home. Ringtones are to phone calls, as notifications are to information more generally.
So those are push notifications; a form of information transfer that is particularly prevalent and/or natural on mobile. What are web push notifications?
Web push notifications
Ask yourself: of the notifications you have received today on your phone, how many were sent by native apps (i.e. downloaded from App Store in case of iOS, or Google Play store in case of Android). The most likely answer right now is “all of them”. That is to say, the ability to send users push notifications has typically been an affordance enjoyed only by native apps.
What if I told you that websites could send push notifications on mobile, including iOS?
As a web-developer and iPhone-owner myself, I would say that this sounds a lot like good news. I love developing for the web. I love the fact that for the most part, I don’t need to worry about what operating system a user is running or what other software they have installed, only that they own a modern browser with which to view my link. Startups love it because it is a natural distribution platform - think how quickly Figma took over the design world all thanks to the power of the web and the simple “shareability” of URLs. It’s thanks to the web that I am communicating with you right now. I don’t know how to write Swift, or Objective C or Java, and at this point I’m not sure if I want to.
But at no point in my Javascript-dabblings did I ever expect to have any control over what appears on the lock screen of a user’s iPhone, for instance. If I needed to build some software that relied on timely communication with my users via mobile and required any kind of alerts, my first instinct would be to try something like React Native and interact with their operating systems directly.
In a somewhat under-appreciated move by Apple, for just over a month now this is no longer the case. Now, a user need only visit my website, click “Add to Home Screen” (thus turning it into a PWA) and a whole new channel of consensual communication becomes available to us both. A form of user interaction heretofore enjoyed exclusively by native app developers can now be enjoyed by me, a web developer.
See it in action
During my foray into this world of web push notifications and bleeding-edge iOS features, I built a demo that should serve as a simple proof-of-concept. You can run it successfully on desktop or Android, but it’s only iOS for which this represents anything particularly cutting-edge. I wanted to ensure that it included lots of instructions and feedback, and if all goes well it is likely to be the first time you will have ever received a push notification from a piece of software that hasn’t been pre-installed or downloaded from the App Store.
The code for this demo is also open-sourced here: https://github.com/magicbell-io/webpush-test. It demonstrates usage of the various Magic Bell client libraries that make this type of thing all the more easier - including a pre-written Service Worker precisely built for this type of use case.
Parting thoughts
What was Apple’s intentions in releasing this feature in iOS 16.5? Could this lead to less native apps being developed? If this article resonated with you, let us know your thoughts on Twitter @magicbell_io and let’s get the conversation going!