SwiftUI Boilerplate: The Complete Guide for Indie iOS Developers

Building an iOS app from scratch means weeks spent on auth, onboarding, paywalls, and backend integration before writing a single line of your actual product. A SwiftUI boilerplate eliminates that pain by giving you a production-ready starting point. I have shipped six apps using boilerplates, and the difference between starting from zero and starting from a solid foundation is not incremental -- it is transformational.

In this guide I will walk you through exactly what a SwiftUI boilerplate is, what it should contain, how it compares to cross-platform alternatives, how to evaluate one before you buy, and the real economics behind building versus buying. By the end you will know whether a boilerplate is right for you and, if so, which boxes it absolutely must check.

What Is a SwiftUI Boilerplate?

A SwiftUI boilerplate (also called a SwiftUI SaaS boilerplate or iOS app starter kit) is a pre-built Xcode project that includes common features every app needs: authentication, onboarding screens, subscription paywalls, analytics, and backend connectivity. Instead of building these from scratch, you buy the SwiftUI source code once and customize it for every project.

Think of it like a house with the foundation, plumbing, and electrical already done. You are not buying a finished product -- you are buying a head start. The walls, paint, and furniture are yours to choose. A good boilerplate stays out of your way while giving you 80% of the infrastructure every production app needs on day one.

The key difference between a boilerplate and a tutorial project is production readiness. Tutorial code is designed to teach. Boilerplate code is designed to ship. That means proper error handling, accessibility labels, dark mode support, localization hooks, and architecture that scales beyond a weekend prototype. When you open the project in Xcode, you should be able to build, run, and see a working app in the simulator within five minutes -- sign-in flow, onboarding, and paywall included.

What a Boilerplate Saves You

The table below breaks down the most common features an iOS app needs, how long each one takes to build from scratch (based on my experience and estimates from other indie developers I have spoken to), and how long it takes when you start with a well-structured boilerplate.

Add those up and you are looking at 110-200+ hours of work to build all of this from scratch versus roughly 6 hours of configuration with a boilerplate. At a freelance rate of $100/hour, that is $11,000-$20,000 worth of development time saved. Even if you value your own time at $50/hour as a solo developer, you are still saving $5,000-$10,000 on every project.

Why Indie iOS Developers Use SwiftUI Boilerplates

• Save 100+ hours -- Skip repetitive setup across every new project
• Production-ready code -- Auth, paywalls, and backend are already tested
• Ship faster -- Go from idea to App Store in days, not months
• Focus on differentiation -- Spend time on what makes your app unique
• Consistent architecture -- Every project starts with the same clean patterns
• Fewer bugs at launch -- The boring plumbing has already been debugged

I want to emphasize that last point. The number-one cause of bad App Store reviews in the first week is broken auth flows, crashing paywalls, or missing edge cases in onboarding. These are exactly the modules a boilerplate gives you pre-tested. You eliminate an entire class of launch-day bugs before you write your first line of custom code.

The Anatomy of a Production-Ready Boilerplate

Not all boilerplates are created equal. A production-ready SwiftUI boilerplate should be organized around a clean, scalable architecture. Here is what that looks like in practice:

Architecture Pattern

The project should follow MVVM (Model-View-ViewModel) or a variation of it. Views stay thin. Business logic lives in ViewModels. Services abstract away network calls, persistence, and third-party SDKs. If you see a 500-line ContentView.swift with networking code inline, run.

Dependency Injection

A good boilerplate uses a dependency injection container rather than singletons scattered everywhere. This makes testing possible, swapping implementations trivial, and previews reliable. You should be able to inject a mock auth service for SwiftUI previews without touching production code.

Feature Flags

Feature flags let you ship code that is not yet ready for users, A/B test onboarding flows, and toggle functionality without redeploying. A boilerplate with a built-in feature flag system saves you from bolting one on later. Here is a minimal example of how feature flags might work:

// FeatureFlags.swift
enum FeatureFlag: String, CaseIterable {
    case newOnboarding
    case aiChat
    case socialLogin
    case premiumPaywall

    var isEnabled: Bool {
        switch self {
        case .newOnboarding:  return true
        case .aiChat:         return true
        case .socialLogin:    return false
        case .premiumPaywall: return true
        }
    }
}

// Usage in any view
if FeatureFlag.aiChat.isEnabled {
    AIChatView()
}

Configuration Layer

Every API key, product identifier, and environment variable should live in a single configuration file. You should never have to hunt through twenty files to set up a new project. Here is what a well-designed AppConfig.swift looks like:

// AppConfig.swift
struct AppConfig {
    // MARK: - App Identity
    static let appName       = "MyApp"
    static let bundleId      = "com.yourcompany.myapp"

    // MARK: - Supabase
    static let supabaseURL   = "https://your-project.supabase.co"
    static let supabaseKey   = "your-anon-key"

    // MARK: - RevenueCat
    static let revenueCatKey = "your-revenuecat-key"
    static let entitlement   = "premium"

    // MARK: - AI
    static let openAIKey     = "sk-..."
    static let aiModel       = "gpt-4o"

    // MARK: - Analytics
    static let telemetryAppID = "your-telemetry-id"
}

One file. Every secret in one place. You clone the repo, fill in your keys, and run. That is the experience a boilerplate should deliver.

SwiftUI Boilerplate vs Cross-Platform Alternatives

Before you commit to a native SwiftUI boilerplate, you might wonder whether React Native or Flutter would be a better choice. Here is an honest comparison:

If you are building an iOS-only app -- and most indie developers are -- a native SwiftUI boilerplate gives you the best performance, the smallest bundle, and zero dependency on third-party bridges for core platform features. If you need Android too, that is a different conversation, but for iOS-first developers, native is the right call.

How to Evaluate a SwiftUI Boilerplate

Before you spend money on a boilerplate, run through this checklist. I have bought three different boilerplates over the years and these are the criteria that actually matter:

1. Does it compile and run out of the box? -- Clone, open in Xcode, hit Run. If it fails, that is a red flag.
2. What iOS version does it target? -- It should target iOS 16+ at minimum. Ideally iOS 17+ for the latest SwiftUI features.
3. Is the architecture clean? -- Look for MVVM or similar. Check that views are not bloated with business logic.
4. Does it use dependency injection? -- Singletons everywhere means testing and previews will be painful.
5. Are SwiftUI previews working? -- If previews crash, the code quality is suspect.
6. How is configuration handled? -- One config file is good. Secrets scattered across the project is bad.
7. Is dark mode fully supported? -- Toggle dark mode in the simulator. If anything breaks, the theming is incomplete.
8. Does the paywall actually work? -- Connect RevenueCat sandbox and test a purchase flow end to end.
9. What does the auth flow look like? -- Sign in, sign out, delete account. All three should work.
10. Is there documentation? -- A boilerplate without docs is just someone else's messy project.
11. Is it actively maintained? -- Check the last commit date. If the last update was 8 months ago, move on.
12. Does the developer offer support? -- A Discord community, email support, or GitHub issues matter when you get stuck.

What to Look for in the Best SwiftUI Boilerplate

The best SwiftUI boilerplate for 2025 should include:

• SwiftUI onboarding screen templates (multiple styles -- carousel, highlights, minimal)
• RevenueCat + StoreKit 2 paywall integration with restore purchases and free trials
• Supabase SwiftUI integration for auth and database
• Sign in with Apple ready to go
• AI integrations -- ChatGPT, image generation, vision
• Dark mode support, design tokens, and customizable themes
• Analytics pre-wired (TelemetryDeck, PostHog, or similar)
• Push notification scaffolding
• Settings screen with account management
• Proper error handling and loading states throughout

Common Mistakes When Using a Boilerplate

Even with a great boilerplate, developers make avoidable mistakes. Here are the five I see most often:

1. Not reading the documentation first

I know, obvious. But most developers clone the repo and start hacking immediately. Then they spend three hours debugging something that was explained in a two-paragraph setup guide. Read the docs. All of them. It takes 15 minutes and saves you hours.

2. Modifying core modules instead of extending them

When you change the internal implementation of the auth service or paywall manager, you make it impossible to pull updates from the boilerplate later. Instead, extend via protocols, add new files, and override behavior through the DI container. Keep the core untouched.

3. Leaving placeholder content in production

I have seen apps ship with "Lorem ipsum" in the onboarding, default app icons, and even the boilerplate author's RevenueCat API key. Create a checklist of everything you need to replace before submitting to the App Store.

4. Ignoring the architecture patterns

If the boilerplate uses MVVM with a service layer, do not start throwing networking code into your views because it is faster in the moment. The architecture exists for a reason. Follow it, and your codebase stays maintainable as it grows.

5. Not testing the purchase flow in sandbox

Your paywall might look perfect in the UI, but if you have not tested an actual StoreKit sandbox purchase end-to-end, you are shipping blind. RevenueCat sandbox mode, StoreKit testing in Xcode, and a real sandbox Apple ID -- test all three before you submit.

The Economics: Building vs Buying

Let us put real numbers on this. The table below estimates the cost of building each feature from scratch at various hourly rates versus buying a boilerplate for a one-time price.

Even at the lowest rate, the math is overwhelming. A $99 boilerplate pays for itself before you finish configuring Supabase. And this is per project -- if you ship two apps a year, you are saving $15,000+ annually at a modest rate. For agencies shipping client projects, the ROI is absurd.

There is also an opportunity cost that does not show up in the table. Every hour you spend wiring up auth is an hour you are not spending on the feature that makes your app different. The feature that gets you featured on the App Store. The feature that makes users tell their friends. That opportunity cost is, in my experience, the biggest reason to use a boilerplate.

The Swift Kit: The Best SwiftUI Boilerplate for Indie Developers

The Swift Kit is a complete SwiftUI boilerplate built specifically for indie iOS developers and solopreneurs. It includes everything listed above -- onboarding templates, RevenueCat paywall integration, Supabase backend, AI features, analytics, theming, and more. One-time purchase, unlimited projects, lifetime updates.

What sets it apart is the developer experience. Configuration lives in a single file. The architecture is clean MVVM with dependency injection. SwiftUI previews work for every screen. And there is an active community of indie developers building with it, so when you get stuck, help is a message away.

If you are serious about shipping iOS apps and you do not want to spend your first two weeks on plumbing, check out the pricing page or browse the documentation to see if it fits your workflow. I built it because I was tired of rebuilding the same infrastructure for every project, and I think you will find it saves you a lot more than the sticker price suggests.