PWA, Swift and Kotlin, or Expo: Picking a Mobile App Architecture
Compare PWAs, fully native Swift and Kotlin apps, and Expo on codebase, store presence, performance, hardware access, release speed and cost, then choose.
This article is published in English.
Sources: PWA vs Native vs Expo: Pros, Cons, and How to Choose the Right Architecture
The architecture you choose for a mobile product is hard to change later. Pick poorly and the next year goes into fighting the platform instead of shipping features: dependency conflicts after a framework upgrade, a missing hardware API, or two native teams drifting apart. This guide compares the three most common starting points, Progressive Web Apps, fully native apps written in Swift and Kotlin, and Expo on top of React Native, and ends with concrete criteria for choosing between them, whether you are building an MVP or planning the next stage of an existing app.
How the three options compare
Before looking at each option in detail, here is how they differ on the dimensions that usually decide the outcome.
Codebase
- PWA: one web codebase built with HTML, CSS and JavaScript.
- Native: a separate codebase per platform, typically Swift for iOS and Kotlin for Android.
- Expo: a single JavaScript or TypeScript codebase shared by iOS and Android.
App store presence
- PWA: lives on the web. Store listing is optional and relies on wrappers or platform-specific workarounds.
- Native and Expo: distributed directly through the Apple App Store and Google Play.
Performance
- Native: the ceiling. Smooth animation at the display's full refresh rate, up to 120 fps on capable screens, with no abstraction layer in the way.
- Expo: close to native for most interfaces. React Native renders real native views, and its New Architecture replaces the old asynchronous bridge with direct JavaScript-to-native calls through JSI, which removed a long-standing bottleneck.
- PWA: limited by what the browser engine allows, especially for heavy animation and background work.
Hardware access
- Native: everything the platform exposes.
- Expo: broad coverage through the Expo SDK, extended with config plugins and custom native modules when needed.
- PWA: the core set available to the web, such as camera and geolocation, with notable gaps on iOS.
Release speed
- PWA: changes go live as soon as you deploy, with no store review.
- Expo: over-the-air (OTA) updates can ship JavaScript and asset changes instantly, while changes to native code still go through normal store review.
- Native: every release goes through the store review process.
Cost
- PWA: usually the cheapest to build and maintain.
- Expo: a moderate investment with one team.
- Native: the most expensive, because two platform codebases usually mean two specialized teams.
Progressive Web Apps: the web-first route
A PWA is a web application that uses capabilities such as a service worker and a web app manifest to behave more like an installed app: it can be added to the home screen, launch in its own window and keep working offline. If offline behavior is central to your product, the blog's guide to offline support with service workers shows the mechanics.
Strengths. There is no app store standing between you and your users. Anyone with the URL can use the app and add it to their home screen. Updates reach everyone on the next load, and the content is indexable by search engines, which brings organic discovery that store listings rarely match.
Limitations. Apple still restricts PWAs on iOS. Web push is available only for apps added to the home screen, and background execution is tightly limited. Web Bluetooth and similar hardware APIs are not supported in Safari at all. If the product depends on Bluetooth, continuous background tracking or deep device integration, a PWA will run out of road quickly. Platform policies here have changed more than once, so check the current state for your target iOS versions.
Native Swift and Kotlin: maximum control
Going native means building and maintaining two applications: one in Swift for iOS and one in Kotlin for Android.
Strengths. Nothing is abstracted away, so performance and fidelity are as good as the platform allows. New APIs from Apple and Google are available on the day they ship, without waiting for a framework to wrap them. This is the natural choice for demanding graphics, complex AR or VR, and heavy background processing.
Limitations. The overhead is substantial. Two codebases roughly double the development and testing effort and usually require two teams with different skills. Every feature has to be built twice and kept in sync, and every release, including a small bug fix, waits for store review.
Expo: one codebase, native results
Expo is an open-source framework and toolchain built on React Native. It hides much of the native build complexity on iOS and Android, so a single JavaScript or TypeScript codebase can produce real native apps for both platforms.
Strengths. Development moves quickly. Expo Application Services (EAS) builds the native binaries in the cloud, so day-to-day work rarely requires opening Xcode or Android Studio. EAS Update delivers OTA fixes straight to installed apps. Keep in mind that OTA updates can change JavaScript and assets but not native code, and store policies still govern what an update may change; a new native dependency means a new store build.
Limitations. Config plugins and the Expo Modules API have made custom native code far more accessible than it used to be, and development builds let you include any native library, not just what ships in Expo Go. Even so, apps that need very low-level hardware drivers or complex custom C++ still require real native work, and the team needs someone comfortable doing it.
For a wider view of cross-platform options beyond Expo, including Flutter and Kotlin Multiplatform, see the blog's overview of cross-platform mobile frameworks.
Choosing the right architecture
Match the architecture to the product rather than to the team's favorite tool:
- Choose a PWA when the budget is tight, discoverability through search matters, and the product is mostly content or forms: an online shop, a news site or a SaaS dashboard. It is also a sensible way to validate demand before committing to store apps.
- Choose Expo for a startup, an MVP or a production app that needs to reach both the App Store and Google Play quickly with a single team. This covers the majority of business and consumer apps.
- Choose native for high-end games, hardware-heavy products such as fitness devices that sync continuously over Bluetooth, or any app where 120 fps interfaces and zero abstraction risk are genuine requirements.
These choices are not permanent silos. A PWA can coexist with a store app, and an Expo app can contain native modules written in Swift and Kotlin, so a hybrid path is often available when one part of the product outgrows the default.
Wrapping up
None of the three is better in general. The right answer depends on what the product must do on the device, how fast you need to reach users, and how many engineers you can fund. Settle those three questions before writing code: the cost of the wrong choice shows up later as refactors and platform workarounds, while the right one lets the team spend its time on features users notice.