Did you know you can put a whole game inside of a push notification

To help increase battery life, both Apple and Google provide a standard notification backend that keeps a single background connection open for every device and routes notifications to the device. Google and Apple require the use of their systems for push notifications (APNS and FCM).

BUT... Google's services are blocked in mainland China. So, developers in that region have resorted to building their own push notification systems. No single standard has emerged, so apps may use several third-party FCM alternatives or entirely develop their own.

Inevitably if you live in China and you have hundreds of apps on your device, with each one waning to keep its own background connection open, your battery won't last more than a few hours.

As a result, OEMs in China modify the operating system on devices they sell to prevent apps from having background connections open. Users are expected to manually go into their settings and allow specific applications to keep connections open. Sometimes OEMs will have pre-set list of popular apps that are automatically included.

If one of these devices is sold outside of China, it sees FCM in the same way as any other background connection and kills it.

Now here's where it gets crazy:

1. Many devices sold on eBay and in other channels are devices that were intended to only be sold in China. The seller modifies the operating system to add Google's services to it and changes the default language to English. These devices tend to be particularly problematic because sellers intentionally mislabel them as international devices, even though they are still running a modified version of Android intended only for phones sold in China.

2. Many OEMs have chosen to keep some of their background connection killing logic even in devices sold outside of China. It's hard to say precisely why. Maybe they are competing for higher battery life, or perhaps they don't recognize the problems that it causes. This logic usually does some combination of either killing an app such that it can't wake up to receive a notification, or it interferes with the FCM connection to prevent any app from receiving notifications.

3. Building on #2 -- Many popular devices (e.g. modern Samsung phones) will ask users during the onboarding process if they want to "put apps to sleep after three days of not being used", and the option is "ON" by default. Users often don't realize that this setting will break apps that set background timers (e.g.: alarm apps) or that need to receive notifications.

4. The modifications made by these OEMs are often buggy. For example, user settings get reset after updates. Or the operating system seemingly randomly kills apps in such a way that prevents them from getting notifications.

5. Since OEMs often allow some popular apps to get around these restrictions, it creates an unfair situation between different companies. For example, Facebook might always work fine, but an up-and-coming social network will run into reliability issues.

6. In some cases, devices will appear to receive a push notification but will not display it to the end-user. This can be related to either power management preferences or OEM-specific "do not disturb" preferences.

This is a great website with more information on this issue: https://dontkillmyapp.com/

(Disclosure: I'm one of the founders of OneSignal. We've been tracking and mitigating this problem by implementing "Delivery Confirmation", a feature that permits apps to send a webhook whenever the app displays notification so that developers can see the end-to-end delivery of each message and either retry their messages or use a different method of contacting the user)

Also: read markers. You definitely want notifications of messages you've read elsewhere to disappear from the iPhone. Currently, there is no good way to do that.

I wouldn't be surprised if OEMs had nasty tricks going on but the dontkillmyapp.com doesn't even mention the existence of these APIs and instead try to promote some auto-start apps on boot workaround believing that the service must be running? Giving me very little confidence in the rest of what they are saying. A lot of it has become more aggressive since each release lately so that could explain confusion for old app developers.