Mobile app development
Native iOS and Android apps, or a single Flutter or React Native codebase when the product allows it. We'll tell you which one we'd pick, and why, before you sign anything.
Start a projectWhat’s included
- iOS development
- Swift and SwiftUI for new work. UIKit where an existing app still depends on it, which is most of them.
- Android development
- Kotlin and Jetpack Compose, tested on the mid-range devices your users actually carry, not only on a Pixel.
- Cross-platform
- Flutter or React Native, when two native teams would cost more than the product needs to spend.
- First release
- The smallest version that passes App Store and Google Play review and starts teaching you something.
- Taking over an existing app
- Code audit, build pipeline repair and a written list of what to fix first. For when the previous team has moved on.
- Store releases and upkeep
- Signing, review submissions, yearly OS updates, and crash triage after each release.
See it working
Sign in
Welcome back
Enter your password to continue.
Incorrect password. Try again.
Sign in
Welcome back
Enter your password to continue.
Incorrect password. Try again.
imePadding() and bring-into-view.Reports
+
- Roof inspection, Block CToday, 09:12
- Meter reading, Unit 2AYesterday, 16:40
How it usually runs
- 1. Scope
1–2 weeks
Screens, flows, what is left out of the first version, and the native vs. cross-platform decision, all in writing.
- 2. Build
2-week cycles
Every cycle ends with a build you can install on your own phone through TestFlight or Play internal testing.
- 3. Launch
Store submissions, review back-and-forth, then fixing what real users run into in the first weeks.
What you have at the end
- Source code in your repository from the first commit
- CI builds for both stores, signed with keys held in your accounts
- Crash reporting and analytics connected to your accounts, not ours
- A release checklist your team can run without us
Stack
- Swift
- SwiftUI
- Kotlin
- Jetpack Compose
- Flutter
- React Native
- Firebase
- Fastlane
- TestFlight
- Play Console
From our engineering notes
What went wrong, the code that fixed it, and what we do differently now.
- The error message was on screen. The keyboard was on top of it.An automated UI test found the wrong-password message and passed, over and over. On a real phone, nobody could see it.
- A 30-minute timer that stopped running when the phone went to sleepWe patched the symptom twice before replacing the thing that was actually wrong. Here's how that happened, and the fix.
- Where a session token should live on iOSUserDefaults is convenient, and it's a plain property list. Tokens belong in the Keychain, with an accessibility class chosen on purpose.
Questions we get
Native or cross-platform?
Cross-platform is usually fine for forms, lists, content and payments. We lean native when the app lives on the camera, Bluetooth, background location or heavy animation. The scoping document gives the reasoning for your case.
Can you take over an app another team built?
Yes. We start with a short paid audit so we both know what we're inheriting before quoting the rest.
Tell us what you're working on.
A few paragraphs is plenty. We'll read it, reply by email, and if it looks like a fit, set up a 30-minute Google Meet with an engineer.