Don’t Build Push Notifications Yourself
At first glance, running your own Push Notification server for your mobile app or website might seem simple, but most developers find themselves in a deep pit of trouble.
Imagine this scenario: You’re a Flutter engineer at a mobile app startup. One day your product manager comes to you and asks you to build a system to send notifications to users when an item they follow goes on sale.
“No Problem”, you say, already starting to search on Github for an open-source library to help you do it. Happily, you see that there are two popular open-source projects to send notifications to both iOS and Android.
Like most developers, you’re more experienced in Javascript than Go. So you pick the popular “Smile-SA/node-pushserver” project.
Excitedly cloning the project and getting ready to deploy it to Heroku, you happen to overlook that the project hasn’t been updated since 2015. (Contrary to the “Mar 21” label in the screenshot. That’s just when the last issue was reported.)
Everything works fine…for a while. Then November 2020 rolls around and everything breaks. Sadly, you didn’t see the news that Apple announced they would be deprecating their old push API. Even if you had seen the news, you didn’t realize that the “node-pushserver” project doesn’t support this protocol. Uh-oh.
You quickly rush to fix the problem. With each passing hour, your app is getting bad reviews from your users. You switch to the next most popular project “appleboy/gorush”. This project is much more complicated, requiring running a Docker container, a Redis database, and learning how to set up and keep a Go service running. Thankfully, you get it working.
GoRush is a popular project with over 690 commits. Unfortunately, 95% of the commits have been made by just one, unpaid contributor.
Everything is fine for a few months until the contributor abandons the project. You hope that someone else will rise to take over. Sadly few people want to take on the responsibility of unpaid development of a complicated open source project with dozens of issues reported each month. [This example hasn’t happened, but it’s well within the realm of possibility]
Notification APIs tend to meaningfully change once per year, the clock starts ticking on another “node-pushserver”-style failure like the one you had before.
You briefly consider learning Go and taking on the maintenance work yourself, but quickly give up. You’re a mobile developer, not a systems engineer.
You start to look for alternate solutions and find Firebase Cloud Messaging. It’s not open source but it’s free. It supports both iOS and Android, and it’s owned by Google. “Why didn’t I use this in the first place?!” you exclaim, already creating an account. The process is smooth thanks to clear videos, example projects, and instructions.
One day your product manager runs over to your desk. “It’s broken again!” she exclaims. You realize that some of your most critical notifications aren’t reaching your users. Finally tracking down the cause, you find that Firebase is not correctly delivering notifications to user groups, or “Topics” as Firebase calls them.
After sending nearly a dozen bug reports via the Firebase support form they finally acknowledge the issue 5 days later. Relieved, you grab a coffee expecting it to be fixed from the Firebase team in a few minutes. Sadly, those minutes turn into 12 more days before a fix is rolled out.
During this 17-day period, your app has received several hundred 1-star reviews. Fortunately, the problem is now resolved and you hope for a better experience in the future.
A few months later you run into problems again. Some iOS users aren’t receiving notifications. You believe it’s an issue with the Firebase iOS mobile SDK and you report the issue on Github. You’re joined by several dozen other developers struggling with the same problem. The issue takes about 35 days for Firebase to fix. Meanwhile, you’ve lost the ability to message a large number of your iOS users.
“This was supposed to be simple,” you think, wondering where you went wrong.
This is crazy. Notifications should be simple. Nearly every application sends them, yet nearly everyone runs into the same problems.
We founded OneSignal after running into many of these problems ourselves when we were previously a mobile game studio. We needed something that would not only “just work”, but would also support essential features like segmentation, analytics, A/B testing, and integrations with third-party systems. Yet everything before fell way short of the basics.
We’ve seen many developers make the mistake of trying to run their own notification infrastructure, only to find it quickly crumble under load or fall behind technology changes. We’ve also had thousands of developers switch to OneSignal from other vendors like Firebase who ran into long-lasting service issues or unreachable support. We’ve finally made it simple for all developers to send effective notifications.
