SaaS Subscription Screen iOS UI Kit: Manage, Not Sell

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, 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 when cross-platform state and experiments matter, the build-vs-wrap decision is covered in the StoreKit-without-RevenueCat guide. The screens scaffold fastest from a finished design: pick a settings or account design from VP0, 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 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, 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 and the SwiftUI paywall template guide.

For apps weighing a web checkout against the sheet, the external purchase link modal build 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.