I'd prefer Apple to fix horrible notifications on iOS. Since they broke VoIP background notifications, developers have no way to reliably perform silent delivery of information to device.
For example in a chat app that syncs with desktop you can deliver incoming messages, showing them as alerts, but you can't deliver your own, because you MUST show alert on every push notification. Another use case is removing notifications: once you message on another device, you want to remove notification on iOS as well. With current notifications it is extremely problematic.
(Remaining background notifications in iOS work like shit - and please, do not start discussion that 'it is not needed' - It is BADLY needed, just ask anyone who has developer experience with this wreck)
We've also run an app with 1 million+ users for a few years, and I can confirm that notifications are a wreck on both platforms, but IMO even more so on Android/FCM.
In fact most of our calculations show that we have never gone past 85% delivery of high-pri Android notifications to valid FCM tokens. By high-pri here we mean direct chat messages in an active 1-on-1 chat conversation. This has caused many users to abandon the app since they assume the system to be unreliable. One of the main reasons seems to be that many Android phone vendors have simply whitelisted WhatsApp, Facebook and a couple of famous apps and then dumped every single other app into some kind of "kill if in background and completely forget about it" bucket. In some cases it can be fixed by asking the users to wander deep into the phone settings and toggle some switches. We brought the delivery rate from the low 80s to 85% by literally buying a bunch of the phone models we had heard had issues and trying to repro what was happening then popping up custom instructions for users like "looks like you are running this kind of phone which in general will not deliver notifications, please go to settings -> blah". But the whole thing has been a gigantic game of cat and mouse which really shouldn't be in the hands of individual app developers. In many cases the FCM system does not return any error code.
I'd be curious to hear if anyone here has achieved 95%+ FCM delivery rates on Android apps.
Until last week I would have been confused by this, but last week my Pixel 4 broke.
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.
Killing idle apps, including Services, is a feature in Android to conserve battery life and to give memory to Activities in more recent use. This might not be as noticeable on high-end-phones.
A lot of shitty written apps are not aware of this and think they can run some while loop in the background to poll their own backend 10 times per second. Eventually that will get killed.
The solution to this is the push apis, or for apps that truly need a background loop to present a persistent notification aka "foreground-service", so the user is aware something heavy is going on in the background. Hearing FCM, which is the suggested push solution, having delivery issues above is not very comfortable.
I'm developing an app with critical realtime notifications. Do you mind if I ask you a few questions?
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.
There are some well-intended reasons for this, but unfortunately, they've resulted in many problems that don't have simple solutions.
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.
(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)
Thank you for this! It seems like many apps on the growth path go through this same investigation, since we arrived at many of the same conclusions you did (down to calling our own webhooks from within onMessageReceived to retry, or figure out which kinds of devices had the most problems). We spent over a year on this before we hit what I think is our maximum achievable delivery rate of around 85% (short of repeatedly hassling users to go deep into their settings or forcing them to give us an e-mail/phone number to use as backup).
Our app isn't even enabled in China but the points you make in 1 and 2 mean that plenty of devices in South America, Africa, Asia (and even some in North America and Europe) run into these problems.
I think (5) above is a serious unfairness problem since many conversations turn to "I didn't get your notification, let's talk on Whatsapp instead" which affects retention. Now 10-15% failed notification deliveries might not seem like much but if you're talking to 4-5 people either individually or in a group chat then one of them is bound to pull you into a more "reliable" app.
Incidentally we've considered actually reaching out to those top phone providers and ask to be put on the whitelist; not sure if you or anybody on here has tried anything similar.
We've tried contacting OEMs about some of the more buggy behaviors we've seen related to their power optimization features. Unsurprisingly, even when we did get ahold of someone in the US who was senior enough to understand the problem, they had limited ability to influence the China-based operations of the company. Getting whitelisted seems nearly impossible unless you are a large company with a major presence in China and connections to the OEMs.
Google has hinted that they are working on something to improve the situation, but it's been years without resolution and the problem appears to have become worse instead of better.
Thanks for the link. I noticed some of these OEMs had started implementing their own "more reliable" PushKits, but I am guessing that the privacy implications are quite bad so it's basically a non-starter.
Yes. Also, for example, Huawei is not permitted to use Google Services on their new devices. As a result, they leverage a replacement called HMS and they replaced FCM with the HMS "Push Kit".
Privacy or not, it's the only way to send notifications to new Huawei devices that don't have FCM like the Huawei P40 that are sold worldwide. This isn't a niche issue -- Huawei was recently the #1 manufacturer of smartphones outside of China, surpassing both Apple and Samsung. Although this ranking has fallen as consumers have become aware of the lack of Google Services on these devices.
#3 shouldn't break normal apps (excluding these chinese notification solutions), it's clearly documented restrictions apps should adhere to on https://developer.android.com/guide/components/services, and https://developer.android.com/about/versions/oreo/background, with WorkManager and JobScheduler examples one should use instead. Are you saying OEMs go even deeper and interfere with these APIs rather than just stopping the background service and the process as they are allowed to, and some times must due to memory shortage?
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.
> as absolutely no one should be delivering information silently to a device they don't own.
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.
> 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.
It's worth noting, however, that desktop and laptop PCs have a surplus of energy relative to mobile phones, so it's no big deal if there's a bunch of processes running in the background doing their thing… usually, anyway, because on PCs it's also shockingly common for background processes to misbehave and consume far more resources than they have any right to. Point in case, the daemon for my Logitech mouse will sometimes consume 120% CPU for no apparent reason for extended periods if I allow it to run.
I could see an argument for extending background capabilities in iOS while also heavily also reducing their potential for bad behavior, though. For example, allowing apps to run in the background indefinitely, but on low power cores only with heavily capped CPU and memory consumption, along with a new Settings page that shows a list of persistent background processes and gives the user direct control over them.
Did you happen to not have an internet connection at the time? I noticed years ago Dropbox would spike CPU usage on my Mac when WiFi was off or couldn’t reach the outside world, like when on airplane WiFi but without paying for internet access.
Or, give people easy to use task manager that shows background processes, with big buttons labeled "kill", and "kill and keep down".
Android doesn't have anything like it either. It's my number 1 complaint about smartphone experience ever since I bought my first one: the phone actively refuses to give user insight and control over what's running on their device.
Recently, yes. Wasn't really the case for most of the lifetime of Android project, at least if my memory serves. Also even today, the application section is barely usable as it is.
Contrast that with e.g. the task manager on Windows. It's not a pinnacle of UI, but it's easy to use, communicates necessary information, and gets the job done.
In early android we had more insight and control over processes, but unfortunately we lost that supposedly due to abuse by apps (which seems highly likely)
I think the use cases for running in background indefinitely are so few that it's better to build special purpose APIs rather than general processing on low power cores with caps. The settings page would help but I think it is too complex for the average user to think about. Mobile phones are not PCs and we shouldn't be striving to make them more PC like, even if we can do so under mobile power constraints.
I think it may be best if there's a wide variety of battery capacities in phones, rather than a raised minimum capacity across the bar.
If battery power is universally plentiful, you'll get something of a road expansion effect where developers simply take advantage of cheap power and bloat apps to fill the added capacity, returning you to square one with phones struggling to last a day.
So with that in mind, the best case scenario may be for manufacturers to keep their current thin models but also introduce new ultra-high-capacity models, so apps are optimized reasonably well and users can take full advantage of the extra capacity.
I agree. User should decide, how he will use his battery power. If an app requires background running, it should be allowed to, with full control over data and battery used. That's all users need.
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.
Fun fact: Apple still allows signal, telegram, WhatsApp and few other high profile developers to use VoIP notifications without mandatory calling up VoiceKit. Because they can't work as smooth as users are used to they work with these new rules for notifications.
So, no, nothing 'improved' in your Signal experience. At least, not yet.
All developers are equal, but some are more equal than others.
On deaktops, neither windows nor dlinux do not behave differently depending on developer's name. I see no reason why mobile devices should be any different. I wonder if there are grounds for anti-monopoly lawsuits.
Windows absolutely does: it has a large collection of various hacks in place to detect specific applications to keep the running across newer versions of Windows. This is neat in a technical sense, but you’ve gotta be on Microsoft’s radar and worth it for them to put that sort of effort in for you.
On top of that, the partner support you used to get from Microsoft if you were a developer they cared about was orders of magnitude more helpful and useful than what you’d get if you weren’t a preferred partner.
I mean, if the apps is built for current windows, it runs and has all access to all APIs the system has for apps. So apps like Transmission will load after startup and will be seeding torrents in the background, you don't have to be on some special list to do that.
The Apple philosophy is “give users zero agency” – and from that stance, yes, this is a fix. But I remember the days when a computer program was either a game, an extension of the user's will or the BIOS; by that philosophy, this should absolutely be possible. (But computers have been artificially complexified to the point that this isn't viable.)
Why would you need to notify user of his own messages ? Can't you just do a sync pull once the chat is up ? I feel like using notifications to deliver messages is unreliable anyway you are going to sync on focus.
It's not for the purpose of notifications, it's for the purpose of sync. If you do not initiate sync process after even own messages, immediately after launch of the app you'll see only incoming messages, and own will load up after a significant delay. That is not what chat users are used to these days.
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.
> Another use case is removing notifications: once you message on another device, you want to remove notification on iOS as well. With current notifications it is extremely problematic
What is wrong with this at the moment? Ive noticed Discord does this and it works perfectly fine for me. Its the only app I have thats relevant to this feature, so I just assumed it was fine for everything.
It is likely that discord still uses 'old' VoIP notifications that worked well before iOS 12/13 dropped the hammer on them and forced developers to always show callkit on every voip notification. With those notifications, it wasn't really a problem, but apple killed them because some developers (Facebook?) abused them to gather location and other data.
I have no idea why, as I'm not an iOS developer, but I have to say this is one of the most annoying things about my iPad.
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.
These are not delivered along with the notification-- they're provided (client-side) by the application that the notification was sent for. So, while a notification could display dynamic content here depending on the content of the notification (for example, this is the same mechanism as used by Mail on iOS for mail previews) and the preview code should take the untrusted nature of the content into account if it does, it doesn't have to and it's not any different than running the application itself in terms of security issues.
No. Nowadays you should still disable JavaScript as well as video playback in your browser if you want to be safe.
There was a brief period some years ago where browsers looked "pretty safe", but we have quickly backtracked by stuffing JS and browsers full of new APIs that are creating new vulnerabilities.
Edit: Yes. Downvoting will surely reduce the amount of CVEs.
I mean you might as well just disable all connectivity on your computer if you only feel safe by not having CVEs show up in a search. Generally people want to still receive content though and are looking for the safest ways to do that, not ways to re-enact Bubble Boy, and for that browsers actually rank pretty good against most any other ways to get dynamic content.
The question wasn't "what is the safest way to display dynamic content", the question was "is displaying dynamic content (this way) safe".
And the answer is no. Web browsers are the safest way to run arbitrary code in a sandbox on your computer - which is what dynamic content in this context really means - the same way that aiming at your feet is the safest way to shoot yourself.
Not sure how macOS does it but iOS has notification service and content extensions. The original notification in itself is pretty lightweight. However, the service extension allows an app to perform additional downloading and data retrieval from which it can augment the notification data. From there, the notification content extension can take this enlarged notification and present a custom, interactive view controller. So yeah, almost none of the data is from the notification itself. I haven’t explored the limits of what APIs are available to a notification content extension but it wouldn’t surprise me if what’s seen here is possible on iOS, too.
For example in a chat app that syncs with desktop you can deliver incoming messages, showing them as alerts, but you can't deliver your own, because you MUST show alert on every push notification. Another use case is removing notifications: once you message on another device, you want to remove notification on iOS as well. With current notifications it is extremely problematic.
(Remaining background notifications in iOS work like shit - and please, do not start discussion that 'it is not needed' - It is BADLY needed, just ask anyone who has developer experience with this wreck)