The architecture decisions that decide whether a platform still works, untouched, three years after launch, and how a Vermont studio makes them early.
Mobile apps for iPhone and Android, from one codebase
One React Native codebase for both app stores, with native work where the platform asks for it: watch apps, Live Activities and the lock screen.
Our approach
A phone app is judged in the first ten seconds. It has to open fast, show the one thing the person came for, and stay out of the way. We design the app around that moment first, then build the account, settings and edge cases around it.
We use React Native with Expo so iPhone and Android share one codebase and one team, then drop into native Swift or Kotlin for the parts that need it, such as an Apple Watch companion, a Live Activity on the lock screen, or background location.
What is included
- App design
- Navigation, key screens and states designed for thumbs and small screens, including empty, offline and error states.
- iPhone and Android
- One React Native and Expo codebase, with native modules where the platform requires them.
- Lock screen and watch
- Live Activities, the Dynamic Island, widgets and Apple Watch companions when they serve the product.
- Back end and sync
- APIs, push notifications, offline storage and sync, built so the app still works on a weak connection.
- Store release
- TestFlight and Google Play testing tracks, store listings, review submissions and release management.
- Privacy by default
- Data kept on the device where possible, and analytics only when you decide you need them.
Who it is for
- Companies whose customers need to act from their phone, not a desk.
- Founders launching a consumer app on both stores without two separate teams.
- Teams with a web product that needs a proper mobile companion.
How the work runs
Built with React Native, Expo, Swift, TypeScript, Node.js and PostgreSQL.
01
Scope
Agree the one job the app must do well, the platforms, and what waits for a later release.
02
Design
Clickable prototypes of the key flows, tested on real phones before engineering starts.
03
Build and test
Builds on TestFlight and Google Play internal testing every week or two.
04
Release and maintain
Store submission, then updates for new OS versions and new features after launch.
Examples
Case studies where this was the main job.
Questions
Should we build native or cross-platform?
For most products, one React Native codebase with native modules where needed gives you both stores for close to the cost of one. We recommend fully native only when the app depends on platform features that cross-platform tools handle poorly.
Can you publish the app under our developer accounts?
Yes. The apps are published under your Apple and Google developer accounts, so you keep the listings, reviews and customer relationship.
Do you build Apple Watch apps?
Yes. Pacelit has a native SwiftUI watch companion that works alongside the React Native phone app.
What happens when a new iOS or Android version ships?
We test the app against the betas and ship any updates it needs, as part of ongoing maintenance.
Read next
- How we architect platforms for a five-year horizon
Other services: Web applications and SaaS, Internal tools and business systems, Modernizing older software
Tell us what you are building.
A few lines about the project and when it needs to ship is enough to start.