Whether to use an iOS boilerplate or build from scratch comes down to one question: is the scaffolding the interesting part of your app, or the tax you pay before you get to the interesting part? For a paid subscription app, the plumbing (RevenueCat, a paywall, App Store Connect products and their regional pricing, sign-in, a networking layer) is the same on every project and is almost never the idea you set out to build. A boilerplate is worth it when you want that plumbing to disappear so you can work on what makes your app different. Building from scratch is worth it when the learning is the point, your requirements are unusual, or you want zero dependencies you did not write.
This post lays out, honestly, what building the foundation from scratch actually involves, what a boilerplate gives you in exchange for what tradeoffs, and how to tell which side of the line your project is on.
On this page
- What building from scratch really involves
- What a boilerplate gives you
- When building from scratch wins
- When a boilerplate wins
- What to look for in a boilerplate
- FAQ
What building from scratch really involves
The reason this decision matters is that the foundation for a paid app is more work than it looks. Before you write a single feature that is actually yours, a subscription app needs:
- A subscription layer. RevenueCat or raw StoreKit 2, a paywall, purchase, restore, and entitlement checks that respect trials, grace periods, and family sharing.
- App Store Connect setup. The subscription products themselves, their group and levels, product IDs, and, if you care about international revenue, prices tuned across dozens of markets rather than a flat US price everywhere.
- Sign in with Apple. Required by Apple if you offer any other third-party login, plus the nonce and Keychain handling that goes with it.
- A networking layer, typed constants, and project structure. The unglamorous parts that make the codebase safe to grow: a typed HTTP client, generated asset and string constants so a typo is a build error, and a layout an AI agent can extend without reinventing your patterns.
None of this is your app's idea. It is the identical starting line for the tenth app as the first, which is exactly why it feels like a tax. Doing it well from scratch is a real chunk of time; doing it badly is where subscription bugs and App Store rejections come from. The subscription lifecycle post gives a sense of just how much is in that first bullet alone.
What a boilerplate gives you
A good boilerplate hands you that entire foundation already wired and building, so you start from a working paid app instead of an empty project. The upside is obvious: days of undifferentiated setup collapse into a download.
The tradeoffs are worth naming honestly:
- Dependency and lock-in risk. If a boilerplate is a black box or pulls in closed dependencies, you inherit someone else's choices and a project that might not build if they disappear. The mitigation is a boilerplate built on open-source packages you can read and keep.
- Code quality and currency. A boilerplate is only as good as its patterns. One that ships deprecated SwiftUI or sloppy structure just moves the cleanup earlier. You want current patterns and code you would have been happy to write.
- Fit. A boilerplate optimized for a standard subscription app may fight you if your app is genuinely unusual. The closer your app is to the well-trodden path, the more a boilerplate helps.
The question is not "is a boilerplate good" in the abstract, it is whether a specific one removes work you did not want to do without adding work you now have to undo.
When building from scratch wins
Building the foundation yourself is the right call in a few real cases:
- You are learning. If the point is to understand StoreKit, RevenueCat, and the App Store, building it yourself is the best way to learn it, and the time is not wasted because the learning is the deliverable.
- Your requirements are unusual. A non-standard purchase model, a heavily custom paywall, or constraints a general boilerplate does not anticipate can make a generic starting point more friction than help.
- You want zero dependencies you did not write. Some developers have a hard rule about owning every line. From scratch respects that.
- It is a hobby and the craft is the reward. If you enjoy building the plumbing, that is a completely valid reason. Not every project optimizes for shipping speed.
The honest signal: if the scaffolding is genuinely part of what you want out of the project, build it.
When a boilerplate wins
A boilerplate pays off when the opposite is true:
- You are shipping a fairly standard paid app and want to spend your time on its actual features, not on rebuilding subscriptions for the Nth time.
- You ship more than one app. The foundation is a recurring tax, and a boilerplate turns it into a one-time cost amortized across every project.
- The plumbing is not the product. If your app's value is its idea and the subscription layer is just how it gets paid, there is little reason to hand-build the part every app shares.
- International pricing matters to you. Actually creating and pricing subscription products across markets is the step most developers skip because it is tedious, and it is where a boilerplate that automates App Store Connect setup saves the most, not just paywall code. The pricing strategy post explains why that step is worth not skipping.
What to look for in a boilerplate
If you decide a boilerplate fits, the differences between them matter more than the pitch:
- Open-source dependencies, no lock-in. You should be able to read every package it uses, and the project should keep building if the vendor vanishes.
- Current SwiftUI, cleanly structured. Modern state management, no deprecated APIs, and a structure that both you and an AI coding agent can extend consistently rather than drift against.
- It actually builds, with no local tooling ceremony. Download, open in Xcode, build. If it needs a bootstrap script and three CLI installs before it compiles, that friction never fully goes away.
- It handles the App Store Connect and pricing part, not just paywall code. Most starter kits hand you a paywall and stop. The tedious, high-value part is creating and pricing the subscription products themselves, so a boilerplate that does that through the App Store Connect API is doing the work you most wanted to avoid.
FAQ
Is it better to use an iOS boilerplate or build from scratch?
It depends on your goal. Build from scratch if you are learning, have unusual requirements, or want to own every line. Use a boilerplate if you are shipping a fairly standard paid app, ship more than one app, or simply do not want to rebuild the same subscription plumbing again.
What does building a paid iOS app from scratch involve?
At minimum: a subscription layer (RevenueCat or StoreKit 2) with a paywall, purchase, restore, and entitlement checks; App Store Connect subscription products with regional pricing; Sign in with Apple if you use other logins; and a networking layer, typed constants, and a maintainable project structure.
Do boilerplates create lock-in?
They can, if they are a black box or use closed dependencies. Choose one built on open-source packages you can read, so your project keeps building even if the vendor disappears. Open dependencies are the main defense against lock-in.
Will a boilerplate save time on App Store pricing?
Only if it goes beyond paywall code to actually create and price your subscription products in App Store Connect. That setup, especially per-country pricing, is the tedious step most developers skip, so a boilerplate that automates it saves the most time.
Is a boilerplate worth it for just one app?
Often yes if the app is standard, because the setup you skip is a large fixed cost. It is most worth it across multiple apps, where the foundation is a recurring tax you pay once instead of every time.
What should I avoid in a boilerplate?
Closed or unreadable dependencies, deprecated SwiftUI or messy structure that you will have to clean up, and heavy local tooling just to get it building. Those move work around rather than removing it.
If you land on the boilerplate side of this decision, the part worth insisting on is the one most starter kits skip: actually creating and pricing your subscriptions, not just handing you paywall code. That is what Spaceport is built around. It generates a SwiftUI project on open-source packages with the paywall, purchase, and restore flow wired and building on the first try with no local tooling, and it creates and prices your subscription products in App Store Connect across 25 markets through the API, then matches them in RevenueCat. You start from a paid app that is already set up, not an empty project or a paywall with no products behind it. And when you are lining up a waitlist and launch-day audience for the app, our sister tool Lighthouse covers that side.
From an indie iOS dev, for indie iOS devs.