Services / mobile
one codebaseevery device
iOS, Android, and web from one TypeScript codebase. The Sports Team App's coaches and players see the same live schedule. That is the 60% cut. One roster, not three native teams.
- off building native twice
- 60%
- faster to a store build
- 3×
- apps shipped, Ionic and React Native
- 25+
Why one codebase
Native quality without a native dual-track. Ionic and React Native cover the phones. The web client is the same product.
Ionic, Capacitor, React Native
Web tech when the product is a workflow. React Native when the animation budget is tighter. TypeScript in both.
60% off the dual-track
iOS, Android, and web share the screens. Bug fixes land once. Store releases still go through each review.
3× to first store build
One design system, one API client, one QA pass against the shared flows.
Native where it counts
Push, biometrics, camera, and background location go through the native bridge. Users do not see a webview tell.
The same UX, platform details kept
Shared flows, platform chrome. iOS gets the swipe. Android gets the back stack it expects.
Updates that land together
A schedule bug is not fixed on iOS and left on Android for a sprint. The shared module ships to both.
The two stacks I keep reaching for
Ionic when the team already thinks in the web. React Native when the app needs native lists and gestures all day.
Ionic and Capacitor
Web UI, native shells, device APIs through Capacitor. The Sports Team App's web and mobile clients come from this family.
React Native
True native views, React mental model, one TypeScript repo. Used when scroll performance is the product.
The glass it has to fit
Pick a surface. The shared TypeScript app is the same. The layout is not.
Tablet
Split views, tables, and a dashboard a coach can run a session from. I do not stretch a phone layout and call it tablet.
- Multi-pane list and detail
- Charts and filters on one screen
- Landscape as a first-class layout
Phone
The daily driver. Offline, push, and 60fps on the interactions people hit a hundred times a day.
- Platform scroll and gestures
- Push through APNs and FCM
- Roster still opens offline
Watch
Glanceable state, not a shrunk phone. Complications, haptics, and a few actions that make sense on a wrist.
- Live activity on the face
- Confirm, skip, ping
- No forms
Car
The car is not a phone with a bigger screen. Fewer choices, bigger targets, voice first.
- Turn-by-turn
- Steering-wheel audio
- Hands-free calling and replies
Hardware the app can actually use
The bridge is there so the product can talk to the world around the phone. I wire the ones the brief needs, not a sensor museum.
Radios and identity
Talk to devices, tags, and the person holding the phone.
- Bluetooth / BLE
- NFC
- Face ID, Touch ID, biometrics
Where this lands
The same integrations show up in a few kinds of product.
- IoT and smart-home control
- Fitness and health accessories
- Retail scan-and-pay
Where the binary runs
Write once. Ship the shell each store expects.
iOS
iPhone, iPad, and Watch from the shared TypeScript app.
- iPhone
- iPad
- Apple Watch
Android
Phones, tablets, and Wear OS with the same business logic.
- Android phone
- Android tablet
- Wear OS
Web
The desktop and mobile browsers, plus an installable PWA when the store is the wrong channel.
- Desktop browser
- Mobile browser
- Installable PWA
Desktop
When the product also needs a window on a laptop. PWA or Electron, depending on the OS APIs.
- Windows
- macOS
- Linux
If native dual-track is the budget problem
Tell me the surfaces you need. I will tell you whether Ionic, React Native, or a PWA is the honest cut.