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

That's a very very very shallow thinking. You are advocating to break the internet. You are destroying every internet protocol that ever existed. They all silently deliver information to devices you likely don't own.

Actually, we wouldn't need these dirty perversions with notifications if we had a proper background mode for apps. Like, you know, proper computers had for maybe 60 years.

Story time: Years ago the Signal app would silently wake up in the background, upload 20MB+ of my contacts’ photos, and then shutdown and do it all over again every time I received a silent notification. Due to my membership in a few large groups this was very often. The result was gigabytes of cellar data usage in a week.

Fortunately my experience was rare because I both had a lot of contacts with photos and I ran the desktop app. But it was infuriating to track down and it made me realize that silent wake ups were even possible on iOS. (Or used to be)

I don’t know what the right balance is, but I think there should be some middle ground.

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.

While waiting for it to be repaired, I bought a cheap Chinese phone to use as a backup - not sure of the brand but it cost £200.

I don't know what the fuck they did to the operating system, but notifications are completely unreliable. I think there's possibly some aggressive app termination going on, maybe for battery or memory usage. Either way, most of the time I would only get a notification once I open the app. Some apps seem to be more reliable than others - maybe due to whitelisting as you say.

In hindsight, Google allowing these no-QA phones to use the Android branding was a big mistake.

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)

1. Does your 85% delivery rate apply to FCM "notification messages" (displayed to user) or only to "data messages" (processed by app)?

2. Do some devices fail to deliver messages when your app is in the foreground? And does it happen often with US-based devices?

3. When the app is in the background, how long does it take for it to stop receiving notifications? I know the answer must vary by device.

4. How do you determine delivery rate of notification messages? I believe those are handled entirely by Android OS and app code runs only when they are tapped. I'm using Flutter and have not yet dug into the details of how Android processes and displays notifications.

5. Do you use FCM to deliver APNS messages?

6. How reliable are APNS messages to a foreground app for US users I'm considering launching iPhone-only.

My app helps people make appointments (dates). It uses notifications to remind users of their upcoming and imminent appointments. The backend detects when a user has not tapped a critical notification and sends them an SMS. This should reach the user even if they didn't see the notifications or they uninstalled the app without cancelling their appointments.

I also implemented real-time chat using FCM data messages with a slow poll fallback. If data messages are not reliable, then I will need to replace the slow poll with a realtime push service. That will be a significant cost in added complexity. I would like to put off that work.

I'm a solo bootstrapper. Working with Android and FCM has been daunting. Would you be interested in mentoring me a few hours a month? I can pay you. My email is in my profile.

On my android, most notifications disappear if I pick up the message on another device, but invariably my iPad notification center is full of rubbish I've already dealt with elsewhere. I mostly just leave the iPad in do not disturb and never check the notifications.