Implementing Subscription Expiry Push Notifications in Mobile Apps

When launching a mobile app with subscriptions, a typical situation: the payment fails, the user doesn't even notice, the app remains silent. Up to 60% of customers churn on the first auto-payment failure. Without a notification chain, recovering the subscription is nearly impossible. A well-designed push notification system retains up to 40% of users on the verge of unsubscribing. Let's break down how to set up subscription expiry notifications using StoreKit 2, FCM, and proper segmentation. Our experience: 5+ years and 50+ subscription projects.

Why One Push Notification Is Not Enough

A single notification is a poor strategy. The user may ignore or postpone it. Research shows that a cascade of 3–4 reminders boosts renewal conversion by 30%. We use a chain: 7 days before → 1 day before → on the day of expiry → 3 days after. Each step delivers a specific call-to-action with a deeplink.

Server-Side Events vs. Local Notifications

The first question: how do you know when the subscription expires? For In-App Purchase (StoreKit), Apple sends events to your server via App Store Server Notifications V2. For custom server-side subscriptions, the logic is on your end.

StoreKit 2 / App Store Server Notifications V2: Apple delivers RENEWAL and EXPIRED events to your server. Upon receiving DID_FAIL_TO_RENEW — the first signal to send a push. At GRACE_PERIOD_EXPIRED — the last chance. Apple sends some system notifications on its own, but relying solely on them is insufficient — you must build your own reminder business logic.

// Server notification V2 (decoded payload)
{
  "notificationType": "DID_FAIL_TO_RENEW",
  "subtype": "GRACE_PERIOD",
  "data": {
    "bundleId": "com.example.app",
    "transactionInfo": { ... }
  }
}

App Store Server Notifications

Local notifications are only suitable if you have no server at all, or for offline scenarios. Use UNUserNotificationCenter with UNCalendarNotificationTrigger — schedule a notification on expiresDate - 3 days. Problem: if the user renews via web or another device, the local notification will still fire. Without server synchronization, this leads to false positives.

Server push is 3–4 times better than local in delivery accuracy and configuration flexibility.

Reminder Chain

A working scheme for B2C:

• 7 days before expiry: "Your subscription expires April 15 — renew to keep your data"
• 1 day before: specific call-to-action with deeplink to the subscription management screen
• On expiry day: notification with a limited-time offer (if available)
• 3 days after: reactivation with a discount (optional)

A deeplink in the notification is mandatory. A push without action loses conversion. On iOS: UNNotificationAction with foreground — opens the app and passes userInfo. On Android: PendingIntent with the appropriate Intent.

// iOS: handle tap on subscription notification
func userNotificationCenter(_ center: UNUserNotificationCenter,
    didReceive response: UNNotificationResponse) async {
    let info = response.notification.request.content.userInfo
    if info["type"] as? String == "subscription_expiry" {
        NavigationRouter.shared.navigate(to: .subscriptionManagement)
    }
}

On Android via FCM, similarly: pass type: subscription_expiry in the data payload, route in FirebaseMessagingService.onMessageReceived.

class MyFirebaseMessagingService : FirebaseMessagingService() {
    override fun onMessageReceived(message: RemoteMessage) {
        val type = message.data["type"]
        if (type == "subscription_expiry") {
            // Open subscriptions screen
            val intent = Intent(this, SubscriptionActivity::class.java)
            startActivity(intent)
        }
    }
}

What to Do If Push Is Not Delivered?

Check notification permissions (ATT on iOS, settings on Android), device token status, and deeplink correctness. Consider the user's timezone — send pushes during local daytime. Implement retry logic with a manual trigger.

Segmentation and Timing

A user with a monthly subscription and a user with a yearly subscription require different approaches. For monthly, a 7-day window is 25% of the remaining term — too aggressive. For yearly, 7 days out of 365 is fine.

The user's timezone is critical: a push at 3 AM causes irritation and unsubscribes. Firebase FCM allows setting delivery_time based on the device's local time. For APNs, this is handled server-side via a task scheduler that respects the user's timezone.

Our Work Process

1. Audit your current subscription system: StoreKit / server-side / hybrid.
2. Configure App Store Server Notifications V2 or server webhooks for expiry triggers.
3. Implement the push notification chain with deeplinks to the appropriate screen.
4. Test on StoreKit sandbox environment and live FCM.
5. Monitor and adjust timing based on analytics.

What's Included in the Work

• Setup of App Store Server Notifications V2 / server webhooks
• Development of push notification chain (up to 4 stages)
• Integration of deeplinks to the subscription management screen
• Event logging for analytics
• Documentation and instructions for your team
• 1 month of support after launch

Timeline Estimates

Integration with an existing notification server and StoreKit 2 — 2–3 days. Building server-side logic from scratch (scheduler, user segmentation) — up to 1 week.

Losing one user with a yearly subscription costs on average $300–$500, and a notification cascade brings back 15–20% of them. Implementing the notification chain increases LTV by 20–30% and reduces new user acquisition costs by 15%.

Get a consultation for your project — contact us to assess the scope and propose a solution. Request a free audit of your current subscription system.

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.

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.

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.

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

1. Audit current implementation — check token storage, update handling, notification types.
2. Design architecture — choose transport (FCM + APNs), segmentation layer (OneSignal/Braze/custom), personalization method.
3. Implementation — write registration code, inbound handling, rich push, deep linking.
4. Testing — send test campaigns, verify delivery on different devices, simulators, regions.
5. Monitoring and analytics — set up dashboard, open and conversion events.
6. 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.

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.