Mobile apps
iOS and Android apps, built and kept current
We build mobile apps in React Native when one codebase makes sense, and in Swift or Kotlin when it doesn't. We handle App Store and Google Play releases, and keep the app working through every OS update.
Who it's for
Clients usually come to us for mobile apps in one of these situations.
Your customers are asking for an app
You already have a web product and an API. You need iOS and Android apps that share accounts and data with it, without a second backend.
Field staff work on paper or with poor signal
Technicians, drivers or inspectors need forms, photos and signatures that work offline and sync when they reconnect.
Your app is stuck
It no longer builds, was rejected in store review, crashes on the latest OS, or the vendor that wrote it is gone.
What we build
We'll recommend cross-platform or native based on what the app needs to do, not on what we prefer to write. The choice is explained in writing before we start.
- Companion apps for a web product
- Mobile access to an existing platform, sharing the same API, accounts and design system as your web app.
- Field and operations apps
- Offline-first apps for crews and technicians: forms, photos, barcode scanning, signatures and background sync.
- Consumer apps
- Onboarding, in-app purchases and subscriptions, push notifications and analytics, with attention to app store review rules.
- Native features
- Camera, Bluetooth, HealthKit, location, widgets and Apple Pay or Google Pay, written natively where a bridge isn't enough.
- App rescues
- Taking over an app that no longer builds, crashes on new OS versions or was abandoned by a previous vendor.
How we approach it
Every request moves through the same steps, inside your weekly release cycle.
- 01
Platform decision in writing
We compare React Native and native for your feature list and recommend one, with the trade-offs spelled out.
- 02
Test builds every week
You get TestFlight and Google Play internal testing builds with each release, so you can try changes on real devices.
- 03
Store submissions handled
We prepare listings, screenshots and privacy disclosures, submit builds and respond to review feedback.
- 04
Crash and performance tracking
Crash reporting and performance metrics are set up from the first build, and regressions become requests.
Typical timeline
Engagement timeline
A typical schedule for a first release on both the App Store and Google Play.
About 14 weeks to both app stores
Weeks 1 to 2
Platform decision and spec
React Native or native, recommended in writing, plus the feature list for the first release.
Weeks 2 to 4
Key screen design
Onboarding, the main flows and settings, designed to each platform's conventions.
Weeks 3 to 5
Foundations
Signed builds from CI, crash reporting, authentication and push notification setup.
Weeks 5 to 11
Feature build
Features shipped in weekly TestFlight and Google Play internal testing builds.
Weeks 10 to 13
Beta testing
TestFlight and Play closed testing with real users; stability and accessibility passes.
Weeks 13 to 14
Store submission
Listings, screenshots and privacy disclosures prepared; builds submitted and review feedback handled.
Typical for a first release on a Growth plan. Apple and Google set their own review times, which can add days, so we plan launch dates with a buffer.
What you get every week
Releases happen on a fixed day each week. Monday starts with a queue check; Friday ends with these in your inbox and your shared channel.
A build on your phone
TestFlight and Google Play internal testing builds with each release, so you try changes on real devices, not screenshots.
Release notes
What changed, which OS versions were tested, and anything to try specifically in this build.
Stability summary
New crashes and errors since the last build, with what we're doing about each one.
Demo recorded on devices
A short video of the week's changes on both platforms, including offline and error states.
Quality standards
The targets we hold this work to, and how we check them. These are our commitments for how the work is done, not certifications.
- Release management
- Our targetSigned builds from CI, phased release on the App Store and staged rollout on Google Play, with a written checklist per version.
- How we checkRollouts are paused automatically or manually if crash reports spike after release.
- Crash reporting
- Our targetCrash and error reporting from the first build, tagged with release and device details.
- How we checkNew crashes reviewed weekly; regressions become priority requests.
- Accessibility
- Our targetDynamic Type and font scaling, VoiceOver and TalkBack labels, contrast and touch target sizes in line with WCAG 2.2 AA.
- How we checkA manual screen reader pass on every new screen before it ships.
- Store compliance
- Our targetPrivacy nutrition labels and the Google Play Data safety form match what the app actually collects.
- How we checkA pre-submission review against current App Store and Google Play guidelines.
- Device coverage
- Our targetSupported OS versions and device classes agreed in writing at the start.
- How we checkA test matrix of real devices and simulators kept in the repository.
- Offline behavior
- Our targetDefined behavior for no connection and slow networks on every screen that loads data.
- How we checkTested with network throttling and airplane mode before each release.
Typical deliverables
What you can expect to have in hand, in accounts and repositories you own.
- Apps published under your own Apple and Google developer accounts
- Source code and build pipeline in your repositories
- TestFlight and Play internal testing builds weekly
- Store listing copy, screenshots and privacy labels
- Crash reporting and release health dashboards
- Upgrade plan for each new iOS and Android version
Illustrative example, not a client case study
Example engagement
A field service company moves inspections off paper
Picture a company whose technicians complete inspection forms on paper, photograph them and email them to the office at the end of the day. Forms get lost, and handwriting causes rework.
Weeks 1 to 2
Choose the approach
Interviews with technicians confirm that signal is unreliable on site. We recommend React Native with offline storage and explain the trade-offs in writing.
Weeks 3 to 8
Forms that work offline
Inspection forms, photo capture, signatures and background sync ship in weekly TestFlight and internal testing builds to a few technicians.
Weeks 9 to 12
Closed testing with a crew
One crew uses the app on real jobs. Sync conflicts and confusing fields they report are fixed in the following builds.
Weeks 13 to 14
Publish and roll out
The app is submitted under the company's own developer accounts and rolled out in stages to the rest of the field team.
Where it ends up
Technicians complete inspections on their phones with or without signal, reports reach the office when they reconnect, and the company owns the apps, listings and developer accounts.
Technologies we use
A short, well-known list. We'd rather know a few tools deeply than list every framework we've touched.
| Area | Tools |
|---|---|
| Cross-platform | React Native, Expo, TypeScript |
| Native | Swift, SwiftUI, Kotlin, Jetpack Compose |
| Services | RevenueCat, Firebase Cloud Messaging, Sentry |
| Release | Fastlane, EAS Build, GitHub Actions |
Which development plan fits
Mobile apps is delivered under a development subscription. These are the plans that suit this work best.
Starter
$390 per month, best fit
One mobile codebase and one request at a time. Suits a focused first release on one or both stores.
Start with StarterGrowth
$790 per month
Web and mobile in parallel with a shared design system. The most common plan for mobile work.
Start with GrowthScale
$1,490 per month
Four parallel requests for apps with several platforms, native modules or a busy release schedule.
Start with Scale
Common questions
If yours isn't here, ask us on a call or by email.
React Native or native?
React Native is usually the faster and cheaper path when the app is mostly screens, forms and API calls. Native makes sense for heavy device integration, complex animation or when you already have native code. We'll explain the recommendation for your app specifically.
Whose developer account is the app published under?
Yours. We're added as team members to your Apple Developer and Google Play Console accounts. The app and its listing stay with your company if you stop working with us.
What happens when Apple or Google release a new OS?
We test against the beta releases, fix what breaks, and ship an update before the public release where we can. This work is a normal request in your queue.
How long does app store review take?
Apple and Google set their own review times, and they vary. We submit early, plan launch dates with a buffer, and handle any rejection feedback as a priority.
Can you add in-app purchases or subscriptions?
Yes, using StoreKit and Google Play Billing, often through RevenueCat. We'll explain which purchases the stores require to go through their billing and how their fees apply.
Do you support tablets and older devices?
We agree on supported OS versions and device classes, including tablets, in writing before we start, and test against that list on every release.
Talk to an engineer about mobile apps.
A 30-minute call with an engineer, not a sales script. You'll leave with a scope, a plan recommendation and a start date.