# How to Build a Mobile App as a Solo Developer (No Funding)

> How to build a mobile app as a solo developer: pick a stack, set up backend, payments and testing, ship to both stores in 12 weeks for about $124 in year one.

- Canonical: https://zeroraised.com/blog/how-to-build-a-mobile-app-as-a-solo-developer
- Published: 2026-11-10T13:30:00Z
- Author: ZeroRaised Team (https://zeroraised.com/blog/authors/zeroraised)
- Publisher: ZeroRaised (https://zeroraised.com/)
- Section: Building
- Tags: indie-apps, mobile, developer-tools, mvp

**Short answer:** To build a mobile app as a solo developer, scope it to one core job, pick a cross-platform stack you already half-know (React Native with Expo, or Flutter), lean on free tiers for backend, crash reporting, purchases and cloud builds, and design around the store rules on login, account deletion, privacy and testing from week one. The unavoidable cash cost is about $124 in year one: 99 USD for Apple and US$25 for Google Play. The rest of your budget is time, and a 12-week plan keeps it honest.

Every price, limit and rule below comes from the vendor's or store's own page, checked on 10 Nov 2026 and linked inline. The advice in between is ours and is marked "Our read".

## TL;DR

- **Decide the format first.** If your app is mostly forms, content and lists, a web app or PWA may be enough. Go to the stores when you need push, purchases, offline use, device hardware or store discovery.
- **Default stack for one person:** React Native with Expo or Flutter, one codebase for iOS and Android. React Native's homepage says "To build a new app with React Native, we recommend a framework like Expo" ([React Native](https://reactnative.dev/)).
- **Fixed costs:** Apple's "annual fee is 99 USD" ([Apple enrollment](https://developer.apple.com/support/enrollment/)); Google has "a US$25 one-time registration fee" ([Google Play Console help](https://support.google.com/googleplay/android-developer/answer/6112435)).
- **No Mac? Still possible.** Expo says "you can use Expo Build to build your app in the cloud" ([Expo FAQ](https://docs.expo.dev/faq/)), but you will test on a real iPhone.
- **Rules that bite late:** equivalent private login if you use Google or Facebook sign-in (Apple Guideline 4.8), in-app account deletion on both stores, privacy labels, and Google's 12 testers for 14 days for new personal accounts.
- **Free tiers carry you far:** Expo Free, Supabase or Firebase, Crashlytics, and RevenueCat up to $2,500 in monthly tracked revenue.

**Disclosure:** ZeroRaised publishes this guide and is a launch site for bootstrapped products; it appears in the final section. ZeroRaised has no commercial relationship with any vendor named here and earns nothing if you sign up. Facts come from the linked sources as checked on 10 Nov 2026. This guide makes no promise of approval, downloads or revenue.

## What this guide covers, and what it links out to

This is the build guide: from a scoped idea to a working build in both the App Store and Google Play. It covers the decisions one person has to make alone (format, framework, Mac or no Mac, backend, payments plumbing, analytics, privacy, testing, builds and updates) with a 12-week plan and a first-year cost table.

It deliberately does not redo the rest of the journey. When you get to store submission, the [App Store launch guide](https://zeroraised.com/blog/how-to-launch-an-app-on-the-app-store) covers App Review, release options and launch day in detail, and our Google Play guide (linked in the testing step) does the same for Android. Business models get their own guide, linked in the payments step.

## Step 1: Scope the app so one person can finish it

The most common reason solo apps never ship is not the framework. It is scope. A team of five can build onboarding, social features, a web dashboard, an admin panel and three platforms in parallel. You cannot.

Our read: write the app down as one sentence in the form "A [specific person] uses this to [one job] in under [time]". Then list every screen you think you need and cut it to the screens that sentence requires. For most first versions that is five to eight screens: onboarding or sign-in, the core screen, one or two supporting screens, settings (which must include account deletion if you have accounts, more on that below) and a paywall if you charge.

Three filters help cut:

1. **Does the core job work without it?** If yes, it waits for version 1.1.
2. **Does it add a platform-specific risk?** Background location, Bluetooth, widgets, HealthKit, Apple Watch and CarPlay each add native work and review questions. Keep at most one in version 1.
3. **Does it need its own backend?** Chat, feeds and anything multiplayer mean real-time infrastructure and moderation. If your idea needs them, it may be a bigger build than a solo first version.

If you want a fuller method for deciding what goes in, our guide on [how to build an MVP as a solo founder](https://zeroraised.com/blog/how-to-build-an-mvp-as-a-solo-founder) covers scoping, validation and the "what to leave out" list in general terms. The rest of this guide assumes you have a scope you can describe in one sentence.

## Step 2: Web app, native, or cross-platform?

Before choosing a framework, decide whether you need the app stores at all. This is our decision guide, not a rule from Apple or Google.

| Your app needs | Our pick | Why |
|---|---|---|
| Content, forms, dashboards, mostly used at a desk | Web app or PWA | One deploy, no review, no store fees, works everywhere |
| Push notifications, in-app purchases, offline use, camera or sensors, a home-screen icon people actually use | Cross-platform native (React Native + Expo, or Flutter) | One codebase, both stores, real native access |
| One platform only, or heavy platform features (widgets, watch, deep OS integration) | Fully native (Swift/SwiftUI or Kotlin) | Best access and tooling for that platform, no bridge |
| Shared business logic, but native UI per platform, and you already know Kotlin | Kotlin Multiplatform | Share logic, keep native UI where it matters |
| You do not write code and the app is a simple CRUD tool | No-code builder | Fastest path, with limits on custom behaviour |

Two concrete criteria settle most cases:

- **Will people open it more than once a week, away from a desk?** Habit apps, trackers, utilities and companions for a physical activity live on the phone. A tool people use at work on a laptop usually does not need to.
- **Do you need to charge inside the app or send push?** If your revenue depends on subscriptions bought on the phone, or retention depends on reminders, a store app is the natural home. If people pay on your website, a web app keeps all of that simpler.

If you do not code, a no-code builder can get a simple app into the stores, though you trade away control over performance, offline behaviour and custom native features. Our roundup of [the best no-code app builders for solo founders](https://zeroraised.com/blog/best-no-code-app-builders-for-solo-founders) compares the options and their prices. The rest of this guide is for people writing code.

## Step 3: Pick a framework you can maintain alone

The best framework for a solo developer is the one you can still debug at 11pm, a year from now, with no one to ask. Here is what each official site says today, and how we would decide.

### React Native with Expo

React Native lets you write the app in JavaScript or TypeScript with React, rendering native components. The project itself steers new apps towards a framework: its setup docs say "if you're building a new app with React Native, we recommend using a Framework" and that "most developers benefit from using a React Native Framework like Expo" ([React Native environment setup](https://reactnative.dev/docs/environment-setup)).

Current versions when we checked: the React Native blog announced React Native 0.88 on 19 October 2026 ([React Native blog](https://reactnative.dev/blog)), and Expo's reference lists SDK 58.0.0, built on React Native 0.88 ([Expo SDK versions](https://docs.expo.dev/versions/latest/)). React Native 0.82 was described by the project as "the first React Native that runs entirely on the New Architecture", so a new project today starts on it.

Note a naming change if you read older tutorials: Expo's pricing page now says "EAS Build is now Expo Build, EAS Update is now Expo Update", while the CLI keeps the `eas` name ([Expo pricing](https://expo.dev/pricing)).

Our read: if you already build for the web in React, this is the shortest path to a store app. You reuse your language, much of your tooling and often your API client code.

### Flutter

Flutter is Google's toolkit for building apps from one Dart codebase, drawing its own UI rather than wrapping native components. Flutter's "What's new" page listed release 3.47, dated 12 August 2026, as its latest entry when we checked ([Flutter what's new](https://docs.flutter.dev/release/whats-new)). Its install page says you can set up development tools for "Android, iOS, web (requires only a supported browser), Windows, macOS, or Linux" ([Flutter install](https://docs.flutter.dev/get-started/install)).

Our read: Flutter suits people who want one consistent toolkit with strong built-in UI widgets and are happy to learn Dart. Pixel-identical design across iOS and Android is easier here.

### Native: Swift/SwiftUI and Kotlin

Fully native means Xcode and Swift for iOS, Android Studio and Kotlin for Android: two codebases. Apple's Xcode page describes it as offering "the tools you need to develop, test, and distribute apps for Apple platforms", including "simulators for Apple devices", and the current release is Xcode 27 ([Apple Xcode](https://developer.apple.com/xcode/)).

Our read: for one person, native makes sense when you are launching on one platform first (often iOS, if your audience skews that way) or when the app is mostly platform features such as widgets, Live Activities or watch apps. Two native codebases double the work of every feature and every bug fix, which is the cost a solo developer can least afford.

### Kotlin Multiplatform (briefly)

Kotlin Multiplatform shares Kotlin code across platforms. Its official page says it is "production-ready for all supported platforms" and that "Compose Multiplatform is stable for Android, iOS, and desktop, while the web target is currently in Beta" ([Kotlin Multiplatform](https://kotlinlang.org/multiplatform/)). Our read: a good fit if you are already an Android developer in Kotlin. If you are starting from the web, React Native with Expo is usually the shorter road.

### Framework comparison for one person

This table is ours, based on the official pages above.

| | React Native + Expo | Flutter | Native (Swift + Kotlin) | Kotlin Multiplatform |
|---|---|---|---|---|
| Language | JavaScript / TypeScript | Dart | Swift and Kotlin | Kotlin (plus Swift for some iOS work) |
| Codebases | One | One | Two | Shared logic, optional shared UI |
| Current version (checked 10 Nov) | RN 0.88, Expo SDK 58 | 3.47 | Xcode 27 | Stable per official page |
| UI approach | Native components | Draws its own UI | Native | Native UI or Compose Multiplatform |
| Cloud iOS builds without a Mac | Yes, via Expo Build | Via third-party CI (Codemagic, Bitrise) | Via third-party CI | Via third-party CI |
| Over-the-air JS updates | Yes, Expo Update | No built-in equivalent | No | No |
| Best for | Web developers, fastest to both stores | Custom UI, one consistent toolkit | One platform, deep OS features | Existing Kotlin developers |

Our read: if you are undecided, choose React Native with Expo when you know TypeScript and Flutter when you do not mind learning Dart. Then stop researching. Switching frameworks halfway through costs more than picking the second-best one.

## Do you need a Mac to build an iOS app?

This is the question that stops a lot of Windows and Linux developers, so here is what the official pages say.

Apple's tools are Mac software. The Xcode page invites you to "Prototype on every device, all from your Mac", and Xcode includes the iOS simulators ([Apple Xcode](https://developer.apple.com/xcode/)). Apple also sets a minimum toolchain for uploads: "Apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26" ([Apple upcoming requirements](https://developer.apple.com/news/upcoming-requirements/)). That build has to happen on a Mac somewhere, but it does not have to be yours.

Cloud build services run those Macs for you:

- **Expo:** its FAQ says "Traditionally you needed a macOS to develop iOS apps, however, you can use Expo Build to build your app in the cloud" ([Expo FAQ](https://docs.expo.dev/faq/)), and its build docs say "iOS builds run on macOS runners hosted in Expo's macOS cloud" ([Expo Build introduction](https://docs.expo.dev/build/introduction/)). For submission: "Expo Submit works on macOS, Linux, and Windows, so you don't need a Mac to ship iOS builds" ([Expo Submit for iOS](https://docs.expo.dev/submit/ios/)).
- **Codemagic:** the free personal plan includes "500 free macOS M2 minutes / month" with "Max 1 parallel build" ([Codemagic pricing](https://codemagic.io/pricing/)).
- **Bitrise:** "The Hobby plan is free, with 500 build minutes a month on Linux or macOS, 1 private app, and unlimited public apps" ([Bitrise pricing](https://bitrise.io/pricing)).

What a cloud build does not give you is the Simulator. Without a Mac, you test on a real iPhone. Expo's development-build flow, for example, is started from the CLI:

```bash
eas build --platform ios --profile development
```

That command appears in Expo's environment setup docs as the cloud route to a development build ([Expo environment setup](https://docs.expo.dev/get-started/set-up-your-environment/)), and Expo's [tutorial on development builds for iOS devices](https://docs.expo.dev/tutorial/eas/ios-development-build-for-devices/) walks through installing one on a physical iPhone.

Our read: you can ship your first iOS app without owning a Mac. But when a native build fails with an obscure signing or CocoaPods error, a Mac makes debugging much faster. If the app starts earning, a used Mac is often the first hardware purchase worth making. And whatever you build on, own at least one real iPhone and one real Android phone.

## Step 4: Open the developer accounts early

Do this in week one, not the week you want to ship. Enrolment has paperwork, and Google has a testing clock that only starts once you have an account.

| Account | Cost | What to know |
|---|---|---|
| Apple Developer Program | "The Apple Developer Program annual fee is 99 USD ... in local currency where available" ([Apple enrollment](https://developer.apple.com/support/enrollment/)) | Fee waivers exist for nonprofits, accredited educational institutions and government entities ([Apple fee waivers](https://developer.apple.com/help/account/membership/fee-waivers/)); a solo developer will not usually qualify |
| Google Play Console | "There is a US$25 one-time registration fee" ([Google Play Console help](https://support.google.com/googleplay/android-developer/answer/6112435)) | New personal accounts must run a closed test before production (see Step 9) |

You can start building and testing before you pay Apple. Apple's membership comparison says "To install and test your apps on a personal device, you'll need to sign in to your Apple Account in Xcode", and an account without a membership shows as a Personal Team, with a limit: "You can register up to 3 devices, which expire after 7 days" ([Apple compare memberships](https://developer.apple.com/support/compare-memberships/)). That route needs Xcode, so it assumes a Mac. Our read: pay the 99 USD when you are ready for TestFlight, not before.

## Step 5: Backend, auth and data

Most solo apps need three server-side things: a database, user accounts and somewhere to run a little logic (webhooks, scheduled jobs, push triggers). You have two routes.

**Backend-as-a-service (BaaS).** Supabase or Firebase gives you auth, a database, storage and functions with an SDK you call from the app. On today's pricing pages:

- **Supabase Free:** "500 MB database size" and "50,000 monthly active users", with the catch that "Free projects are paused after 1 week of inactivity. Limit of 2 active projects." Pro is "from $25/month", and "Projects on paid plans aren't paused for inactivity" ([Supabase pricing](https://supabase.com/pricing)).
- **Firebase:** Authentication on the no-cost Spark plan covers 50K monthly active users, and the Blaze plan is no-cost up to 50K MAUs before Google Cloud pricing applies ([Firebase pricing](https://firebase.google.com/pricing)).

**Your own API.** A small server you write (Node, Go, Python, whatever you know) on a cheap host with a managed Postgres. More control, no vendor-specific SDK, but you own auth, security patches and uptime.

Our read: for a solo first version, use a BaaS. Auth is where solo developers lose weeks and make security mistakes, and both options handle sign-in for you instead of you writing it. Keep your business logic in a thin layer of your own (a few functions or one small service) so moving later is a migration, not a rewrite. Our [Supabase vs Firebase comparison](https://zeroraised.com/blog/supabase-vs-firebase-for-indie-makers) goes through the trade-offs (SQL vs NoSQL, pricing shape, lock-in) in depth.

### The two login rules to design for now

**Sign in with Apple, or an equivalent.** If you add Google, Facebook or other social login, Apple's App Review Guideline 4.8 applies. Verbatim: "Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Log in with X, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user's primary account with the app must also offer as an equivalent option another login service with the following features:" the login service "limits data collection to the user's name and email address"; it "allows users to keep their email address private as part of setting up their account"; and it "does not collect interactions with your app for advertising purposes without consent" ([App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)). The guideline lists exemptions, starting with apps that exclusively use "your company's own account setup and sign-in systems".

Our read: the simplest compliant setups are email-only login (magic link or password) or offering Sign in with Apple alongside Google. Check that your auth provider supports it before you commit, and wire it in at the start rather than after a rejection.

**Account deletion.** If people can create an account, both stores require you to let them delete it:

- Apple, Guideline 5.1.1(v): "If your app supports account creation, you must also offer account deletion within the app" ([App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)).
- Google Play: "If your app enables account creation, you must:" "provide users with an in-app path to delete their app accounts and associated data" and "provide a web link resource where users can request app account deletion and associated data deletion" ([Google Play account deletion policy](https://support.google.com/googleplay/android-developer/answer/13327111)).

Our read: build one "Delete account" button in Settings that calls a server function which deletes the user and their data, and one simple web page that does the same after the user signs in. Then you satisfy both stores with one piece of work. Do it in the same week you build sign-up.

## Step 6: In-app purchases plumbing

If you charge for digital features or content inside the app, the stores' own billing systems are the default route.

- **Apple:** "StoreKit provides a simple and secure way to purchase digital goods or services in your apps across all Apple platforms" ([Apple StoreKit](https://developer.apple.com/storekit/)).
- **Google:** "Google Play's billing system is a service that enables you to sell digital products and content in your Android app", integrated "using the Play Billing Library", and it "is only for digital items" ([Google Play Billing](https://developer.android.com/google/play/billing)). Google's Payments policy says apps distributed on Play that sell in-app features, digital content or goods "must use Google Play's billing system for those transactions", subject to exceptions listed in the policy ([Google Play Payments policy](https://support.google.com/googleplay/android-developer/answer/9858738)).

Integrating StoreKit and Play Billing directly is two separate implementations, plus server-side receipt validation and subscription state syncing. A wrapper such as **RevenueCat** handles both behind one SDK. Its pricing page says "Pay nothing for up to $2,500 in monthly tracked revenue", then "pay 1% of what you track" ([RevenueCat pricing](https://www.revenuecat.com/pricing)).

Our read: for a solo developer with subscriptions on both platforms, a wrapper saves real time, and the free threshold means it costs nothing until the app is earning. If you only sell one non-consumable unlock on one platform, the native API may be simple enough on its own.

### What the stores take

- **Apple:** the App Store Small Business Program "features a reduced commission rate of 15% on paid apps and Apple In-App Purchases" for developers who earned "no more than 1 million USD in total proceeds" in the previous calendar year and the current year ([Apple Small Business Program](https://developer.apple.com/app-store/small-business-program/)). Read that page for how to join before your first sale.
- **Google Play:** fees now depend on where your users are. For transactions with users in Australia, the EEA, Japan, the UK or the US (rolled out on June 30, 2026 for the EEA, UK and US, and September 30, 2026 for Australia and Japan), Google's table lists "10% + 5% billing fee" for auto-renewing subscriptions, new and existing installs alike, and "10% + 5% billing fee" in its "First $1M (USD) of annual earnings" row. The standard rate for other transactions from new installs is "20% + 5% billing fee". For all remaining markets, Google lists "15% for the first $1M (USD) revenue earned by the developer each year" and "15% for automatically renewing subscription products purchased by subscribers" ([Google Play service fees](https://support.google.com/googleplay/android-developer/answer/112622)). Read that page for which row applies to you and for programs that lower these rates.

**Worked example (ours, illustrative, before taxes):** a 4.99 USD monthly subscription. Through Apple with Small Business Program enrolment, a 15% commission leaves about 4.24 USD. Through Google Play to a US user, 10% plus a 5% billing fee is also 15% in total, leaving about 4.24 USD. If a one-time 4.99 USD unlock fell under Play's standard 20% plus 5% rate for new installs, it would leave about 3.74 USD, so check which row of Google's table covers your earnings before you choose between a subscription and a one-time price. Our guide on [how to monetize a mobile app](https://zeroraised.com/blog/how-to-monetize-a-mobile-app) covers which business models suit which apps.

## Step 7: Analytics and crash reporting

You cannot watch over a user's shoulder, so you need two things from day one: crashes and a handful of events.

**Crash reporting.**

- **Firebase Crashlytics:** the Firebase pricing table lists Crashlytics for mobile apps as "No-cost" on both the Spark and Blaze plans ([Firebase pricing](https://firebase.google.com/pricing)).
- **Sentry:** the free Developer plan lists "5k errors", "1 User" and "50 replays"; the Team plan is "$29/mo monthly, $26/mo annual" with unlimited users ([Sentry pricing](https://sentry.io/pricing/)). Check Sentry's docs for an SDK that matches your framework before you choose it.

Our read: use Crashlytics if you are already on Firebase and want no-cost mobile crash reports. Use Sentry if you want one tool across your app and your backend. Either way, upload source maps or debug symbols in your build step, or your stack traces will be unreadable.

**Product analytics.** Track five or six events, not every tap: install or first open, sign-up completed, core action completed for the first time, paywall viewed, purchase, and a return visit on day 7. Those answer the only questions that matter early: do people get to the core job, and do they come back?

**Push notifications** are a separate decision with their own costs and limits. For a first version, it is fine to add push after launch, once you know which reminder actually brings people back.

## Step 8: Privacy labels and the Data safety form

Both stores make you declare what data the app collects, including what your SDKs collect.

- **Apple:** "You'll need to provide information about your app's privacy practices, including the practices of third-party partners whose code you integrate into your app, in App Store Connect. This information is required to submit new apps and app updates to the App Store" ([Apple app privacy details](https://developer.apple.com/app-store/app-privacy-details/)).
- **Google:** "All developers that have an app published on Google Play must complete the Data safety form", including apps on closed, open or production testing tracks ([Google Play Data safety](https://support.google.com/googleplay/android-developer/answer/10787469)).

Our read: keep a single document, updated every time you add a dependency, listing each SDK (auth, database, analytics, crash reporting, purchases, ads), what data it collects, whether it is linked to the user and whether it is used for tracking. Filling in both forms then takes an hour instead of a day. Fewer SDKs means shorter forms and fewer surprises, which is one more reason to keep the stack small.

## Step 9: Test on real devices

Simulators and emulators are fine for layout. They are not fine for purchases, push, camera, performance on an old phone or what happens when the network drops.

**iOS.** Before you enrol, a Personal Team in Xcode can install on up to 3 devices that expire after 7 days ([Apple compare memberships](https://developer.apple.com/support/compare-memberships/)). After you enrol, TestFlight lets you "Designate up to 100 members of your development team" as internal testers and "invite up to 10,000 external testers" ([Apple TestFlight](https://developer.apple.com/testflight/)).

**Android.** This is the one to put in your calendar. Google's help page says developers with "personal accounts created after November 13, 2023" "must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days" ([Google Play testing requirements](https://support.google.com/googleplay/android-developer/answer/14151465)). Testers who opt out and back in do not count. Recruit those 12 people before you need them: friends, a small waitlist, a community you are part of. Our [Google Play publishing guide](https://zeroraised.com/blog/how-to-publish-an-app-on-google-play) walks through the closed test and the production application step by step.

**A minimal device matrix (ours):**

| Device | Why |
|---|---|
| Your own current phone | Day-to-day testing |
| An older or cheap Android phone | Performance and screen-size reality check |
| An iPhone (if your own phone is Android) | Required for iOS if you have no Mac, and for TestFlight |
| One small-screen device or simulator | Layouts break on small screens first |

Before each release, run one scripted pass on real hardware: fresh install, sign up, core action, purchase with a sandbox account, background and reopen, airplane mode, delete account.

## Step 10: Builds, CI and signing

Signing certificates, provisioning profiles and keystores are where solo developers lose whole weekends. A managed build service handles most of it.

**Expo plans (checked today, [Expo pricing](https://expo.dev/pricing)):**

| Plan | Price | Builds | Expo Update |
|---|---|---|---|
| Free | $0/month | "Up to 15 Android and 15 iOS builds", low queue priority, "45-minute build timeout" | 1,000 MAUs |
| Starter | $19/month plus usage | "$45 of build credit, then usage-based pricing" | "3,000 MAUs, then usage-based pricing" |
| Production | $199/month plus usage | "$225 of build credit, then usage-based pricing" | "50,000 MAUs, then usage-based pricing" |
| Enterprise | Custom | "Starting at $1,000 and customizable" | Preferred pricing |

**Alternatives:** Codemagic's free personal plan has 500 macOS M2 minutes a month and a 120-minute build limit ([Codemagic pricing](https://codemagic.io/pricing/)); Bitrise's free Hobby plan has 500 build minutes a month, 1 private app and a 90-minute timeout ([Bitrise pricing](https://bitrise.io/pricing)). You can also build locally if you have a Mac, which costs nothing per build.

Our read: on the Free plan, a build is a scarce resource, so do not burn one per commit. Develop against a development build and only produce store builds for real TestFlight or closed-test releases. When release week comes and you need faster queues, a month or two of Starter is a small, temporary cost.

Back up your Android upload key and your Apple credentials somewhere safe outside your laptop. Losing signing material is one of the few mistakes that can lock you out of updating your own app.

## Step 11: Over-the-air updates, and their limits

If you use Expo, Expo Update lets your app "update its own non-native pieces (such as JS, styling, and images) over-the-air" ([Expo Update introduction](https://docs.expo.dev/eas-update/introduction/)). It cannot ship a change to native code or native dependencies, a change to app permissions, or a new Expo SDK version; those need a new store build.

Expo is clear that it does not change the store rules: on publishing updates, "you need to follow the rules of the platforms and app stores you are building for" ([Expo Update introduction](https://docs.expo.dev/eas-update/introduction/)). The Apple rule to read is Guideline 2.5.2, which says apps may not "download, install, or execute code which introduces or changes features or functionality of the app, including other apps" ([App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)).

Our read: use OTA updates for bug fixes, copy and small UI changes. Ship new features through a normal store build and review. That keeps you on the safe side of the rules and keeps your release history readable.

## The 12-week solo plan

This is our plan, not a promise. It assumes a tightly scoped first version, consistent weekly hours, and that you already know the language of your chosen framework. If you are learning the language too, add several weeks at the front.

| Week | Focus | Done when |
|---|---|---|
| 1 | One-sentence scope, screen list, framework choice; open Google Play and (if ready) Apple accounts | Screen list fits on one page; accounts submitted |
| 2 | Project setup, navigation, design basics, first development build on a real phone | App runs on your own device |
| 3 | Backend project, auth (email plus Sign in with Apple if you offer social login), user table | You can sign up, sign in and sign out |
| 4 | Core screen, part 1: the one job the app exists for | Core action works end to end with real data |
| 5 | Core screen, part 2: edge cases, empty states, offline behaviour | Airplane mode does not crash or lose data |
| 6 | Settings, account deletion (in-app plus web page), crash reporting, five analytics events | Delete account removes the user and their data |
| 7 | Paywall and purchases (StoreKit and Play Billing, or RevenueCat), sandbox testing | A sandbox purchase unlocks the feature on both platforms |
| 8 | First closed-test build on Play; recruit 12 testers; start the 14-day clock | 12 testers opted in |
| 9 | TestFlight build to a few iOS testers; fix the first round of feedback | Top three issues fixed |
| 10 | Polish: onboarding, store screenshots, privacy forms, Data safety, privacy policy page | Both privacy declarations drafted from your SDK list |
| 11 | Store listing copy, final device pass, production build; submit to App Review and apply for Play production | Both submissions in |
| 12 | Handle review feedback, set release date, prepare launch | Approved on both stores, release scheduled |

Our read: the Play closed test is the critical path for Android. Start it in week 8 at the latest, or your Android launch will slip behind iOS by two weeks or more.

## What it costs in year one

Our arithmetic from the prices verified above, in USD, excluding taxes, hardware and your time. "Comfortable" uses entry prices; usage above the included amounts costs extra.

| Item | Minimal stack | Comfortable stack |
|---|---|---|
| Apple Developer Program | $99 | $99 |
| Google Play registration (one-time) | $25 | $25 |
| Builds | Expo Free: $0 | Expo Starter: $19 x 12 = $228 |
| Backend | Supabase Free or Firebase Spark: $0 | Supabase Pro from $25 x 12 = $300 |
| Crash reporting | Crashlytics: $0 | Sentry Team annual $26 x 12 = $312 |
| Purchases | RevenueCat: $0 under $2,500 MTR | RevenueCat: $0 under $2,500 MTR |
| **Total** | **$124** | **from $964** |

On top of either column you need at least one real test device you may already own, a domain or simple web page for your privacy policy and account deletion link, and the store commissions once you sell. Our read: start on the minimal column. Every paid line on the right is something you can switch on in an afternoon once the app has users who need it. The Supabase Free project pause after a week of inactivity is the first limit most people hit, usually after launch when it starts to matter.

## Common mistakes solo developers make

1. **Building for three platforms at once.** iOS, Android and a web dashboard in version 1 is a team's roadmap. Ship the phone app first; a web dashboard can wait.
2. **Changing frameworks mid-build.** The second framework never looks as good once you hit its rough edges too.
3. **Adding social login without an equivalent option.** Guideline 4.8 is written down in plain language, so a rejection under it is avoidable. Plan the login screen around it.
4. **Forgetting account deletion.** Both stores require it if you have accounts. Build it with sign-up, not after a rejection.
5. **Starting the Play closed test too late.** Fourteen consecutive days with 12 opted-in testers is a fixed clock. Recruit early.
6. **Writing your own subscription logic.** Receipt validation, renewals, grace periods and refunds are a project in themselves. Use a wrapper or follow the store docs exactly.
7. **No crash reporting at launch.** The first week of real users is when you learn the most. Without crash reports you learn it from one-star reviews.
8. **Losing signing keys.** Back them up the day you create them.
9. **Too many SDKs.** Each one adds app size, privacy declarations and something else to update. Add a dependency only when it removes real work.
10. **Treating approval as launch.** Approval is a private event. Pick the release date yourself, and plan the launch separately.

## The solo mobile app build checklist

Before you write code:

- [ ] One-sentence scope and a screen list of five to eight screens
- [ ] Format decided: web/PWA, cross-platform or native
- [ ] Framework chosen, and no more framework research
- [ ] Google Play account opened; Apple account opened or scheduled

During the build:

- [ ] Running on a real phone from week 2
- [ ] Auth with an equivalent private login option if you offer social sign-in (Guideline 4.8)
- [ ] In-app account deletion plus a web deletion link
- [ ] Crash reporting and five or six analytics events
- [ ] Purchases tested in sandbox on both platforms
- [ ] An SDK list with the data each one collects
- [ ] Signing keys and credentials backed up

Before submission:

- [ ] Play closed test with 12 testers for 14 consecutive days (new personal accounts)
- [ ] TestFlight build tested by at least a few people
- [ ] App privacy details in App Store Connect and the Play Data safety form completed
- [ ] Built with Xcode 26 or later on an iOS 26 SDK (cloud builders handle this if their images are current)
- [ ] Small Business Program enrolment if you sell on iOS
- [ ] Release set to manual or a chosen date

Once both builds are approved, work through our [product launch checklist for bootstrapped makers](https://zeroraised.com/blog/product-launch-checklist-for-bootstrapped-makers) for launch day itself.

## Frequently asked questions

### Can one person really build and ship a mobile app?

Yes. The tooling now covers the parts that used to need a team: cross-platform frameworks such as React Native with Expo or Flutter give you iOS and Android from one codebase, backend-as-a-service tools handle auth and data on free tiers, RevenueCat or the store SDKs handle purchases, and cloud build services compile and submit for you. What one person cannot do is build a big app. Scope to one core job, one platform-specific risk at a time, and plan around 12 weeks for a first version.

### Do I need a Mac to build an iOS app?

Not strictly. Apple's tools, Xcode and the iOS Simulator, run on a Mac, but Expo's FAQ says you can use Expo Build to build your app in the cloud, and its submit docs say Expo Submit works on macOS, Linux and Windows. Codemagic and Bitrise also offer cloud macOS build minutes on free tiers. Without a Mac you have no Simulator, so you need a real iPhone to test, and fixing native build problems is harder.

### How much does it cost to build a mobile app on your own?

The unavoidable costs are the Apple Developer Program at 99 USD per membership year and Google Play's US$25 one-time registration fee. On free tiers for builds (Expo Free), backend (Supabase or Firebase), crash reporting (Crashlytics or Sentry's free plan) and purchases (RevenueCat, free up to $2,500 in monthly tracked revenue), year one can cost about $124 plus a test device. A more comfortable paid stack in our example costs from about $964 a year.

### Should a solo developer use React Native or Flutter?

Our read: pick the one that matches the language you already know. If you write JavaScript or TypeScript for the web, React Native with Expo lets you reuse that skill, and React Native's own docs recommend a framework like Expo for new apps. If you prefer a single toolkit that draws its own UI and you are happy to learn Dart, Flutter is a strong choice. Both ship to iOS and Android from one codebase; the cost of switching later is far higher than the difference between them.

### How long does it take to build a mobile app alone?

There is no fixed answer, and we have not seen reliable data for solo developers. Our 12-week plan assumes a tightly scoped first version, part-time to full-time effort, and a developer who already knows the chosen language. Budget extra time for things outside your control: Google Play's 14-day closed test for new personal accounts and App Review, which can mean at least one rejection round.

## Ship it, then launch it

ZeroRaised is a launch directory for products built without institutional VC. When your app is live in both stores, [submit it to ZeroRaised](https://zeroraised.com/submit) for free and put it in front of people who back bootstrapped makers. For more build and launch guides for solo founders, [join the ZeroRaised newsletter](https://zeroraised.com/newsletter).

## Sources

All sources last checked 10 Nov 2026.

- [Apple Developer Program](https://developer.apple.com/programs/), last checked 10 Nov 2026
- [Apple Developer Program enrollment](https://developer.apple.com/support/enrollment/), last checked 10 Nov 2026
- [Apple Developer Program fee waivers](https://developer.apple.com/help/account/membership/fee-waivers/), last checked 10 Nov 2026
- [Apple compare memberships](https://developer.apple.com/support/compare-memberships/), last checked 10 Nov 2026
- [App Store Small Business Program](https://developer.apple.com/app-store/small-business-program/), last checked 10 Nov 2026
- [App Review Guidelines (2.5.2, 4.8, 5.1.1(v))](https://developer.apple.com/app-store/review/guidelines/), last checked 10 Nov 2026
- [Apple Xcode](https://developer.apple.com/xcode/), last checked 10 Nov 2026
- [Apple upcoming requirements](https://developer.apple.com/news/upcoming-requirements/), last checked 10 Nov 2026
- [Apple app privacy details](https://developer.apple.com/app-store/app-privacy-details/), last checked 10 Nov 2026
- [Apple TestFlight](https://developer.apple.com/testflight/), last checked 10 Nov 2026
- [Apple StoreKit](https://developer.apple.com/storekit/), last checked 10 Nov 2026
- [Google Play Console registration](https://support.google.com/googleplay/android-developer/answer/6112435), last checked 10 Nov 2026
- [Google Play service fees](https://support.google.com/googleplay/android-developer/answer/112622), last checked 10 Nov 2026
- [Google Play testing requirements for new personal accounts](https://support.google.com/googleplay/android-developer/answer/14151465), last checked 10 Nov 2026
- [Google Play Data safety](https://support.google.com/googleplay/android-developer/answer/10787469), last checked 10 Nov 2026
- [Google Play account deletion requirements](https://support.google.com/googleplay/android-developer/answer/13327111), last checked 10 Nov 2026
- [Google Play Payments policy](https://support.google.com/googleplay/android-developer/answer/9858738), last checked 10 Nov 2026
- [Google Play Billing](https://developer.android.com/google/play/billing), last checked 10 Nov 2026
- [React Native](https://reactnative.dev/), last checked 10 Nov 2026
- [React Native environment setup](https://reactnative.dev/docs/environment-setup), last checked 10 Nov 2026
- [React Native blog](https://reactnative.dev/blog), last checked 10 Nov 2026
- [Expo pricing](https://expo.dev/pricing), last checked 10 Nov 2026
- [Expo SDK versions](https://docs.expo.dev/versions/latest/), last checked 10 Nov 2026
- [Expo FAQ](https://docs.expo.dev/faq/), last checked 10 Nov 2026
- [Expo Build introduction](https://docs.expo.dev/build/introduction/), last checked 10 Nov 2026
- [Expo Submit for iOS](https://docs.expo.dev/submit/ios/), last checked 10 Nov 2026
- [Expo environment setup](https://docs.expo.dev/get-started/set-up-your-environment/), last checked 10 Nov 2026
- [Expo tutorial: iOS development build for devices](https://docs.expo.dev/tutorial/eas/ios-development-build-for-devices/), last checked 10 Nov 2026
- [Expo Update introduction](https://docs.expo.dev/eas-update/introduction/), last checked 10 Nov 2026
- [Flutter what's new](https://docs.flutter.dev/release/whats-new), last checked 10 Nov 2026
- [Flutter install](https://docs.flutter.dev/get-started/install), last checked 10 Nov 2026
- [Kotlin Multiplatform](https://kotlinlang.org/multiplatform/), last checked 10 Nov 2026
- [Codemagic pricing](https://codemagic.io/pricing/), last checked 10 Nov 2026
- [Bitrise pricing](https://bitrise.io/pricing), last checked 10 Nov 2026
- [RevenueCat pricing](https://www.revenuecat.com/pricing), last checked 10 Nov 2026
- [Supabase pricing](https://supabase.com/pricing), last checked 10 Nov 2026
- [Firebase pricing](https://firebase.google.com/pricing), last checked 10 Nov 2026
- [Sentry pricing](https://sentry.io/pricing/), last checked 10 Nov 2026

## Frequently asked questions

### Can one person really build and ship a mobile app?

Yes. The tooling now covers the parts that used to need a team: cross-platform frameworks such as React Native with Expo or Flutter give you iOS and Android from one codebase, backend-as-a-service tools handle auth and data on free tiers, RevenueCat or the store SDKs handle purchases, and cloud build services compile and submit for you. What one person cannot do is build a big app. Scope to one core job, one platform-specific risk at a time, and plan around 12 weeks for a first version.

### Do I need a Mac to build an iOS app?

Not strictly. Apple's tools, Xcode and the iOS Simulator, run on a Mac, but Expo's FAQ says you can use Expo Build to build your app in the cloud, and its submit docs say Expo Submit works on macOS, Linux and Windows. Codemagic and Bitrise also offer cloud macOS build minutes on free tiers. Without a Mac you have no Simulator, so you need a real iPhone to test, and fixing native build problems is harder.

### How much does it cost to build a mobile app on your own?

The unavoidable costs are the Apple Developer Program at 99 USD per membership year and Google Play's US$25 one-time registration fee. On free tiers for builds (Expo Free), backend (Supabase or Firebase), crash reporting (Crashlytics or Sentry's free plan) and purchases (RevenueCat, free up to $2,500 in monthly tracked revenue), year one can cost about $124 plus a test device. A more comfortable paid stack in our example costs from about $964 a year.

### Should a solo developer use React Native or Flutter?

Our read: pick the one that matches the language you already know. If you write JavaScript or TypeScript for the web, React Native with Expo lets you reuse that skill, and React Native's own docs recommend a framework like Expo for new apps. If you prefer a single toolkit that draws its own UI and you are happy to learn Dart, Flutter is a strong choice. Both ship to iOS and Android from one codebase; the cost of switching later is far higher than the difference between them.

### How long does it take to build a mobile app alone?

There is no fixed answer, and we have not seen reliable data for solo developers. Our 12-week plan assumes a tightly scoped first version, part-time to full-time effort, and a developer who already knows the chosen language. Budget extra time for things outside your control: Google Play's 14-day closed test for new personal accounts and App Review, which can mean at least one rejection round.