How to Build a Mobile App as a Solo Developer

Step-by-step guide to building a mobile app by yourself. Tech stack, timeline, costs, and practical advice.

What You're Building

A mobile app that runs natively on iOS and Android. This is one of the hardest things a solo developer can take on, but also one of the most rewarding. Mobile apps have built-in distribution through app stores, push notifications to re-engage users, and people are willing to pay for apps in ways they're not willing to pay for websites.

I shipped my first mobile app after about four months of evening and weekend work. It was a simple utility app, nothing fancy. But seeing it in the App Store with real reviews from strangers was genuinely one of the best moments of my developer career. Fair warning though, it was also one of the most frustrating projects I've ever worked on.

Difficulty & Timeline

Aspect	Detail
Difficulty	Hard
Time to MVP	3-6 months
Ongoing Maintenance	High
Monetization	Freemium, subscriptions, one-time purchase, ads

Recommended Tech Stack

Here's my strong opinion on this. Unless you have a very specific reason to go native (like AR, heavy animations, or hardware integrations), use React Native with Expo. It's the best solo developer experience available for cross-platform mobile development in 2026. As of late May 2026 the current releases are React Native 0.85.3 and Expo SDK 56 (the expo package sits at 56.0.8 on npm), and both are heavily battle tested. React Native pulls roughly 8.9 million npm downloads a week and the facebook/react-native repo carries about 125,900 GitHub stars, so you are never the first person to hit a given bug.

Flutter is the other serious option, and it is even more popular on GitHub at around 176,500 stars, but Dart is a language you'll only use for Flutter. React Native lets you leverage your existing JavaScript/TypeScript knowledge and share logic with a web app if you ever build one.

For the backend, use Supabase. It gives you a database, authentication, storage, and real-time subscriptions out of the box. Its @supabase/supabase-js client is at 2.106.2 and is one of the most depended-on packages in this whole stack, with close to 19.8 million npm downloads a week, and the main supabase/supabase repo sits at about 103,200 GitHub stars. Pair it with Expo's EAS Build service for compiling and submitting to app stores without needing a Mac (well, you still need one for testing, but not for building). The EAS Free plan gives you 15 Android and 15 iOS builds per month, which is plenty for a solo project early on, and the Starter plan is $19/month if you outgrow it.

Step-by-Step Plan

Phase 1: Foundation (Month 1)

Install Expo, create your project, and get it running on your physical phone immediately. Not the simulator. Your actual phone. This matters because the simulator lies to you about performance, touch interactions, and screen sizes. The current scaffolding command pins the SDK explicitly, which saves you from version drift later:

npx create-expo-app@latest my-app --template default@sdk-56

Build your navigation structure first using Expo Router (currently 56.2.8, matching the SDK). This is the skeleton of your app. Define all your screens, set up tab navigation or stack navigation, and get the basic flow working. Every screen can just be a text component that says "TODO" at this point.

Set up Supabase, create your database schema, and implement authentication. Email/password plus Google and Apple sign-in. Apple requires Apple Sign-In if you offer any other social login, so don't skip it.

I made the mistake of leaving auth until month three on my first app. Retrofitting authentication into an existing app is painful. Do it first.

Phase 2: Core Features (Month 2-3)

Build the one thing that makes your app worth downloading. Not the settings screen, not the profile page, not the onboarding flow. The core feature. If your app is a habit tracker, build the habit tracking. If it's a photo editor, build the editing tools.

Use React Native's built-in components where possible, and reach for a UI library like Tamagui (currently 2.0.0, about 14,000 GitHub stars) or NativeWind (Tailwind for React Native, currently 4.2.4, roughly 7,900 stars and about 1.17 million npm downloads a week) for styling. NativeWind is the more popular of the two by download volume, so if you already know Tailwind it is the path of least resistance. Avoid heavy animation libraries until you actually need them.

Test on both iOS and Android throughout this phase. I cannot emphasize this enough. Fixing platform-specific bugs at the end is ten times harder than catching them as you go. The most common issues are keyboard handling, safe area insets, and permission dialogs behaving differently between platforms.

Phase 3: Polish & Launch (Month 4-5)

This phase takes longer than you think. App Store review can reject your app for surprisingly minor things. I got rejected once because my screenshot showed a status bar that didn't match the device frame. Another time because my privacy policy link was broken.

Create an App Store listing with good screenshots (use a tool like Screenshots.pro or Fastlane's snapshot), a clear description, and proper keywords. Apple's keyword field is 100 characters, and every character matters for ASO (App Store Optimization).

Set up push notifications with Expo Notifications (the expo-notifications package is at 56.0.15, matching the SDK). This is your biggest retention tool. A well-timed push notification can bring users back better than any email campaign. One thing the docs are explicit about, push notifications do not work in Expo Go anymore, so you have to create a development build to test them, and you need a physical device or a supported emulator.

Building and submitting happens through EAS. The documented flow is to install the CLI, log in, configure once, then build:

npm install -g eas-cli
eas login
eas build:configure
eas build --platform all

Submit to both stores. Apple review takes 1-3 days. Google Play review takes a few hours to a couple of days. Have patience and be ready to fix review feedback quickly. Note that the Apple Developer Program is $99 per year and a Google Play developer account is a one-time $25, both of which you pay before you can ship.

Monetization Strategy

Both stores have a reduced-rate path for small developers, so the headline 30% number is not what most solo apps actually pay. Apple's standard commission is 30%, but its App Store Small Business Program drops that to 15% as long as you earned under $1 million in proceeds in the prior year, which covers basically every app at launch. Google Play works the same way, with 15% on the first $1 million of earnings per year and 30% above that. Factor whichever rate applies to you into your pricing, but plan around 15% if you are just starting out. Note that Google's fee structure is changing as of mid-2026 under the Epic settlement, so check current rates before you finalize pricing.

Subscriptions work best for apps that provide ongoing value. A $4.99/month subscription converts better than a $49.99/year one, even though the annual is cheaper. People are weird about money. Offer both, but default to showing monthly.

For utility apps, a one-time purchase with a premium unlock works great. Charge $4.99-9.99 and give away a useful free tier. Ads are a last resort and honestly aren't worth it until you have at least 50k monthly active users.

One thing that works surprisingly well is offering a free trial of premium features. Seven days is the sweet spot. Apple even lets you offer introductory pricing, and apps that use it convert significantly better than those that don't.

Common Mistakes to Avoid

Going native for both platforms. You're one person. Building and maintaining two completely separate codebases in Swift and Kotlin is a full-time job times two. Use cross-platform tooling unless you have an extremely good reason not to.

Ignoring app size. A 200MB app is a hard sell for casual users. Keep your bundle lean. Lazy-load assets, compress images, and remove unused dependencies.

Skipping the onboarding flow. Users who don't understand your app in the first 30 seconds uninstall it. A three-screen onboarding that shows the core value is not optional. It's essential.

Not planning for offline. Mobile apps should work without internet, or at least degrade gracefully. Use local storage for critical data and sync when the connection comes back. I've seen apps crash on airplane mode because they didn't handle fetch errors. Don't be that developer.

Common Errors and Fixes

These are the failures most likely to stop you mid-build, drawn from the official Expo and store documentation rather than guesswork.

Push notifications return no token in Expo Go. Since Expo SDK 53 the push APIs were removed from Expo Go, and the current docs are explicit that notifications require a development build. If getExpoPushTokenAsync throws or returns nothing, you are almost certainly still running inside Expo Go. Build a development client with eas build --profile development, install that on your device, and test there instead.

Push setup fails on a simulator. The Expo docs require a device or emulator that actually supports push, meaning a physical phone, an Android Emulator with Google Play services, or an iOS Simulator on Xcode 14 or newer. A bare simulator without those will not register a token. Use a physical device when in doubt.

The push token is missing a projectId. The docs call this out as a common oversight. Even though the projectId is set automatically in a development build, Expo recommends reading it from expo-constants and passing it explicitly to getExpoPushTokenAsync so tokens stay stable across account transfers. Add expo-constants alongside expo-notifications and wire the id in by hand.

eas build fails with no configuration. EAS Build needs an eas.json before it will run. The documented order is npm install -g eas-cli, then eas login, then eas build:configure, and only then eas build. Skipping the configure step is the usual cause of a build that errors immediately.

iOS build rejected for missing credentials. Building for the Apple App Store requires an active Apple Developer Program membership, which is the $99 per year account. EAS can generate the provisioning profile and distribution certificate for you, but it cannot create them without that paid membership in place first. Enroll before your first eas build --platform ios.

Android build cannot find a keystore. On the first Android build EAS offers to generate a keystore for you. Let it, and let EAS store it, otherwise you have to manage signing credentials yourself and reuse the exact same keystore for every future update or Google Play will reject the upload.

SDK version drift between Expo and its libraries. Most "it built yesterday and not today" problems come from mismatched versions. Pin to one SDK from the start (the scaffold above pins SDK 56), and when you add Expo libraries let npx expo install pick the version that matches your SDK instead of installing the latest from npm by hand.

Is This Worth Building?

It depends on your idea. Mobile apps are high-effort but also high-reward when they work. The distribution advantage of app stores is real. People discover apps differently than they discover websites, and the willingness to pay is higher.

But here's the honest truth. Most solo developer mobile apps fail not because the code is bad but because marketing a mobile app is brutally hard. App Store SEO matters, reviews matter, and getting those first hundred downloads is a grind. If you're building a mobile app, make sure you have a plan for how people are going to find it. "Build it and they will come" does not apply to the App Store. There are millions of apps there. You need a distribution strategy from day one.

If your app solves a real problem that people already search for, go for it. If it's a "nice to have" that you think would be cool, maybe validate the idea with a landing page and waitlist first. The four months you'd spend building could be saved by a two-week validation experiment.