Service
Mobile application development
Native Android, native iOS, and Flutter when the constraints fit — phone and tablet products designed to ship, not stall in prototype theatre.
Many teams can sketch a screen. Fewer can take a mobile product through architecture, device reality, store policy, and ongoing release.
What kind of mobile application
The first question is the job the application has to do. These are the types we design and build.
Consumer tools
Everyday products people install for themselves: expense tracking, cameras, recorders, utilities, and focused games. Treasure, MapSeal, Recora, and Sudoku are this class of work — a clear job, store-ready packaging, and no account wall unless the job actually needs one.
Field and operations apps
Applications used on site: inspections, property visits, deliveries, attendance, and photo proof. These usually need camera, location, offline storage, and later upload. MapSeal is the public example of place-aware capture; client work extends that pattern into workflows and reporting.
Business and internal apps
Catalogues, staff tools, booking, CRM companions, and dashboards that sit on the phone beside a web back office. The phone is the capture and notification surface; accounts, roles, and data live in Firebase or a custom API.
Education and learning apps
Course delivery, practice, live sessions, and assessments. The white-label EdTech platform covers website, Android, and iOS surfaces so an institute can own the learning product instead of renting disconnected tools.
Media, playback, and companion apps
Screen recording, tutorials, media capture, and playback experiences. Recora is the consumer recorder. The same media stack extends to lean-back TV applications and watch or car companions when the product needs a second screen.
Surfaces we build for
Phone and tablet work is the core. Watch, car, and television applications use the same engineering practice with a different interaction model.
Android phones and tablets
Native Android is the default when the product needs the camera, location, background work, media, or OEM behaviour that a wrapper cannot guarantee. It is also the first market for most of the products we publish ourselves.
- New Android products from architecture through Play Console release
- Redesign, performance work, and maintenance of existing Kotlin or Java applications
- Camera, location, maps, media, background tasks, and offline-first storage
- Material Design, tablets and foldables, and accessibility
- Play listing, Data Safety, signing, staged rollouts, and release notes
Stack: Kotlin · Java where a codebase already uses it · Jetpack (Compose, Navigation, Room, WorkManager, CameraX) · Coroutines and Flow · Google Play services · Play Console and Play Integrity
iPhone and iPad
Native iOS is used when the product has to feel like an Apple application: SwiftUI or UIKit, App Store policy, notifications, purchases, and the device APIs the brief actually needs.
- New iPhone and iPad applications in Swift
- SwiftUI for new surfaces; UIKit where an existing app or a specific control requires it
- Sign in, Keychain, push notifications, and in-app purchases
- Camera, location, media, and background modes declared honestly in Info.plist
- App Store Connect, TestFlight, privacy nutrition labels, and review preparation
Stack: Swift · SwiftUI · UIKit · StoreKit · APNs · Core Data or SQLite · App Store Connect
Flutter when a shared codebase fits
Flutter is a choice, not a default. We use it when Android and iOS must ship together, the risky device APIs are ordinary, and a single Dart codebase will stay maintainable — not because a slogan asked for it.
- Shared UI and business logic for list, form, account, and content products
- Platform channels only where a native API is required
- Play and App Store packaging from one project with honest feature parity
- A documented exit to native if camera, sensors, or OEM behaviour outgrow Flutter
Stack: Flutter · Dart · Firebase Flutter plugins · Platform channels
Android Auto and Apple CarPlay
Car applications follow driver-safety templates. The work is media, navigation, messaging, or a narrow set of parked-car tasks — not a desktop UI squeezed onto the dashboard.
- Android Auto media, messaging, and navigation-style templates
- Apple CarPlay scenes that stay glanceable while driving
- Voice, large hit targets, and limited interaction while the vehicle is in motion
- Companion phone apps that hold accounts, libraries, and settings
Stack: Android Auto · Car App Library · Apple CarPlay · Media session APIs · Voice and notification guidelines
Security, Firebase, and Google Cloud
Accounts, data, notifications, and store declarations are part of the product, not an afterthought. We use Firebase and Google Cloud where they fit, with rules and IAM that match the data model.
Firebase Authentication
Email, phone, or federated sign-in when an account is actually required. Session handling, verified emails, and role claims live with the product — Treasure and Recora stay usable without a login because those jobs do not need one.
Cloud Firestore and Security Rules
Per-user and per-role rules, not open collections. Reads and writes are scoped to the signed-in identity or a documented admin path. Rules are reviewed with the data model, not copied from a tutorial.
Firebase App Check
Play Integrity on Android and App Attest on Apple devices so backend and callable functions prefer genuine app installs over scraped API keys.
Google Cloud
Hosting, Cloud Run, Cloud Functions, Storage, and IAM with least-privilege service accounts. Secrets stay in Secret Manager or environment config — not in the client binary.
Device storage and keys
Android Keystore and EncryptedSharedPreferences or SQLCipher where local data is sensitive. iOS Keychain and Data Protection. Offline-first products still encrypt what they keep on the device.
Transport and APIs
HTTPS only, certificate pinning where a high-risk API justifies it, signed requests, and backend validation. Payments go through approved providers; the app never stores raw card data.
Notifications
Firebase Cloud Messaging on Android and APNs on Apple platforms, with topics or device tokens scoped to the user. Notification content stays free of secrets.
Store and privacy declarations
Google Play Data Safety, Apple privacy nutrition labels, permission rationales, and a privacy policy that matches the shipped SDKs. We do not declare a permission the product does not use.
Release pipeline
CI/CD for builds, signing stored outside the repository, staged Play rollouts, TestFlight groups, crash reporting, and a path to revoke a compromised key or rotate an API credential.
Scope
- Native Android with Kotlin, Jetpack, and Play Console release
- Native iOS with Swift, SwiftUI or UIKit, TestFlight, and App Store Connect
- Cross-platform Flutter when product constraints support a shared codebase
- Android Auto and Apple CarPlay experiences that stay driver-safe
- Redesign, performance work, API integration, and maintenance of existing apps
- Firebase, Google Cloud, authentication, notifications, offline data, payments, camera, location, and media
How we deliver
- 01Clarify users, phone and tablet platforms, and the first shippable slice
- 02Architecture, information design, accounts, data, and device constraints
- 03Implementation with testable modules and a security model
- 04Device, emulator, and release testing
- 05Store submission, analytics, crash reporting, and a support plan
Technologies
Kotlin · Jetpack · Swift · SwiftUI · UIKit · Flutter · Firebase · Google Cloud · FCM · APNs · REST and GraphQL APIs · Android Auto · CarPlay
Questions
Will you always recommend Flutter?
No. Flutter is one option. Camera, background location, OEM behaviour, watch, car, and TV templates often argue for native Android or native iOS.
Do you only build phone apps?
Phone and tablet applications are this service. Watch, television, and Mac each have their own service page. Android Auto and CarPlay stay here as phone-companion templates.
What security stack do you use?
Firebase Authentication, Firestore security rules, App Check, Google Cloud IAM and Secret Manager, Android Keystore and iOS Keychain, HTTPS APIs, FCM and APNs, and store privacy declarations that match the shipped SDKs.
Can you take an existing app through a store release?
Yes — technical audit, scoped enhancement, or full rebuild, then Play Console or App Store Connect support. We do not promise a review outcome or a ranking.
Related products: TreasureMapSealRecoraSudokuEdTech
Related services: watch application developmenttv application developmentmacos application developmentwebsite design and development