You have an app idea, but limited time. Existing product work competes with mobile build work, and each app store expects a polished product.
Building separate versions for iOS and Android can duplicate product work before anyone pays. A shared codebase only pays off when you pair it with the right architecture decisions and a real plan for distribution.
Start with the category before copying examples
Choose the kind of app you need based on how you will distribute, update, and validate the product. Each category creates a different constraint before you write much code.
- Native apps: Teams build native apps for a single platform with platform-specific tools. For iOS, that means Swift, and distribution requires the Apple Developer Program.
- Webview hybrid apps: Cross-platform is the broader category. Webview hybrid apps are one branch: teams ship native applications with a web browser embedded inside them, still distributed through native stores.
- Progressive web apps: Progressive web apps run in the browser and use service workers. These JavaScript assets are proxies between browser and server to support offline functionality.
Distribution and update speed drive most of the trade-offs between these categories.
- Single codebase: Hybrid apps can use one codebase across platforms; PWAs can also reach devices from a single codebase. Native requires separate platform work.
- App store presence: Native and hybrid both ship through stores. PWAs install from the web by default, with optional store submission.
- Update speed: Native and hybrid follow the same App Store review path. Web-only PWA updates can skip store packaging.
Why iPhone changes the PWA math
PWAs can reduce duplicate platform work. On iOS, that benefit can break down when the product needs user installation flows or features that depend on what the browser and platform support.
If your business depends on app-store presence, native app expectations, or features outside current browser support, a store-distributed app often fits better on iPhone. Decide on distribution before you decide on a framework.
What production cross-platform apps show
Flutter powers a long list of production apps. The team behind eBay Motors chose Flutter because native builds took longer to reflect in the emulator, so iteration ran faster.
The STAGE streaming app switched after trying to build for each platform in parallel. Hot reload and customizable widgets became deciding factors.
Production Flutter apps also include BMW and Alibaba; Google Pay appears there too. For indie builders, the practical lesson is about iteration speed.
React Native has a similar roster. Amazon uses React Native across Shopping and Alexa. Photos and Kindle appear on the same React Native page. Shopify and Shop appear there too.
Bluesky takes the indie-friendly route: a builder thread notes it uses Expo on React Native, with React Native for Web handling desktop. The clients are open source, which keeps mobile and web work closer together while the product keeps changing.
Why webview hybrid still matters for web builders
Webview hybrid tools can make more sense when your strongest skill set already sits in web development.
Capacitor and Ionic are closest to web developers. Burger King used Ionic Capacitor to bring a design system to mobile across platforms.
For a web developer, that path means shipping to the stores without learning Dart or React Native quirks. A practical rule for solo builders is to reduce the number of new concepts between the idea and the first usable version.
What solo builders should copy from the stack pattern
A shared codebase can help when it removes duplicated product work without hiding the distribution constraints.
Umberto Mezzadra built Floga, a mindfulness app, on Flutter for one codebase across platforms. He chose shared product work over parallel platform work, and that is the pattern to copy: pick the stack that lets you test the product without maintaining separate builds too early.
How to choose your first build path
Before you commit to a mobile stack, check these decisions.
- Choose store or web distribution first. Use a store-distributed app when store presence matters. Use a PWA when web installation fits the product. This choice prevents wasted framework work.
- Pick a framework that matches your current skills. Lower learning load shortens the path to validation.
- Flutter suits builders willing to learn Dart.
- React Native suits builders near React.
- Ionic and Capacitor suit web developers.
- Validate device features and store policy early. Review rules before building features that depend on native behavior. That check reduces rework and lowers the risk of a blocked release.
- Ship the smallest version someone can pay for.
Start with distribution, match the stack to your skills, and validate the smallest paid version before optimizing the architecture. If your first mobile target is iOS, we can help you refine the app through conversation, add Stripe payments, and host without setup.
When you are ready for store submission, you can deploy through Expo. For a builder example, read how Dirk stopped waiting.
