Subscription Management Screen for Mobile Apps: Development

TRUETECH is engaged in the development, support and maintenance of iOS, Android, PWA mobile applications. We have extensive experience and expertise in publishing mobile applications in popular markets like Google Play, App Store, Amazon, AppGallery and others.

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
Subscription Management Screen for Mobile Apps: Development
Simple
~2-3 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    744
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    562

A poorly designed subscription management screen accelerates cancellations — up to 40% of users churn without understanding what they lose. We build screens that read real-time status via StoreKit 2 on iOS and Google Play Billing Library 6 on Android, integrate grace period, retention offers, and the system-managed subscription button. Our approach reduces churn and boosts renewal rates. With 5+ years of experience in subscription models and over 20 implemented screens for apps with 10k–500k active users, we know platform nuances and help avoid App Review rejections (guideline 3.1.2).

What data to display

Minimum set:

  • Current plan: name, price, period
  • Next billing date or expiration date (if cancelled)
  • Status: active / cancelled (access until) / grace period / billing retry
  • Button to switch plans (upgrade/downgrade)
  • Link to Apple/Google system cancellation screen

Without showing grace period you lose up to 30% of renewals — users simply don't have time to update their card. Retaining a user costs 5 times less than acquiring a new one, so investment in the cancellation flow pays off within the first month. Displaying grace period status with a dedicated banner reduces user anxiety and increases renewal probability.

How we read subscription state (StoreKit 2)

import StoreKit

struct SubscriptionInfo {
    let productID: String
    let displayName: String
    let price: String
    let renewalDate: Date?
    let expirationDate: Date?
    let willAutoRenew: Bool
    let state: Product.SubscriptionInfo.RenewalState
    let isInGracePeriod: Bool
}

func loadSubscriptionInfo(productIds: [String]) async -> SubscriptionInfo? {
    guard let product = try? await Product.products(for: productIds).first,
          let status = try? await product.subscription?.status.first else {
        return nil
    }

    let renewalInfo = try? status.renewalInfo.payloadValue
    let transaction = try? status.transaction.payloadValue

    return SubscriptionInfo(
        productID: product.id,
        displayName: product.displayName,
        price: product.displayPrice,
        renewalDate: renewalInfo?.renewalDate,
        expirationDate: transaction?.expirationDate,
        willAutoRenew: renewalInfo?.willAutoRenew ?? false,
        state: status.state,
        isInGracePeriod: status.state == .inGracePeriod
    )
}

renewalInfo.willAutoRenew indicates whether auto-renewal is active or cancelled. If false, access continues until expirationDate.

Comparison: StoreKit 2 vs Play Billing 6

Parameter iOS (StoreKit 2) Android (Play Billing 6)
Status reading SubscriptionInfo.state (.subscribed, .inGracePeriod, etc.) BillingClient.queryPurchasesAsync() + purchaseState
Grace period Automatic via .inGracePeriod Requires checking acknowledgementState and purchaseTime
Upgrade/downgrade Product.subscription?.update() BillingClient.launchBillingFlow() with updated SKU
System screen AppStore.showManageSubscriptions Deeplink to Google Play
Promotional offer SubscriptionOffer type .introductory or .promotional BillingFlowParams.SubscriptionUpdateParams

SwiftUI component example

struct SubscriptionManagementView: View {
    @StateObject private var viewModel = SubscriptionManagementViewModel()

    var body: some View {
        ScrollView {
            VStack(alignment: .leading, spacing: 24) {
                if let info = viewModel.subscriptionInfo {
                    CurrentPlanCard(info: info)

                    if info.state == .inGracePeriod {
                        GracePeriodWarning()
                    }

                    if info.willAutoRenew, let date = info.renewalDate {
                        Text("Следующее списание: \(date.formatted(.dateTime.day().month().year()))")
                            .foregroundStyle(.secondary)
                    } else if let date = info.expirationDate {
                        Text("Доступ активен до: \(date.formatted(.dateTime.day().month().year()))")
                            .foregroundStyle(.secondary)
                    }

                    PlanPickerSection(currentPlan: info.productID)
                }

                ManageButton()
            }
            .padding()
        }
        .task { await viewModel.load() }
    }
}

Why the system subscription management button is required

Apple mandates access to the system screen (guideline 3.1.2). Without it — rejection. Use showManageSubscriptions to open the system subscription management screen — Apple Developer Documentation. Implementation is simple:

Button("Управление подпиской в App Store") {
    Task {
        try? await AppStore.showManageSubscriptions(in: windowScene)
    }
}

On Android — a deeplink to Google Play:

val intent = Intent(Intent.ACTION_VIEW).apply {
    data = Uri.parse("https://play.google.com/store/account/subscriptions?sku=premium_monthly&package=${packageName}")
}
startActivity(intent)

How we design the cancellation flow

Best retention practices on attempted cancellation:

  1. Before redirecting to the system screen, show a list of features the user will lose.
  2. If the subscription has been active for a long time (3+ months), offer a pause (natively supported on Android).
  3. For users with a long history, show a promotional offer with a discount.

This is not a dark pattern — it is an honest reminder. Do not overdo it: one confirmation screen at most. Our statistics: retention after a promo offer is 60%. Promotional offers can generate up to 15% additional revenue. If the user still leaves, capture the reason via analytics to improve the product.

Comparison: basic vs retention screen

Parameter Basic screen Screen with retention
Status reading StoreKit 2 / Play Billing + grace period + billing retry
Display plan, date, status + feature list, promo offer
Cancel flow only system screen system screen + second screen with pause/discount selection
Development time 2–3 days 4–5 days
Retained users 10–15% 40–60%

What is included in the work

  • Status reading via StoreKit 2 / Google Play Billing Library 6
  • Display component: plan, date, status, grace period
  • Plan switcher (upgrade/downgrade) with terms description
  • Integration of AppStore.showManageSubscriptions / Play Store deeplink
  • Optional cancellation flow with retention offer
  • Documentation for components and subscription screen architecture
  • 14-day support after delivery

Timeline and cost

2–3 days for a basic screen with real-time status. With a complex cancellation flow and retention offers — up to 5 days. Cost is calculated individually. Get a consultation — we will evaluate your project.

Contact us to discuss your subscription management needs. We will tailor a solution to your business logic.

Mobile App Monetization: IAP, Subscriptions, and Ad Mediation

An app with poorly implemented purchases loses money not because users don't want to pay, but because a StoreKit transaction hangs, Receipt Validation fails with an error, or restore purchases doesn't work — and the user writes to support or leaves a 1-star review. Our experience (over 7 years in mobile development) shows that proper monetization increases LTV by 30–60% within the first three months after implementation. Get a consultation on monetizing your app — we'll analyze the current model and find growth points.

Why StoreKit 2 is the Best Choice for IAP?

StoreKit 2 (iOS 15+) is a modern API with async/await and device-side verified transactions without a server. Transaction.currentEntitlements returns all active purchases. Key change compared to StoreKit 1: JWS signature verification on device via VerificationResult<Transaction> — no need to send receipt to server for basic validation.

But server-side validation is still needed for consumable purchases and fraud prevention. App Store Server API replaces the old /verifyReceipt endpoint. Webhooks via App Store Server Notifications v2 provide real-time events: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — without polling.

A typical mistake: not handling paymentQueue(_:updatedTransactions:) in the background for unfinished transactions. User bought a consumable, app crashed before finishTransaction — purchase remains in queue, restores on next launch and requires reprocessing on server. Without server idempotency — double crediting.

How Not to Lose Revenue on Subscriptions?

The subscription model requires tracking states: trial → active → grace period → expired → refunded. RevenueCat is the de facto standard for managing subscriptions in production. It abstracts StoreKit and Google Play Billing, providing a unified API, webhooks, cohort analytics, and A/B testing of paywalls.

Alternatives to RevenueCat include custom implementations with Adapty or Qonversion. Fully custom only if data must not leave the infrastructure or there is non-standard logic. We guarantee that webhook setup and subscription lifecycle event handling is done without losses — verified on projects with over 500k DAU.

Google Play Billing Library 6+ requires handling PurchasesUpdatedListener and explicitly calling acknowledgePurchase() or consumePurchase() within 3 days — otherwise Google automatically cancels the purchase and refunds. The average cost of such an error is a significant loss per user per month (based on our project data).

Ad Mediation: Boosting CPM via Bidding

Showing ads from a single source means losing revenue. Mediation (waterfall or bidding) requests ads from multiple networks and displays the best bid. Google AdMob is the foundation for banner, interstitial, rewarded ads. Mediation via AdMob Mediation or MAX (AppLovin) is the second de facto standard. MAX uses In-App Bidding — a real-time auction without waterfall. In practice, MAX yields significantly higher CPM than classic waterfall (depending on geo and audience). For example, for rewarded video in the US, the improvement can be substantial. With 100,000 rewarded video impressions per day, switching from waterfall to In-App Bidding can generate additional daily revenue.

ironSource (Unity Ads) has a strong position in the gaming segment, especially rewarded video. Mintegral covers the Asian audience well.

Setting up mediation requires ATT (App Tracking Transparency) on iOS 14+. Without requestTrackingAuthorization, ad CPM drops by 3-5 times for non-consenting users. SKAdNetwork and Privacy Manifest (iOS 17) are mandatory requirements; without them, review fails.

Network Ad Type Feature
AdMob banner, interstitial, rewarded Wide network, easy start
MAX (AppLovin) rewarded, interstitial In-App Bidding, high fill rate
ironSource rewarded video Best for games
Mintegral rewarded, native Asia, programmatic

How We Implement Monetization: Step-by-Step Process

  1. Current model audit — analysis of funnel, paywall, price tiers, and identification of bottlenecks.
  2. Model design — choose type (subscription, consumable, non-consumable) and optimize price points.
  3. IAP integration — set up StoreKit 2 / Google Billing 6, receipt validation, webhooks.
  4. Ad mediation — connect 3-6 networks, configure waterfall or In-App Bidding, test fill rate.
  5. Analytics and cohorts — integrate RevenueCat, Amplitude, or Firebase for LTV tracking.
  6. A/B testing of paywall — use Remote Config for experiments without a release.
  7. Launch and monitoring — 2 weeks of free support after launch, bug fixes by 24-hour SLA.

How to Design a Freemium Model and Paywall?

Freemium works when the boundary between free and paid is properly drawn. Too strict a paywall at the start — users delete. Too generous a free tier — no incentive to pay.

A technically sound pattern: server-side feature flags (Remote Config in Firebase or LaunchDarkly) control access to features. This allows A/B testing of paywall without a release, changing trial conditions, and running promotions.

Implementation at the code level: EntitlementManager — a single point for checking access to features, aware of subscription status, flags, and promos. No scattered isPremium checks throughout the code. Experience shows this approach reduces paywall-related bugs by 80% (confirmed on 30+ projects).

Checklist of Typical Monetization Mistakes
  • Missing handling of unfinished transactions — revenue loss of 5-10%.
  • No server-side idempotency for consumable processing — double crediting.
  • Forgot to call acknowledgePurchase() on Android — purchase cancelled after 3 days.
  • Not handling REFUND and DID_RENEW events — incorrect subscription status.
  • Paywall without A/B testing — leaving 20-40% of monetization potential.
  • Ads from a single source (e.g., AdMob without mediation) — CPM 15-30% lower.

Scope of Monetization Work

  • Current model audit — analysis of funnel, paywall, price tiers.
  • IAP integration — StoreKit 2 / Google Billing 6, receipt validation, webhooks.
  • Ad mediation — configure MAX / AdMob, connect 3-6 networks, test fill rate.
  • Analytics setup — RevenueCat, Amplitude / Firebase, cohort analysis.
  • Documentation — description of entitlements, restoration procedure, review checklist.
  • Team training — analysis of typical mistakes, support recommendations.
  • Guarantee — 2 weeks free support after launch, bug fixes by 24-hour SLA.

Estimated Timelines

Stage Duration
Basic IAP (one store) 1–2 weeks
Subscription system + RevenueCat + paywall 3–5 weeks
Ad mediation (MAX + 3 networks) 1–2 weeks
Full cycle (IAP + ads + analytics) 4–8 weeks

Cost is calculated individually. We have been working in this field for over 8 years and have implemented monetization in over 40 projects — many of which passed App Store Review without a single rejection. Contact us for an audit or order a consultation — we'll tell you what growth points exist in your app.