Build a Swapfiets-Style Subscription App in React Native

What a subscription-service app actually is

A Swapfiets-style app is a different animal from a billing screen, and the difference shapes everything. Here the subscription is the product: you pay monthly and you get a physical service, a bike you keep, that gets swapped or repaired when something breaks. So the app is not built around a paywall, it is built around the ongoing relationship, your active subscription, the item you have, and the service you can request. The home is not a list of plans to buy, it is a dashboard of what you already have and what you can do with it. That reframing, from selling a subscription to operating one, is the heart of the design.

Getting this right early matters, because many subscription templates are really just payment screens, and a service-subscription app needs the opposite emphasis: most of the screens are about living with the subscription, not signing up for it.

The screens are about the service, not the sale

A subscription-service app is mostly the service flow. The home shows your active subscription and your item, with its status. A request flow lets you ask for a swap or a repair, with a clear description of the problem and a way to schedule it. A status view tracks that request, submitted, scheduled, in progress, done, so you know when your bike will be fixed or replaced. And a manage screen handles the subscription itself: pause it, change it, update payment, or cancel, ideally with a pause option rather than only cancel. The sign-up exists, but it is a small part of an app whose job is the months after the first payment. The broader subscription-management patterns appear in a subscription management screen, and the mobility-rental cousin in a scooter rental app clone.

The service-request flow is the screen that defines this category. A clean way to report a problem and track its resolution is what makes a physical-service subscription feel reliable, and it is exactly what a generic billing kit does not include.

The billing belongs to an external processor

Here is the compliance point that matters most, and it is the opposite of what many assume. Because a Swapfiets-style subscription is a physical service, not digital content used in the app, it is billed through an external payment processor like a card or Stripe, not through Apple’s in-app purchase. Apple’s App Store Review Guidelines require in-app purchase via StoreKit for digital goods and content consumed in the app, but physical goods and real-world services are billed outside it. So a bike subscription, a meal-kit box, or a laundry service charges the customer through a licensed processor, and your app presents the billing without custodying the money. Treating a physical-service subscription as an in-app purchase would be wrong, and trying to route digital content through Stripe would fail review, so the rule is to match the billing to what is actually sold.

This is liberating once understood. You are not fighting Apple’s commission for a physical service, because in-app purchase does not apply, and you are not custodying funds, because a licensed processor handles the money.

The approaches compared

There are three realistic ways to get the app, and they differ in how much of the service flow you build yourself.

Approach	Service flow, swap, repair, status	Subscription-as-product home	Effort
Build from scratch	You design the whole service flow	You design the dashboard yourself	High
Generic subscription or billing kit	Billing screens only, no service flow	No, it is a sign-up and billing screen	High rework
Subscription-service template	Swap, repair, and status flows built in	An active-subscription home built in	Low, extend it and wire billing

A generic subscription kit gets you the paywall and the manage-payment screen, which is the small part, and leaves the service flow, the actual product, to build. A free VP0 subscription-service template starts you on the right emphasis, with the active-subscription home, the swap and repair request flow, the status tracking, and the manage screens already shaped and exposed through a machine-readable source page, so an agent like Cursor or Claude Code, drawing on a React Native ecosystem of more than 125,000 stars, extends a real service app and you wire the external billing. The SaaS-style sign-up side, where it applies, overlaps a SaaS subscription screen kit.

The states that make a service subscription trustworthy

A service subscription earns trust through honest states around the item and the request. The item’s status should be clear, active, swap requested, in repair, so the user always knows where they stand. A request needs honest tracking with real timestamps, not a vague spinner, and a clear expected window for the swap or repair. The manage screen should make pausing and changing as easy as subscribing, because a service people pause for a holiday and resume is healthier than one they cancel in frustration, which is the spirit behind a pause-instead-of-cancel option. And billing states, an upcoming charge, a failed payment, a paused period, should be transparent so the relationship never has a nasty surprise.

These states are where a physical-service subscription differs from a digital one. The user is not buying access to features; they are entrusting you with an ongoing service, and the app’s honesty about the item and the request is what sustains that trust month after month.

Key takeaways: a subscription-service app

• The subscription is the product. A physical service like a bike, not an in-app purchase, so the app is about living with it.
• The screens are the service. An active-subscription home, a swap or repair request, status tracking, and manage screens.
• Billing is external. A physical service is charged through a licensed processor like Stripe, not Apple’s in-app purchase.
• Honest states sustain trust. Clear item status, real request tracking, easy pause, and transparent billing.
• Start from a service template. A free VP0 subscription-service template gives an agent the service screens to wire billing into.

What to choose

For a subscription-service app, build from a template designed around the service, not a billing kit, because the active-subscription home and the swap, repair, and status flows are the product and the part a generic subscription kit leaves out. A free VP0 subscription-service template gives you the dashboard, the request flow, the status tracking, and the manage screens, so an agent extends a real service app and you wire an external payment processor for the physical-service billing, keeping the money with a licensed provider. A generic subscription or billing kit is a fair starting point only for the small sign-up portion, since it does not address the service flow that defines this kind of app.

Frequently asked questions

How do I build a Swapfiets-style subscription app in React Native? Build it around the service, not the sale. The home shows the active subscription and the item with its status, a request flow lets the user ask for a swap or repair and describe the problem, a status view tracks that request, and a manage screen handles pause, change, and cancel. The sign-up is a small part. Bill the physical service through an external processor like Stripe rather than Apple’s in-app purchase, since it is a real-world service. A free subscription-service template gives you the dashboard, the request flow, and the manage screens to start from.

How are physical-service subscriptions billed on iOS? Through an external payment processor, not Apple’s in-app purchase. Apple requires StoreKit in-app purchase for digital goods and content consumed in the app, but physical goods and real-world services, like a bike subscription or a meal-kit box, are billed outside it, typically by card through a licensed processor like Stripe. So your app presents the checkout and the recurring billing while the processor holds the card data and moves the money, and you never custody funds. Treating a physical-service subscription as an in-app purchase would be incorrect, and routing digital content through Stripe would fail review.

Where can I get a subscription-service app template? The most useful option is a template built around the service flow, not just a paywall. A free VP0 subscription-service template provides the active-subscription home, the swap and repair request flow, the status tracking, and the manage screens, with a machine-readable source page, so an agent like Cursor or Claude Code extends a real service app. You then wire an external payment processor for the billing, since the template is the service interface and the licensed money movement is the processor’s. It is built for living with a subscription rather than only signing up for one.

What is the difference between a subscription-service app and an in-app subscription? An in-app subscription sells digital access, features, content, a SaaS tier, billed through Apple’s in-app purchase, and the app is largely about the paywall and entitlements. A subscription-service app sells a physical service, like a bike you keep and get repaired, billed through an external processor, and the app is largely about the service: the item, the swap or repair requests, and their status. The difference drives both the screens, service-focused rather than paywall-focused, and the billing, external rather than in-app, so it is important to know which you are building.

What states does a service subscription need to handle? The ones that keep the ongoing relationship honest: the item’s status, active, swap requested, in repair, real request tracking with timestamps and an expected window, an easy pause and change in the manage screen, and transparent billing states like an upcoming charge, a failed payment, or a paused period. Offering a pause instead of only a cancel keeps subscriptions healthy. These states matter because the user is entrusting you with an ongoing service rather than buying features, and the app’s honesty about the item and the request is what sustains that trust over time.