If a recruiter or technical buyer scans vishu.app and only sees React Native - no standalone Swift app, no Kotlin-only repo - the lazy conclusion is “cannot do native.” That reading is wrong. I choose React Native on purpose because cross-platform is how I ship mobile products faster and cheaper without lowering the quality bar my clients actually pay for.
The decision in plain language: React Native is a strategic efficiency choice. The lack of dual native codebases is not a gap in the portfolio. It is the portfolio strategy.
The decision, stated explicitly
I build mobile products in React Native and TypeScript, usually with Expo, and I pair them with Next.js web apps and Node or Fastify APIs. I do this because the products I ship - logistics, food-tech kiosks, hospitality companions, wellness, recruitment - share the same constraints:
- The client needs iOS and Android, or a tablet kiosk plus a phone app, on one budget.
- Time-to-first-revenue matters more than a platform-specific animation.
- The web dashboard and the mobile client must share the same domain model.
- One person (or a very small team) has to maintain the product after launch.
What clients actually buy
Clients do not buy a SwiftUI showcase. They buy a shipper who can create an order, a driver who can navigate and mark delivered, a diner who can tap a kiosk without staff, and an operator who can see all of that in one admin. Those jobs are product and systems problems. They are solved by a reliable API, a clear data model, offline queues, GPS, payments, and a UI that does not fight the user.
React Native is unusually good at that job when the rest of the stack is also TypeScript. The same types that describe an order on the SVSFood Fastify API describe the cart on the kiosk and the ticket on the rider phone. The same patterns that power SharpOrders on iOS power the driver workflow on Android. I am not maintaining two source-of-truth UIs that drift apart after the first release.
Production evidence, not a tutorial opinion
SharpOrders: two apps, one React Native codebase
SharpOrders is a two-sided logistics product for SharpOrder Inc. in Johannesburg. Shippers create and track deliveries. Drivers accept jobs, stream GPS, and capture proof of delivery. Both surfaces share authentication, the API client, and state-management patterns. Building that twice in Swift and Kotlin would have burned the timeline and the budget for no user-visible gain. The app is live on the iOS App Store. GPS uses native location services through Expo Location; photos use the device camera; offline status updates sit in a local queue and flush when coverage returns - common on South African delivery routes.
SVSFood: kiosk tablets and a rider app from the same stack
SVSFood replaced a third-party Uengage subscription with a system they own. The in-store self-ordering surface is a React Native / Expo kiosk on 10-inch tablets: category browse, variants, coupons, QR receipts, staff PIN, offline queue. The delivery surface is a React Native Android rider app with Maps navigation and live status. Both talk to one Fastify API and one PostgreSQL database. The “missing native apps” here would have been two extra codebases for hardware that is already well served by React Native’s touch and offline story.
That stack contributed to ₹7L+ revenue in the first month on self-ordering devices alone. The business outcome did not require a UIKit rewrite. It required ownership of menu, inventory, pricing, and order state.
Ten-plus mobile apps, one language
Across the portfolio I have shipped 10+ mobile apps. YogaFlow, Campus Cupid, City Care, and other client products follow the same rule: React Native when the product is a workflow, not a game engine. Web stays on Next.js. Shared TypeScript is the efficiency multiplier.
The cost and speed math
A focused MVP with me is usually 4–8 weeks. Dual native projects with feature parity are closer to two teams or two sequential builds. For a startup or an SME, that is not “more professional.” That is delayed revenue and a forever-forked backlog.
| Dimension | Dual native (Swift + Kotlin) | React Native (my default) |
|---|---|---|
| Codebases to maintain | Two, plus a third if there is a web app | One mobile codebase; types shared with Next.js |
| Typical MVP window | Two sequential native builds | 4–8 weeks for iOS + Android (or kiosk + phone) |
| Bugfix cost | Fix twice, QA twice, release twice | One pull request, both platforms |
| Team shape | iOS specialist + Android specialist | One full-stack engineer who also owns the API |
| Best fit | Games, custom BLE, OS-level products | SaaS companions, logistics, kiosks, bookings |
I am the full-stack owner on most engagements. React Native lets the same person who designed the Postgres schema ship the phone UI without a handoff tax. That is how a solo product engineer launches 30+ products without a twenty-person mobile department.
What this choice is not
It is not a claim that React Native is always faster than UIKit. It is not a claim that every animation should go through the JS bridge. It is not a refusal to write native modules when a product needs them. Expo’s location, camera, secure store, and notifications cover the 90% case I see in production. When something must be native, I drop to a native module. I do not start there by default.
When I would go native
- Real-time games or heavy 3D where the engine is the product.
- Deep Bluetooth, NFC, or custom hardware protocols that Expo and community modules cannot support cleanly.
- A client who already has a large native team and an existing Swift/Kotlin codebase I should extend, not replace.
- OS-level products (keyboard, VPN, CarPlay-first) where the platform SDK is the interface.
None of the live client systems on this site fall into those buckets. Treating “no native repo” as a weakness is measuring the wrong artifact.
How I keep quality high without two native teams
- TypeScript end to end. API contracts and mobile models stay aligned.
- Offline-first for field apps. SharpOrders and the SVSFood kiosk queue writes locally and sync when the network returns.
- Native device APIs through maintained Expo modules - location, camera, maps - instead of re-implementing platform kits.
- One design system. Spacing, type, and interaction patterns stay consistent on phone and tablet.
- Production observability. Crashes and API errors are not “cross-platform mysteries”; they are typed failures in one codebase.
How to read this choice
Short version: I am a full-stack product engineer who standardizes on React Native for mobile efficiency. I ship iOS, Android, kiosk, and rider apps from one TypeScript stack, paired with Next.js, PostgreSQL, Docker, and GCP. 30+ products and 10+ mobile apps for clients including SVSFood, SharpOrders, YogaFlow, and others across 8+ countries. The missing native-only repos are the point of the strategy, not evidence against it.
I choose React Native so clients get both platforms, one backlog, and a product that can be maintained by a small team. That is the efficient path. I will choose native when the product is the platform - not when the product is a workflow.
For the infrastructure that sits behind those apps - containers, Cloud Run, and Postgres - see how I use Docker, GCP, and Supabase to scale.