Ecommerce App Boilerplate for iOS

The payments rule that decides your whole ecommerce app

The single most important thing to get right in an iOS shopping app is not the cart — it is which payment system Apple forces you to use. Apple's guidelines are firm: physical goods and real-world services must be sold through an external processor like Stripe or Apple Pay, and Apple takes no cut. Digital content and services consumed inside the app must be sold through StoreKit in-app purchase, where Apple does take its commission. Mixing these up is one of the most common causes of rejection. A clothing store or a food-delivery app uses Stripe; a coin pack or a premium-content unlock uses IAP. The Swift Kit does not hide this from you or pretend one rail fits all — it ships a RevenueCat and StoreKit layer for the digital case, and leaves you a clean place to integrate Stripe or Apple Pay for physical goods, because that is the architecture Apple actually approves.

• Physical goods and services: external processor (Stripe, Apple Pay), no Apple commission
• Digital content consumed in-app: StoreKit / in-app purchase, Apple commission applies
• Getting this wrong is a top cause of App Store rejection
• The kit ships the IAP/RevenueCat side and leaves Stripe integration clean to add

Catalog, cart, and the state that a shopping app lives on

Under the payment question, an ecommerce app is a catalog plus a cart plus orders. The Swift Kit gives you the architecture for all three. Products live in Supabase Postgres with images in Supabase storage, so your catalog is server-driven and you can change prices and stock without shipping an app update. The centralized design system means product cards, the grid, and the detail screen retheme from one file. The cart itself is client state that you own — a small, observable model that tracks lines and totals — and the kit's clean architecture keeps it out of your view code. When an order is placed, it is written back to Postgres tied to the user's account, so order history and reorder both work.

import SwiftUI

struct Product: Identifiable, Codable {
    let id: UUID
    let name: String
    let price: Decimal
}

struct CartLine: Identifiable {
    let id = UUID()
    let product: Product
    var quantity: Int
}

@Observable
final class Cart {
    private(set) var lines: [CartLine] = []

    func add(_ product: Product, quantity: Int = 1) {
        if let i = lines.firstIndex(where: { $0.product.id == product.id }) {
            lines[i].quantity += quantity
        } else {
            lines.append(CartLine(product: product, quantity: quantity))
        }
    }

    var subtotal: Decimal {
        lines.reduce(0) { $0 + $1.product.price * Decimal($1.quantity) }
    }
}

Accounts, orders, and order-status notifications

A shopping app without accounts is a demo. Real ecommerce needs users so orders, addresses, and payment methods persist and reorder is one tap. The Swift Kit ships Sign in with Apple and email auth, and stores orders and order status in Supabase Postgres tied to that account. Push notifications — which the kit includes — are what a shopping app uses constantly: order confirmed, order shipped, out for delivery, back in stock. You wire your fulfillment logic to trigger them; the registration and delivery plumbing is already there. Analytics let you see where the funnel leaks between product view, add-to-cart, and checkout, and onboarding gets a first-time shopper to a purchase with less friction.

• Sign in with Apple + email so orders, addresses, and reorder persist
• Supabase Postgres for products, orders, and order status
• Push notifications for confirmed, shipped, delivered, and back-in-stock
• Analytics on the view → add-to-cart → checkout funnel

When RevenueCat and biometric auth earn their keep

Two kit features are quietly valuable to ecommerce even though they are not obvious catalog features. First, RevenueCat: many shopping apps run a paid membership — think free shipping and member pricing for a monthly fee. That membership is a digital subscription, which means it belongs on StoreKit, and RevenueCat is exactly the layer for it, wired and ready. Second, biometric authentication: Face ID and Touch ID to confirm a purchase or unlock a saved-payment screen is both a security expectation and a conversion win, and the kit ships it. Localization is included too, which for a store means currency and language for different markets — a real requirement the moment you sell across borders.

• RevenueCat for paid memberships (free shipping, member pricing) — a digital subscription on StoreKit
• Biometric auth (Face ID / Touch ID) to confirm purchases and protect saved payment info
• Localization for currency and language across markets
• A design system so a seasonal or brand retheme is a one-file change

What you build on top

The Swift Kit is not a finished store. There is no bundled Stripe checkout, no inventory management backend, no shipping-rate calculator, no product data. That is expected — your catalog, your pricing, your fulfillment, and your Stripe or Apple Pay integration are your business, and a boilerplate should not fake them. What the kit removes is the roughly 30% of any shopping app that is identical everywhere: accounts, catalog and order storage, cart architecture, push notifications, biometric confirmation, localization, and a design system. It also removes a costly mistake — by being explicit that physical goods use Stripe and digital goods use IAP, so you do not architect your payments the wrong way and discover it at App Review.

Building an ecommerce app: from scratch vs with The Swift Kit

Frequently Asked Questions