React Native vs native: how Polyforge uses Expo and Kotlin together
We are not ideological about frameworks. The right tool is the one that ships a maintainable product on time—without hiding platform realities from the user. In practice that means Expo (React Native) for many surfaces and Kotlin when Android behaviour must be owned end-to-end.
When Expo wins
- Rapid iteration on UI flows, forms, and content-heavy screens.
- Shared business logic between iOS and Android with one team velocity.
- OTA-style workflows where appropriate (always alongside store policy).
When we reach for Kotlin
- Foreground services, exact alarms, and notification channels that must be bulletproof.
- Deep integration with OEM-specific power management quirks.
- Performance-critical paths where the bridge or JS thread would be a liability.
Hybrid products are normal
A single app can ship a React Native shell while critical modules are native modules or a sidecar Android component. The art is drawing the boundary so debugging stays tractable—clear ownership, logging, and contracts between layers.
Hiring a London / UK studio for Android app development? We combine product sense with platform depth.