You have a working idea for a mobile app. You also have no team and limited time or budget. The architecture you pick on day one determines how fast you ship and whether maintenance leaves room to pivot when real users show up with real feedback.
Six paths to a shipped app
Every mobile architecture option falls along a spectrum from maximum control to maximum speed.
Native: SwiftUI and Jetpack Compose
Platform-specific development gives you direct hardware access and pixel-perfect platform feel. Jetpack Compose is Google's recommended modern toolkit for Android. Apple's SwiftUI is the equivalent for iOS.
Targeting both platforms means maintaining two codebases across separate toolchains and submission workflows. A developer in the linked discussion reported that shipping dual-platform natively takes close to a year for a single person, and that every feature ships slower afterward.
iOS-only is a different story. Native iOS development with AI tools can be fast and manageable for one person.
Cross-platform: Flutter
Flutter trades native UI components for one codebase that reaches multiple platforms. Google's UI toolkit uses Dart and compiles to native machine code.
A developer in the linked discussion described Flutter as having "the best dev experience" out of all platforms, including native. The trade-off is learning Dart, which JavaScript developers often find unfamiliar. Flutter renders its own widget set, and on iOS, Flutter apps may not feel native to platform users.
Cross-platform: React Native with Expo
React Native with Expo is often the shortest path for solo developers who already know React. Meta's framework uses JavaScript and TypeScript. Unlike Flutter, React Native renders actual native UI components on each platform.
The New Architecture replaced the old JavaScript bridge with direct method invocation. For developers already comfortable with React, the learning curve is minimal. Expo's managed workflow handles most build configuration automatically.
Hybrid: Ionic with Capacitor
Ionic with Capacitor works best when you already have web skills and need app store presence quickly. Capacitor wraps web applications in a native container with access to device APIs. Ionic provides adaptive components that match each platform's design language.
Performance runs through a WebView, which tends to feel less smooth than Flutter, React Native, or fully native approaches. A developer in the linked discussion switched from Capacitor to Expo after encountering iOS keyboard and scrolling issues.
Progressive web apps
PWAs remove app store overhead and let you test demand fast. PWAs use service workers and browser APIs to deliver app-like experiences without an app store. You skip review queues and avoid commission fees. Updates deploy instantly.
AI app builders
AI app builders can speed up validation for solo developers. Code ownership matters. If you outgrow FlutterFlow, you keep your codebase. If you outgrow some app builders, you may need to start over.
How solo developers actually choose a framework
Framework choice should follow existing skills before benchmark charts. The wrong choice slows you down before users ever see the product.
Match your existing skills
A developer already fluent in React and JavaScript should start with React Native and Expo. One builder's explicit reasoning: "React for Web, with Remix… React Native for Mobile. Node.js and Typescript for the Backend". Stack consistency eliminates the need to learn Dart.
For maximum platform coverage from a single codebase, Flutter can fit apps that need broad platform reach. A solo founder who built an iOS MVP in Swift then faced the cross-platform question. Another builder later switched frameworks as the app scaled.
If you plan to charge money and only need iOS, native SwiftUI is a legitimate strategy. Apple charges $99 per year for the Developer Program.
AI tooling tilts the balance
AI coding tools do not produce equal output across all frameworks. Tools trained heavily on JavaScript and TypeScript may generate better results for React Native than for Dart. Flutter's team argues that a single Dart codebase reduces AI token overhead compared to maintaining separate native codebases. Both points are valid. If you plan to lean hard on AI assistance, test your chosen framework with your preferred AI tool before committing to a workflow that fights your tools.
Backend decisions that protect your future self
Backend structure usually determines maintenance pain more than frontend choice. A clean backend setup reduces migration pain and limits future rework.
Pick your BaaS by data model
For solo developers, the choice is almost always a backend-as-a-service. The right option depends on your data model, which affects query complexity and how painful a migration becomes if your app changes shape later.
- Document-oriented data: Firebase and Firestore work well. Firestore does not support SQL joins across collections, so relational queries become painful as complexity grows.
- Relational data: Supabase runs on PostgreSQL with standard SQL. It also includes row-level security and real-time subscriptions. Its pricing page shows a free tier supports up to 50,000 monthly active users, and a Pro plan costs $25 per month for up to 100,000.
- Self-hosting available: Supabase documents self-hosting with Docker as the recommended path.
Use your data shape to choose the service. That decision tends to matter more later than small differences in setup speed.
Isolate your backend calls
If you expect your app to change backends later, isolate backend calls from the start. The Android data layer guide recommends placing all backend SDK calls inside Repository and data source classes. Do not scatter them through UI code or ViewModels.
This keeps a backend migration, such as moving from Firebase to Supabase, scoped to a handful of files instead of touching your entire codebase. Migrating without this isolation can become a substantial undertaking. A single, well-structured monolith can remain maintainable for many years.
Where AI tools fit your architecture workflow
AI tools speed up development, but technical judgment still determines how much cleanup and debugging you inherit later.
Prompt-to-app platforms versus AI coding assistants
Prompt-driven app builders and AI coding assistants solve different problems. AI app builders generate functional, deployed applications from natural language descriptions. AI coding assistants like Cursor and Claude Code assume you can read and debug code.
One builder documented building MemoBloom with React Native and AI coding assistance. The app uses an AI pipeline for its functionality. AI tools lowered the skill floor, but the output is a traditional, exportable codebase. After shipping, distribution became the hard problem.
Moving a project generated in app-building tools into Cursor can create friction because the AI assistant may need additional codebase context. Developers use different workflows when moving from AI app builders to code-first tools.
AI changes the pace of development. Technical judgment still determines how much code you can own and debug.
App store rules that constrain your architecture
Store rules can override technical convenience, and review policies matter most when your stack leans on web wrappers or third-party SDKs.
Apple's Rule 4.2 says apps should provide more than a website wrapped in an app. A WebView that reproduces your website without native features like push notifications or offline capability carries rejection risk. This applies regardless of framework. A Flutter app can fail this test as easily as a Capacitor app.
Google's User Data Policy makes developers responsible for every SDK bundled in their app. Cross-platform frameworks include third-party SDKs for analytics and crash reporting. They may also include advertising SDKs that you did not explicitly select. An incomplete or inaccurate Data Safety form can lead Google to require changes before approval or reject the app listing. Audit every SDK in your generated build before submission.
Apple's Rule 2.5.2 prohibits apps from downloading code that changes features at runtime. The written guidelines do not carve out an explicit exception for over-the-air JavaScript updates for React Native, even though those updates have been tolerated in practice.
What the real costs look like
Solo builders need cost structures they can carry before revenue shows up. Store fees apply to every approach. Apple charges $99 per year. Google charges a $25 one-time fee.
Code-based frameworks add no mandatory framework subscription. Your baseline spend comes from store fees plus your time.
Visual builders add subscription fees on top of store costs:
- Adalo Starter: $36 per month, all-in with a built-in database.
- FlutterFlow: A paid visual builder, with database costs separate depending on your backend setup.
- Bubble Starter: Starts around $29–$36 per month, with workload-based pricing that can increase costs as usage grows.
Subscriptions can become a meaningful part of year-one cost before you earn anything back.
Pick your architecture and start building
For solo app developers, speed to a working product usually matters more than architectural purity. Building has become faster, while distribution is often a major bottleneck. Code has become easier to produce with AI assistance. Getting users is the harder constraint.
Use this as your starting filter:
- Know JavaScript or React? Start with React Native and Expo.
- Want iOS, Android, web, and desktop from one codebase? Pick Flutter.
- iOS-only, planning to charge money? Native SwiftUI.
- Web developer who needs app store presence this week? Ionic with Capacitor or a PWA.
- Non-technical, validating an idea? FlutterFlow for the code export safety net.
These filters work best when you keep the first version small. Whichever path you choose, isolate your backend calls in a data layer and pick a BaaS that matches your data model. Ship the smallest version that solves a real problem. Get started with something you can ship this month.
