Why Silent Push Fails: Real-World Cases
Silent push is a powerful tool for background sync, but implementation is full of pitfalls. According to statistics, improper silent push configuration leads to 40% of missed notifications on Android and up to 60% on iOS in complex scenarios. One of our clients, a delivery service with 500,000 users, faced an issue where after updating to Android 13, background notifications stopped waking the app — Doze Mode with new restrictions blocked high-priority messages due to the absence of setForegroundAsync call in an expedited worker. We reconfigured the handling and added the call — the problem was resolved. In this article, we’ll break down how to reliably set up background sync without user interaction and show how to avoid common mistakes. Our experience: 10+ years in mobile development, 50+ projects with push infrastructure.
Silent Push on iOS: Technical Details
On iOS, silent push requires the content-available: 1 flag in the payload and the “Remote notifications” Background Mode enabled in Xcode Capabilities.
APNs payload:
{
"aps": {
"content-available": 1
},
"sync_type": "messages",
"last_known_id": "msg_8823"
}
No alert, no sound — a pure background call. Handling in AppDelegate:
func application(_ application: UIApplication,
didReceiveRemoteNotification userInfo: [AnyHashable: Any],
fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
guard let syncType = userInfo["sync_type"] as? String else {
completionHandler(.noData)
return
}
Task {
do {
let hasNewData = try await SyncManager.shared.sync(type: syncType)
completionHandler(hasNewData ? .newData : .noData)
} catch {
completionHandler(.failed)
}
}
}
Critical point: iOS gives about 30 seconds for execution. If completionHandler is not called, the task is forcefully terminated. iOS also does not guarantee delivery when the battery is low (Low Power Mode) and after the app has been force-quit. Force quit completely blocks silent push until the app is manually launched — this is documented iOS behavior and cannot be bypassed, as documented by Apple.
Silent Push on Android: FCM Data Message and WorkManager
On Android, the role of silent push is played by FCM Data Message — it reaches FirebaseMessagingService.onMessageReceived regardless of app state (if not killed by system Doze).
class AppFirebaseMessagingService : FirebaseMessagingService() {
override fun onMessageReceived(message: RemoteMessage) {
val syncType = message.data["sync_type"] ?: return
val workRequest = OneTimeWorkRequestBuilder<SyncWorker>()
.setInputData(workDataOf("sync_type" to syncType))
.setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)
.build()
WorkManager.getInstance(applicationContext).enqueue(workRequest)
}
}
setExpedited() requests immediate execution. On Android 12+, inside an expedited worker, you must call setForegroundAsync(), otherwise a long operation may cause an ANR.
Doze Mode restricts background activity. FCM high-priority messages bypass Doze if you specify android.priority: "HIGH" in the payload:
{
"message": {
"token": "device_fcm_token",
"android": {
"priority": "HIGH"
},
"data": {
"sync_type": "messages",
"payload": "{...}"
}
}
}
More about Doze Mode
Doze Mode activates when the device is idle and not charging. High-priority messages bypass it, but if requests are too frequent, the system may start ignoring them — maintain intervals of at least 10 minutes between silent pushes.
How to Update Badge Without Notifying the User?
A common case is updating the badge number without showing a notification. On iOS via silent push:
func application(_ application: UIApplication,
didReceiveRemoteNotification userInfo: [AnyHashable: Any],
fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
if let badge = userInfo["badge"] as? Int {
UNUserNotificationCenter.current().setBadgeCount(badge) { _ in }
}
completionHandler(.newData)
}
On Android, there is no universal API — use the ShortcutBadger library or NotificationManagerCompat.setNumber(), but support depends on the launcher (Samsung, Xiaomi, Huawei).
Limits and Quotas
iOS 13+ introduced BGTaskScheduler and background processing quota. If an app requests background execution too often without benefit to the user, the system will throttle calls. Calling completionHandler(.noData) when there is no new data is critical for correct quota system operation. On Android, a similar mechanism exists — WorkManager throttles frequent tasks. Adhere to intervals and use exponential backoff on errors.
Platform Comparison
| Feature |
iOS |
Android |
| Mechanism |
Silent Push (content-available) |
FCM Data Message |
| Background execution |
Background Modes + 30s limit |
WorkManager + expedited |
| Force quit |
Not delivered |
Delivered (if not killed by system) |
| Doze Mode |
Throttling by quota |
High priority bypasses Doze |
| Badge update |
UNUserNotificationCenter.setBadgeCount |
ShortcutBadger / launcher-specific |
Common Errors and Solutions
| Error |
Solution |
| Silent push not delivered on iOS after force quit |
Explain to the user that the app needs to be launched manually |
| FCM Data Message not waking app on Android 12+ |
Add setForegroundAsync() in expedited worker |
| Badge not updating on Android Xiaomi |
Use ShortcutBadger with explicit Xiaomi support |
| Background execution quota exceeded on iOS |
Reduce silent push frequency to once every 5-10 minutes |
What’s Included in Our Silent Push Setup Service
When you order our service, you get:
- Architecture design for push infrastructure (APNs + FCM)
- Implementation of handlers on iOS and Android with edge cases covered
- Configuration of Background Modes, WorkManager, high-priority topics
- Integration of badge counter updates on both platforms
- Documentation and team training
- Post-launch support (1 month)
Why Trust Our Setup?
We specialize in mobile development with over 10 years of experience. We have implemented more than 50 projects with push infrastructure, including high-load apps with millions of users. Our solutions pass App Store Review and Google Play Console without issues. We use the latest versions of Swift, Kotlin, Flutter — the stack is selected based on your project.
Timelines and Cost
Silent push setup for one platform (iOS or Android) takes 3–5 business days. A cross-platform solution takes 5–9 days. The cost is calculated individually based on integration complexity and required stack. We offer a free project evaluation — simply contact us.
Get a consultation — reach out by email or through the form on our website. We’ll help you set up silent push so that data updates even under the harshest conditions.
Push Notifications in Mobile App: APNs, FCM, Segmentation, Rich Push
We have implemented push notifications in mobile apps for 50+ projects — from startups to enterprise with audiences of 10M+ users. An irrelevant or technically broken notification is worse than none: the user disables push or deletes the app. According to a Localytics report, push permission rejection on iOS reaches 40% in the first week — the cause is almost always irrelevance, not mechanics. Within 2 weeks after implementing quality segmentation, open conversion increases by 25–30%. Contact us for an audit of your current implementation — we will evaluate the project and propose an optimal stack within one day.
How the Infrastructure Works: APNs and FCM
APNs is the only delivery channel on iOS. Everything else (OneSignal, Braze, Airship) is a wrapper on top of it. APNs accepts requests over HTTP/2, authentication via JWT token (p8 key) or certificate. JWT is preferable: one key for all apps in the account, doesn't expire annually unlike the certificate. For more details, see the official documentation.
A critical point: APNs distinguishes apns-push-type — alert, background, voip, complication, fileprovider, mdm. An incorrect type on iOS 13+ causes background notifications not to wake the app. We've seen projects where content-available: 1 was sent without apns-push-type: background — the app didn't receive silent push on some devices, and the team spent a month looking for an 'app bug'.
FCM on Android works through Google Play Services. For devices without GMS (Huawei, part of the Chinese market), Huawei Push Kit or a direct WebSocket is needed — a separate task. FCM supports data messages (handled in onMessageReceived) and notification messages (the system displays automatically if the app is in the background). Mixing them requires caution: if the notification block has a click_action but the deep link is not registered in the app, tapping the notification simply opens the main screen without navigation.
| Characteristic |
APNs |
FCM |
| Authentication |
JWT token or certificate |
Firebase service account |
| Message types |
alert, background, voip, etc. |
notification, data |
| Silent push |
content-available + apns-push-type: background |
data message with priority high |
| Payload limits |
4 KB |
4 KB (upper), up to 2 KB for notification |
| Works without Google Play |
N/A (iOS only) |
No, requires alternative provider |
Why Segmentation Is the Foundation of Effective Push Notifications?
Sending to everyone indiscriminately quickly exhausts user loyalty. Personalized messages are clicked 3 times more often than bulk ones, and proper segmentation reduces churn by 25% (on one project it brought significant additional revenue per quarter). The cost of setting up segmentation in OneSignal or a custom backend depends on the complexity of filters.
Proper segmentation is built on several levels.
| Segmentation Type |
Tool |
Example |
| By topics |
FCM topics / APNs push-to-topic |
Order status notifications |
| By attributes |
OneSignal, Braze |
last_active < 7_days + plan = premium |
| Personalized |
Custom backend |
By device_token linked to profile |
Topics are for broad categories: 'new promotions', 'order status updates'. User subscribes via FirebaseMessaging.getInstance().subscribeToTopic("orders"). Simple, but no flexible filtering.
Attribute-based segments — via OneSignal, Braze, or custom backend. We store in the user profile: language, device type, last activity, LTV segment. Notification goes only to those with last_active < 7_days and plan = premium. OneSignal allows building such filters in the interface without code.
Personalized — by specific device_token. It's important to store tokens correctly: the token updates on app reinstall, restoration from backup on a new phone, or resetting settings. On iOS, use UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, save to backend on every launch, not just the first. Otherwise, after 3 months 30% of tokens in the database are outdated.
What Is Rich Push and How Does It Boost Conversion?
A standard notification with title and text is clicked less often than a rich push with image and action buttons — by 3 times. But implementing rich push is a separate task on each platform.
On iOS, rich content requires UNNotificationServiceExtension (to modify payload) and UNNotificationContentExtension (custom UI). The extension runs in a separate process with limited time and memory. If the extension crashes or exceeds the timeout, the system shows the original payload without media. A typical mistake is trying to load an image over HTTP (not HTTPS): ATS blocks the request, the extension silently fails, and the user sees a notification without an image.
On Android with API 26+, notifications are tied to NotificationChannel. If the channel is created with IMPORTANCE_LOW, sound and vibration are unavailable. Different notification types (transactional, marketing) should be in different channels so the user can disable marketing without losing order notifications. BigPictureStyle, MessagingStyle, InboxStyle are templates for expanded notifications. MessagingStyle with Person and avatars is the best choice for chats.
| Platform |
Component |
Details |
| iOS |
UNNotificationServiceExtension |
Runtime ~30 s, memory ~50 MB, HTTPS required |
| iOS |
UNNotificationContentExtension |
Custom UI, action buttons |
| Android |
NotificationChannel |
Importance level, sound, vibration — user-configurable |
| Android |
BigPictureStyle / MessagingStyle |
Expanded content, message grouping |
How to Track Delivery and Conversion of Push Notifications?
Sending a notification is half the work. It's important to know: was it delivered, opened, and did it lead to a target action.
FCM returns a MessageId on send, but does not guarantee a delivery callback — by design. For open tracking, custom logic is needed: on notification tap in onMessageReceived or via getInitialNotification() / onNotificationOpenedApp (OneSignal SDK), send an event to analytics with notification_id.
OneSignal provides built-in delivery and CTR analytics. For more detailed analysis — integrate with Amplitude or Mixpanel via webhook on open events. The budget for such a dashboard varies depending on event volume.
How We Implement Push Notifications: Typical Process
-
Audit current implementation — check token storage, update handling, notification types.
-
Design architecture — choose transport (FCM + APNs), segmentation layer (OneSignal/Braze/custom), personalization method.
-
Implementation — write registration code, inbound handling, rich push, deep linking.
-
Testing — send test campaigns, verify delivery on different devices, simulators, regions.
-
Monitoring and analytics — set up dashboard, open and conversion events.
-
Documentation and training — hand over operational materials to the team.
Typical stack: FCM + APNs at transport level, OneSignal or Firebase Notifications Composer for segmentation, custom backend for personalized event-based notifications. For large apps with >1M users, OneSignal has pricing limits — then we use Braze or a custom implementation on AWS SNS.
Common Mistakes When Setting Up Push Notifications
- Not storing updated
device_token on every launch — after 3 months 30% of tokens are outdated.
- Confusing
apns-push-type — background notifications don't wake the app.
- Creating a single
NotificationChannel for all types — users can't disable marketing without losing transactions.
- Loading media in rich push over HTTP — ATS blocks the request on iOS.
- Not testing deep link targeting — taps go to the main screen.
Timelines depend on complexity: basic FCM+APNs integration with transactional notifications — 1–2 weeks. A full system with segmentation, rich push, analytics, and A/B testing — 4–8 weeks. Order an audit of your current push infrastructure or get a consultation on implementing push notifications in your mobile app — we will contact you within a day and provide an accurate estimate.