Mobile App Development
Android and cross-platform, with a straight answer on which you need.
We build Android applications in Kotlin and Jetpack Compose, and shared-code applications when the economics favour them. You get a recommendation with reasons, and it is not shaped by what we happen to prefer writing.
What we build for mobile
Android applications
Kotlin and Jetpack Compose, tested across the device range your users actually carry, not the newest flagship alone.
Shared-code products
Flutter, React Native or Kotlin Multiplatform when one team and one codebase genuinely serve the product better.
Enterprise and rugged devices
Android Enterprise, managed Google Play, kiosk modes and hardware scanners for warehouse and field fleets.
The backend behind the app
APIs, authentication, push notifications and sync services, hosted in Canada when your obligations require it.
Where mobile projects are won or lost
Slow devices are the test
Your customers do not all own this year’s flagship. Performance budgets are set against mid-range hardware and checked on every build.
Offline is the normal case
Basements, warehouses, rural highways. Local-first storage and a dependable sync queue are designed in from day one, because they cannot be added later without a rewrite.
Store policy moves underneath you
Google Play raises its target API requirements every year. Maintenance plans account for that, so your listing is never at risk of being pulled.
Which approach fits
The comparison we start from.
| Native | Shared code | Web application | |
|---|---|---|---|
| Built with | Swift and Kotlin | Flutter, React Native, Kotlin Multiplatform | Modern web stack, installable as a PWA |
| Hardware access | Complete | Good, with plugins and some native work | Limited, and varies by browser |
| Feel on the device | Exactly right, by definition | Very close, with care | Good for content and forms |
| Upfront cost | Highest | Moderate | Lowest |
| Long-term upkeep | Two codebases, very stable | One codebase, plus framework upgrades | One codebase, no store review |
| Choose it when | The app is the product, or leans on hardware | Mostly screens and data, on a tighter budget | Reach matters more than device features |
Tools
The stack we reach for.
- Android
- Kotlin, Coroutines, Jetpack Compose
- Shared code
- Flutter, React Native, Kotlin Multiplatform
- Persistence
- Room, SQLDelight, WorkManager
- Testing
- JUnit, Compose UI Test, Macrobenchmark
- Delivery
- GitHub Actions, Gradle Managed Devices, Fastlane
- Distribution
- Google Play, managed Google Play, Android Enterprise
Questions we hear first.
Should we build native or cross-platform?
If your product depends on hardware, platform features or top-tier performance, build native. If it is mostly forms, content and lists, and budget is the constraint, shared code is often the better business decision. The comparison on this page sets out how we weigh it.
Do we need separate teams for iOS and Android?
Not separate vendors. Native builds have platform specialists sharing one product plan, one API and one release calendar. Shared-code builds have a single team and a smaller amount of platform-specific work at the edges.
Whose Google Play account does the app live under?
Yours. Google requires a D-U-N-S number for organization accounts, so we suggest starting this early. Your organization keeps the listing, reviews and billing relationship.
What will it cost?
Cost follows scope and integrations rather than screen count. Discovery is a fixed fee and ends in a written estimate, an architecture recommendation and a release plan.