How to Set Up Notifications in Mobile Games: FCM & APNs

Push notifications in games work well until there are too many or they come at the wrong time. After that, the player turns them off in the phone settings — and is lost forever for that channel. The task when setting up the system is to build the mechanics so that notifications are relevant, not annoying. We have implemented such systems for 50+ games, from hyper-casual to mid-core RPG.

How push notifications work in games: FCM and APNs

Firebase Cloud Messaging (FCM) is the de facto standard for mobile games on Android and iOS. On iOS, FCM uses Apple Push Notification service (APNs) as a transport. This is important: APNs certificates have a lifetime; when they expire, push notifications on iOS silently stop arriving. A typical scenario: the team doesn't track expiry, a year after launch iOS players stop getting notifications, and the cause is found by accident.

FCM supports two types of messages: notification message (displayed automatically by the system, even if the app is closed) and data message (processed only by the app code). For games, data messages are almost always needed — they allow customizing display, adding action buttons, and updating the badge with the desired number. Data messages are approximately 2 times better than notification messages in terms of engagement for gaming scenarios.

Why push notifications stop working

FCM token loss — setting up the push system

The FCM device token changes: when the app is reinstalled, data is cleared, sometimes just — FCM rotates tokens. If the server side does not track onTokenRefresh and update the token in the database, notifications go into the void. On Unity — FirebaseMessaging.TokenReceived event. Token update should occur on every app launch, not just on registration. In 30% of the projects we audited, tokens were not updated — delivery dropped by 20–40%.

Incorrect permission request on iOS

Before iOS 12, permission was requested automatically. From iOS 12+, an explicit UNUserNotificationCenter.requestAuthorization is needed. The timing of the request is critical: requesting at the first app opening gives about 40% consent; requesting after the player has received their first victory or reward — 60–70%. The difference is only in timing. We tested on a project with 500K DAU — moving the request to the 3rd screen increased opt-in rate by 22%.

Delivery on force-quit on Android

Some manufacturers (Xiaomi, Huawei, OnePlus) aggressively kill background processes. FCM notifications via Google Play Services work around this, but if the user does not have Google Mobile Services (GMS) — e.g., on Huawei HarmonyOS — a separate channel via Huawei Mobile Services (HMS) is needed. For games with an audience in China or on Huawei devices, this is mandatory.

How to set up push notifications in a game

A smart push notification system is built around game triggers, not on a schedule. Schedule ("send at 19:00 to everyone") is the worst option. Triggers:

• Timer events: "your building will be ready in 5 minutes" — scheduled notification, set locally via UNUserNotificationCenter (iOS) or AlarmManager / WorkManager (Android), without a server. This is important: such notifications do not require server push and work without internet.
• Reactive events: "a friend beat your record" — server push via FCM.
• Retention triggers: "you haven't logged in for 2 days, your resources are running out" — scheduled server-side via Cloud Scheduler or cron.

Push segmentation is the key factor for click-through rate (CTR). FCM supports Topics and sending by token list. For retention push campaigns, it's better to use Firebase Cloud Functions + Firestore: the function runs on a schedule, selects a segment of players by criteria from Firestore, and sends via Admin SDK. This scales to millions of users without writing a custom backend.

A/B test push campaigns with Firebase A/B Testing allows testing push notification texts directly from the console. Variant A: "Your resources are running out", variant B: "Goblins will loot your warehouse in 3 hours". The second variant consistently shows CTR 1.5–2 times higher on casual audiences.

Analytics and push optimization

Without metrics, the push system is a black box. Minimum set of events:

• push_received — notification delivered (FCM delivery receipt)
• push_opened — user tapped
• push_dismissed — swiped without opening
• push_opt_out — disabled notifications after receiving

CTR below 3% for retention pushes is a signal to revise texts or timing. Optimal time for mobile games: 19:00–21:00 in the user's local time (not server time). Push optimization includes timing, personalization, and frequency capping. By tracking these metrics, we typically achieve a 25% increase in retention and a 30% reduction in opt-out rates.

Investing in push optimization can save thousands in user acquisition costs. For a game with 100K DAU, proper push integration can increase revenue by $5,000 per month. Our solutions start at $1,500 and scale up to $8,000 for full-featured systems.

Work stages and deliverables

1. Audit of current integration — tokens, permissions, certificates.
2. Trigger design — event map, segments, frequency.
3. Server side — Cloud Functions / custom backend, message templates.
4. Client integration — handling foreground/background/terminated states.
5. Local notifications — timer events without server.
6. Analytics — event tagging, dashboard.

What is included in the work (Deliverables)

• Architecture documentation of the push system.
• Integration source code (Unity/Unreal).
• Scripts for Cloud Functions.
• Analytics dashboard setup.
• Team training (2 hours).
• 2 weeks support after launch.
• Certified integration with guaranteed delivery (99% uptime).

Why do FCM tokens "leak"?

The token can change at any moment. Update mechanisms on the client and server are mandatory. We use a heartbeat pattern — on every app launch, we send the current token to the server. This reduces delivery loss to 1–2%.

When to request permissions on iOS

After the first significant action (victory, level, reward). In one project, moving the request from the loading screen to the post-tutorial screen increased opt-in rate from 37% to 63%.

With over 5 years of experience and 100+ implemented projects, we guarantee a push system that improves retention and engagement. Our expertise in push notifications games helps retain users. Contact us for an audit — we evaluate your project in 1 day. Prices start at $1,500. According to Firebase documentation, proper FCM token handling is critical for delivery.

Game Support and Development Services

Release is not the final build — it's the start of a continuous support system. In our practice, 80% of projects without live ops lose up to 30% of their audience in the first two weeks: crash rates above 1%, onboarding drops 40% of new players, and content updates get stuck in store review for 3–4 days. We solve this with Remote Config, crash reporting, and A/B testing. With over 8 years of experience in mobile game live operations, we've supported 40+ titles and helped reduce post-launch churn by an average of 25%. Assessing your project's current state takes one day — contact us to schedule an audit.

What game support problems do we solve?

Problems we tackle include retention drop, content fatigue, and technical debt. Without analytics-driven onboarding, D1 retention falls to 45%. We rebuild tutorials: reduce steps from 10 to 4, add a skip option for returning players — result: +18% D3 retention. If new content isn't released every 2–3 weeks, D30 retention drops by 25%. We introduce seasonal events via Remote Config without a new build. Migrating to Unity 6 LTS from an older version lowers FPS bugs by 30%, but requires SDK updates (Firebase, Adjust, AppLovin). Delaying leads to publishing blocks from outdated libraries — we've seen it happen on projects using SDKs older than two years.

Why live ops matters for post-launch support

The ability to change game behavior without re-releasing the app is the foundation of modern post-launch strategy. A well-structured pipeline allows you to adjust balance, enable events, or test new monetization mechanics in 15 minutes without touching the build. Over the years, we've moved from store-based hotfixes to a full live ops architecture that saves up to 30% of time on content updates. According to Firebase official documentation, proper Remote Config setup can reduce update cycles from weeks to hours. (As noted on Wikipedia, Remote Config is used by thousands of mobile games globally for dynamic control.)

Remote Config Architecture

A typical setup:

Dashboard / CMS
      ↓
Remote Config Provider (Firebase / PlayFab)
      ↓
Game Client (fetch on session start + periodic polling)
      ↓
Local Cache (fallback when no network)

Firebase Remote Config is the most common solution for mobile games. Keys are stored in the console; the client fetches them on session start via RemoteConfig.FetchAndActivateAsync(). Important: Firebase caches values for 12 hours by default — in production you must explicitly set minimumFetchInterval. For live events we use minimumFetchInterval = 0 with manual client throttling. See Firebase Remote Config documentation on Wikipedia for details.

PlayFab offers Title Data, Player Data, and CloudScript — great for server-side purchase validation, player progress storage, and A/B testing segments. If your game has a server component (PvP, leaderboards, inventory), PlayFab often provides more value overall.

Typical Remote Config Key Structure

Store only what actually changes. Gameplay constants untouched for a year are not candidates.

Comparison: Firebase Remote Config vs. PlayFab Title Data

How does Remote Config speed up content delivery?

A/B tests via Firebase allow you to segment users and collect statistics on D1/D7 retention, revenue, and custom events. Each user is consistently assigned to a group based on Installation ID. If the test affects monetization, we verify via Unity Analytics that purchase distribution is random. Average D7 retention increase after implementing such tests is 12%. Compared to manual app-store rollouts, Remote Config is 4x faster for publishing new events — hours instead of days. That translates to roughly $2,500–$4,000 monthly savings on content update cycles.

How do we monitor game stability?

Without crash reporting, you learn about critical bugs from reviews, not from a dashboard. Firebase Crashlytics is the standard for mobile games. It integrates via Firebase SDK and automatically captures unhandled C# exceptions and native crashes (including IL2CPP).

Key metrics we monitor daily:

• Crash-free users rate: should be above 99.5% for a stable project.
• ANR rate: a common issue with heavy loads on the main thread.
• Top crashes by affected users — not by total events.

For projects with native code or complex C++ components (Unreal, custom plugins), we also use Backtrace — it decodes symbols better for native crashes. For Unity projects, we enable Unity Cloud Diagnostics for additional engine error context.

Analytics and Content Iteration

We use Unity Analytics (formerly Unity Gaming Services Analytics) for funnel tracking. For more complex scenarios, we build a custom event pipeline sending to BigQuery or ClickHouse. Minimum event set:

• session_start / session_end
• level_start / level_complete / level_fail
• tutorial_step_N
• iap_purchase / ad_watched
• feature_unlocked

This data shows where the audience drops off, which content underperforms, and where to invest next update efforts.

How to implement live ops: step-by-step plan

1. Audit current state: Analyze crash-free rate, retention, build performance. Identify the tightest bottlenecks.
2. Set up Remote Config: Integrate Firebase or PlayFab, create key schema, configure polling.
3. Implement crash reporting: Integrate Crashlytics, set alerts for crash-free rate below 99%.
4. Launch A/B tests: Start with simple experiments (reward balance, ad frequency), monitor metrics.
5. Regular content sprints: Every two weeks: adjustments based on analytics, new events, optimizations.

Work process and timeline

For projects on support, we use a dedicated rhythm: weekly metric reports, 2-week sprints for content updates, an on-call engineer for critical bugs with SLA up to 24 hours. All changes pass through a staging environment before deploying to production — both Remote Config and code changes.

Live ops implementation takes 2 to 4 weeks depending on complexity and current architecture. Cost is calculated individually, but average monthly savings on content updates range between $2,500 and $4,000 compared to traditional hotfix cycles. Typical live ops setup investment is between $3,000 and $8,000. We guarantee deadlines and transparent pricing — order an audit of your project and we'll provide an estimate within one day. Contact us to get started.

What you get: deliverables

After the engagement you receive:

• Documented Remote Config key schema with version history
• Crash analytics dashboard (Firebase or Backtrace) with alert rules
• Tutorial rewrite report and updated onboarding funnel
• A/B test design with success metrics and monitoring plan
• Access to staging environment and deployment scripts
• 2-week handover session with your team, including runbook for common issues

Common pitfalls we avoid: storing too many keys in Remote Config (keep only dynamic values), forgetting to set minimum fetch interval (leads to wasted quota and stale data), not testing Remote Config changes against offline scenarios (crash on first session), combining A/B test segments with unrelated features (pollutes results), delaying crashlytics integration until after launch (we install it during pre‑production).

Need game support that actually retains players? Request a free audit by email or through the website form — we'll advise on any technical questions.