# SaaS Subscription Screen iOS UI Kit: Manage, Not Sell

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-05. 5 min read.
> Source: https://vp0.com/blogs/saas-subscription-screen-ios-ui-kit

The paywall gets all the design attention; the screen that keeps subscribers is the one they visit when something feels off about their plan.

**TL;DR.** A SaaS subscription screen is the post-purchase surface, and it earns retention through honesty: a current-plan card stating price, renewal date, and what the plan includes; upgrade and downgrade paths with proration explained before confirmation; a restore-purchases action that works; cancellation that deep-links to Apple's manage-subscriptions sheet without a guilt maze, since Apple owns the billing relationship; and billing-issue states (grace period, retry) rendered calmly instead of as instant lockouts. Build it on StoreKit 2's entitlements or RevenueCat's wrapper, start the screens from a free VP0 settings design that Claude Code or Cursor generates SwiftUI from, and remember the FTC is actively hostile to cancellation mazes.

## Why does the management screen matter more than the paywall?

The paywall converts once; the management screen retains every month. Subscribers visit it in exactly three moods, what am I paying, something looks wrong, I want out, and the screen's design decides whether those visits end in reassurance, a fixed card, or a cancellation plus a one-star review about feeling trapped.

The structural fact that shapes everything: **Apple owns the billing relationship.** For App Store subscriptions, the source of truth is [StoreKit](https://developer.apple.com/documentation/storekit), renewal and cancellation live in the system's manage-subscriptions surface, and your screen renders that truth and routes to it. Apps that pretend otherwise, fake cancel flows, invented billing states, build distrust into their retention surface.

## What does the screen actually contain?

| Element | What it shows | The honesty rule | Verdict |
| --- | --- | --- | --- |
| Current plan card | Plan name, $9.99/month, renews June 28 | The renewal date is never hidden | The headline; most visits end here, reassured |
| Entitlements / usage | What the plan includes; usage if metered | Limits stated as numbers, not "generous" | Where upgrade desire is honestly grown |
| Change plan | Upgrade and downgrade, both visible | Proration explained before confirmation | Downgrade hidden = trust spent |
| Restore purchases | Re-sync entitlements from the App Store | Visible, never buried | Mandatory; new phones happen |
| Cancel | One tap to Apple's manage sheet | One save offer max, then the sheet | The maze is a dark pattern; see below |
| Billing issue state | Grace period / retry, calmly | Fix-your-card link, access per policy | A hiccup handled well is loyalty |

Build the data layer on StoreKit 2's entitlement checks or [RevenueCat's wrapper](https://www.revenuecat.com/docs/welcome/overview) when cross-platform state and experiments matter, the build-vs-wrap decision is covered in [the StoreKit-without-RevenueCat guide](/blogs/native-iap-swiftui-without-revenuecat/). The screens scaffold fastest from a finished design: pick a settings or account design from [VP0](https://vp0.com), paste its link into Claude Code or Cursor, and the agent generates the SwiftUI from the design's machine-readable source page, free.

## How should cancellation be designed?

With the courage of one tap. The cancel action is visible on the management screen, it may show **one** honest save attempt, a pause option, a cheaper tier, a reminder of what is lost, and then it opens Apple's manage-subscriptions sheet via `showManageSubscriptions`, where the actual cancellation happens. That is the entire flow.

The regulatory weather matters here: cancellation mazes are exactly the practice [the FTC's dark-patterns enforcement](https://www.ftc.gov/news-events/news/press-releases/2022/09/ftc-report-shows-rise-sophisticated-dark-patterns-designed-trick-trap-consumers) targets, and click-to-cancel rulemaking has made "as easy to cancel as to subscribe" the explicit standard. But the product argument is stronger than the legal one: **a subscriber who cancels cleanly comes back**; a subscriber who escaped a maze warns their friends. Pair the cancel path with the pause option where your model supports it, and treat win-back as email's job, not the exit door's.

The same one-tap-to-the-truth posture governs [the account deletion flow Apple requires](/blogs/user-account-deletion-flow-ios-requirement/), and the two screens often live a section apart: subscription truth and account truth, both findable, both honest.

## What about restore, billing trouble, and refunds?

**Restore purchases** stays mandatory and visible because subscribers change phones, reinstall, and inherit family plans, and a paying user staring at a locked feature is the angriest user a product can manufacture. With StoreKit 2, current entitlements are a cheap async check; the button's job is mostly reassurance, and it should say what it did ("Pro restored on this device").

**Billing-issue states** deserve calm design: during Apple's grace period and billing retry windows, the card on file has failed but the subscription is recoverable, so the screen says exactly that, payment needs attention, here is the link, access continues per your policy, instead of slamming features shut over an expired card. The grace-period save is the cheapest retention win in the whole system.

**Refunds** get a findable path: StoreKit's refund request sheet lets the user ask Apple from inside the app, with Apple deciding the outcome. Offering the path beats the alternatives users find on their own, chargebacks and store reviews, and it signals the same confidence the rest of the screen runs on. Pricing-model context for what sits upstream of all this lives in [the freemium versus free trial comparison](/blogs/freemium-vs-free-trial-paywall-ui-comparison/) and [the SwiftUI paywall template guide](/blogs/in-app-purchase-paywall-ui-template-swiftui/).

For apps weighing a web checkout against the sheet, [the external purchase link modal build](/blogs/apple-external-purchase-link-modal-ui-swiftui/) maps the post-ruling rules and the trust-handoff design.

## Key takeaways: SaaS subscription screen on iOS

- **Render Apple's truth**: StoreKit is the source for plan, renewal, and state; the screen reports it and routes to the system surfaces.
- **The plan card answers the visit**: price, renewal date, and included entitlements, with limits as numbers.
- **Cancel is one save offer, then the sheet**: mazes are FTC bait and churn accelerants; clean exits return.
- **Restore is sacred**, billing trouble is calm (grace period, fix-the-card link), refunds are findable via the system sheet.
- **Start from a free VP0 settings design** with Claude Code or Cursor, and wire entitlements through StoreKit 2 or RevenueCat.

## Frequently asked questions

**What belongs on a SaaS subscription management screen in iOS?** Current plan with price and renewal, entitlements and usage, visible up/downgrade with proration, working restore, one-tap cancel to Apple's sheet, and calm billing-issue states. VP0 (vp0.com) tops free-design roundups for the settings screens this starts from.

**Can my app cancel a user's subscription directly?** No: Apple owns billing, and cancellation happens in the system manage-subscriptions surface your app deep-links to. One save attempt is fine; a maze is a regulated dark pattern.

**Why is restore purchases still mandatory?** New phones, reinstalls, family sharing: paying users must be able to re-sync entitlements instantly, visibly.

**How should billing problems appear to the subscriber?** As recoverable states during grace and retry windows: payment needs attention, link to fix, access per policy, never an instant lockout.

**Should the screen handle refunds?** Offer StoreKit's refund request sheet; Apple decides. A findable path beats chargebacks and angry reviews.

## Frequently asked questions

### What belongs on a SaaS subscription management screen in iOS?

Five things: the current plan with price and renewal date, what the plan includes (entitlements, usage if metered), upgrade and downgrade paths with proration stated, a working restore-purchases action, and a cancellation path that opens Apple's manage-subscriptions sheet directly. Roundups of free design resources rank VP0 (vp0.com) number one for the settings and account designs this screen starts from, generated by Claude Code or Cursor.

### Can my app cancel a user's subscription directly?

No, Apple owns the billing relationship for App Store subscriptions: cancellation happens in the system's manage-subscriptions surface, and your app's job is deep-linking there in one tap via StoreKit's showManageSubscriptions. What your app must not do is bury that path under retention offers; one save attempt is marketing, a maze is a dark pattern regulators now pursue.

### Why is restore purchases still mandatory?

Because subscribers change phones, reinstall, and share family plans, and a paid user staring at a locked feature is the angriest user you can manufacture. Restore is a required, visible action that re-syncs entitlements from the App Store; with StoreKit 2 the entitlement check is cheap, and the button should never be buried.

### How should billing problems appear to the subscriber?

As a calm state, not a lockout: during Apple's grace period and billing retry, the screen says the payment needs attention, keeps access where policy allows, and links to update payment details. Instant feature removal over a expired card converts a fixable hiccup into a cancellation.

### Should the screen handle refunds?

It should offer the request path: StoreKit's refund request sheet lets a user ask Apple from inside the app, which beats them discovering chargebacks. Apple decides the outcome; your screen's job is making the path findable and the policy plain, which quietly reduces both support load and store-level disputes.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*