Mobile App Development
Mobile apps people keep on their home screen
We design and build iOS and Android apps that survive contact with real users — patchy signal, three-year-old handsets and a crowded app store. We have shipped consumer apps, including evera for electric ride-hailing and the Fit and Fab With Swati fitness app.
A senior engineer replies within 24 hours — not a sales rep.
The problems that decide whether an app succeeds
Installs look fine, day-30 retention does not
Acquisition spend brings people in and the app quietly loses them. Onboarding asks for too much before showing any value, the first session has nothing worth returning for, and there is no instrumentation to tell you which screen people abandon. You end up buying the same user twice.
Nobody made a real native-versus-cross-platform decision
The framework got picked because a developer already knew it, or because a blog post said it was faster. Two years later the app needs a Bluetooth integration, background location or a specific camera behaviour, and the team is writing native modules anyway — with all the cost of cross-platform and none of the benefit.
It works on the developer's phone
Built and tested on a current-generation flagship on office WiFi. Your actual users are on mid-range Android handsets with limited memory, on a train, with two bars. The app janks on scroll, drains battery, and does something unforgivable when the connection drops mid-form.
Every release is a fortnight of anxiety
Builds are made by hand on someone's laptop, signing certificates live in a Slack thread, and a rejected review means the fix waits days. Meanwhile a crash reaches production and there is no staged rollout to limit how many users hit it before anyone notices.
How we build mobile
Mobile punishes shortcuts that web forgives — users cannot hard-refresh, and a bad version sits on devices until people update. So we make the platform decision deliberately, build for the worst plausible device and network, and automate the release path before there is anything to release.
The platform choice, argued rather than assumed
We look at what your app actually does. Heavy device integration, sustained graphics or platform-specific UX generally argues for Swift and Kotlin. A content, commerce or workflow app with two platforms and one team is usually better served by React Native or Flutter. We will tell you which case yours is and why, including when the answer is native for one platform only.
Offline as a designed behaviour, not an error state
Local persistence, queued writes and conflict resolution so a user can complete a task in a lift and have it sync when signal returns. Loading and failure states get designed alongside the happy path, because on mobile they are most of the experience.
Performance measured on the devices your users own
We profile cold start, scroll performance, memory and battery on mid-range hardware and throttled networks, not just simulators. Image pipelines, list virtualisation and network payloads get tuned against those numbers rather than against a fast phone in an office.
Release automation and honest analytics
CI builds, signing handled properly, TestFlight and Play internal testing, phased rollouts and crash reporting wired from the first build. Product analytics are instrumented around the funnel that matters — activation, retention, the one action your business depends on — so decisions come from data instead of opinion.
The stack we build on
Chosen to fit the problem — not because it's what we used last time.
Native
- Swift
- SwiftUI
- Kotlin
- Jetpack Compose
- Core Data
- Room
Cross-platform
- React Native
- Flutter
- Expo
- TypeScript
- Dart
Backend & services
- Node.js
- Firebase
- Supabase
- REST & GraphQL APIs
- WebSockets
- Push notifications (APNs & FCM)
Release & quality
- Fastlane
- GitHub Actions
- TestFlight
- Google Play Console
- Firebase Crashlytics
- Detox & XCTest
- Mixpanel / Firebase Analytics
How we'll work together
Every stage ends with something in your hands — not a status update.
- 01
Product and platform shaping
We work out who opens the app on day one, what makes them open it on day seven, and which platform strategy fits that. Device and OS support targets get agreed here, because they change the estimate more than most features do.
You get: A prioritised feature set, a written native-versus-cross-platform recommendation, target device and OS matrix, and a build estimate.
- 02
Interaction design and clickable prototype
Screens designed to platform conventions rather than a web layout squeezed onto a phone, then assembled into a prototype you can hold in your hand and hand to a real user before anyone writes production code.
You get: Design system, screen designs for both platforms, and an interactive prototype installed on a device for testing.
- 03
Build in shippable increments
Two-week sprints, each ending with a build on your phone through TestFlight or Play internal testing. Backend, app and analytics move together, so what you review is the real thing on real infrastructure.
You get: Installable test builds every sprint, backend APIs, automated tests, and source in your repository from the first commit.
- 04
Store submission and post-launch iteration
We prepare store listings, privacy declarations and review responses, then roll out in phases while watching crash-free rates. The first weeks after launch are when the retention data finally tells the truth, so we plan for changes rather than a handover.
You get: Published App Store and Play Store listings, signing assets transferred to your accounts, crash and analytics dashboards, and a post-launch iteration plan.
Where we've applied this
Mobility & transport
Ride-hailing and fleet apps with live location, driver and rider states, trip lifecycle handling and payment flows that behave sensibly when connectivity drops mid-journey.
Health & fitness
Programme and coaching apps with video content, progress tracking, reminders and optional integration with Apple Health or Google Fit.
Retail & e-commerce
Shopping apps where the difference between a sale and an abandoned basket is checkout speed, saved payment methods and a product list that scrolls smoothly on a budget handset.
Healthcare
Patient-facing apps for appointments, medication reminders and secure messaging, built with device-level encryption and cautious handling of anything clinical.
Logistics & field operations
Driver and technician apps that capture scans, signatures and photos offline in warehouses and basements, then reconcile with the back office when a connection returns.
Media & community
Content and social apps where feed performance, background media playback and notification timing decide whether people come back.
Clients we've built for
Real products, in production, with real users on them.
Questions buyers ask us
It depends on what the app does, and we treat it as a real decision rather than a house preference. Apps leaning hard on device capabilities — sustained background location, Bluetooth peripherals, custom camera work, heavy graphics — tend to be cheaper over their life in Swift and Kotlin. Content, commerce and workflow apps that need parity across iOS and Android usually do better in React Native or Flutter, because one team ships both. We make the recommendation during shaping, with the trade-offs written down so you can disagree with it.
A focused first version with a clear core loop typically reaches store submission in a few months, including design, backend and review. Apps with payments, live tracking or third-party integrations run longer. We would rather commit to a date after the shaping phase, when the unknowns have names, than quote one on the first call.
You do, all of it, from day one — repository, designs, signing certificates and store listings. We strongly prefer publishing under your own Apple and Google developer accounts rather than ours, because an app published under an agency account is genuinely painful to move later. If you do not have those accounts yet, we will help you set them up.
It happens, and it is usually procedural rather than fatal: a privacy label, an account deletion path, a sign-in requirement, or a screenshot that does not match the build. We handle the response and resubmission as part of the engagement, and we design around the common rejection triggers before submitting. Budget days rather than weeks for a first review cycle.
Yes, and we do it often. We start with a paid review of the codebase, the crash data and the release setup, then give you a straight assessment — including if the honest recommendation is a rewrite of one layer rather than the whole app. Where the app is live, we stabilise crashes and get releases automated before touching features.
Both, and they are hard to separate. Most retention problems we see are backend latency, notification logic or missing instrumentation rather than UI. We build the APIs, push infrastructure and event tracking alongside the app so that when you ask why users drop at step three, the data exists to answer it.
Got an app idea, or one that isn't retaining?
Tell us who the user is and what the app has to do for them. A senior mobile engineer replies within one business day — with a view on platform, scope and what the first version should leave out.