Android and iOS apps, from first build to the store listing.
Freelance and contract app development from a senior engineer who ships. My own app, RadioShake, is live on Google Play with 1,000+ installs and runs on the phone, a standalone Wear OS watch app, Android Auto and Chromecast from one codebase. If you need an Android app developer or an iOS app developer for something more involved than a single screen, this is what that looks like.
What I build
Native Android in Kotlin and Jetpack Compose, with Media3 for playback, Room for local data and Hilt for dependency injection. RadioShake is the worked example: a single Gradle project with phone, watch and shared modules, a Media3 session that every surface consumes, and a stream-resilience layer that copes with the dead URLs and broken redirects of real-world internet radio.
The surfaces most teams skip. A standalone Wear OS app (not a phone companion), an Android Auto browse tree designed for glance-and-tap, and Chromecast output are each a separate platform with its own review process and its own failure modes. If you have an Android app that needs one of them, or you are planning one that should have them from day one, this is the work I have already done end to end.
iOS in SwiftUI. On RadioShake the iOS app sits on a shared Kotlin Multiplatform module, so station and region rules are written once and used by both platforms. That app is in development and is not yet on the App Store or TestFlight; the point for a client is the architecture, which stops Android and iOS drifting apart on business logic.
Cross-platform React Native when one codebase fits the product. IronPulse is a bare React Native 0.81 app running natively on iOS and Android, offline-first on PowerSync and SQLite, with HealthKit and Google Fit, passkeys, Stripe subscription tiers and Maestro end-to-end tests on both platforms. It is a working build rather than a published app.
The companion pieces that make an app a product: a web player or PWA (RadioShake’s runs at app.radioshake.media), a marketing site, store listing assets, and deep links or App Links that open the right screen from the web.
How a project runs
- Scoping call. What the app has to do, on which platforms and surfaces, and what already exists behind it.
- Written scope. A short document you can sign off, covering screens, integrations, what is deliberately left out, and how the work is split into releases.
- Small releases you can install. Builds go to Google Play internal and closed testing tracks (and TestFlight once an iOS app is ready for testers) so you are using the real app from the first few weeks, not reading status reports.
- Store submission, end to end. Signing keys, Play’s closed-testing requirement for new personal developer accounts, Data safety and privacy labels, listing assets and localisation.
- After launch. Crash monitoring, OS-version updates and responding to policy warnings, on a support arrangement agreed upfront.
Who this is for
- Startups that need a first app or an MVP built properly, with the store process handled rather than left as a surprise at the end.
- Businesses with a web product that need a native app alongside it, sharing the same backend and design language.
- Teams with an existing Android app that needs Wear OS, Android Auto or Cast added without destabilising the phone app.
- Teams that need a senior contractor to unblock a release: a stuck store submission, a playback bug, a sync problem, an OS update that broke things.
Relevant work
Case studies from the app work behind this page. RadioShake is on Google Play; IronPulse is a working build that has not been published to either store.
- RadioShake: Kotlin and Compose across phone, standalone Wear OS, Android Auto and Chromecast on one Media3 session, 45,000+ stations, live on Google Play. The iOS app and the web player are covered in the case study.
- IronPulse: React Native 0.81 on iOS and Android with an offline-first sync layer, health-data integrations, passkeys and Stripe tiers.
- Slipstream: a hand-built local-first sync engine (optimistic mutations, offline queue, server reconciliation), the same problem any app that must work without a signal has to solve.
See it for yourself: RadioShake on Google Play · radioshake.media · All case studies →
Common questions
- Should my app be native or cross-platform?
- It depends on the product. Native Kotlin or SwiftUI is the right call when you need the platform’s own surfaces (a Wear OS app, Android Auto, background media, widgets) or the best possible feel. React Native fits when one team and one codebase matter more, as with IronPulse. Where a native iOS and Android pair makes sense, I share the business rules in Kotlin Multiplatform so they are written once. I’ll recommend one after a scoping call rather than defaulting to a favourite.
- Do you build for iOS as well as Android?
- Yes. Android is where my shipped work is: RadioShake is live on Google Play. On iOS, RadioShake’s native SwiftUI app is in development on a shared Kotlin Multiplatform module and is not yet on the App Store or TestFlight, and IronPulse runs natively on iOS and Android from one React Native codebase as a working build. I’ll tell you plainly what has shipped and what hasn’t.
- Will you handle the App Store and Google Play submission?
- Yes, end to end: signing keys, test tracks, Play’s closed-testing requirement for new personal developer accounts, Data safety and privacy labels, store listing assets and localisation. I’ll also stay on for crash monitoring, OS updates and policy warnings after launch if you want that.
- Who owns the code and the store accounts?
- You do. The store developer accounts are registered in your name, the source lives in your repositories, and the signing keys are handed over with documentation. I build and publish on your behalf; I don’t hold your app hostage.
- How much does an app cost?
- It depends on scope: platforms, surfaces, backend and how much has to work offline. That is best discussed on a call, and I’d rather give you a straight answer for your project than a starting-from price that never applies. Email [email protected] or call 07827 443 288.
- Where are you based?
- Reading, Berkshire. I work remotely with clients across the UK, with on-site days in Reading, the Thames Valley or London when they help.
Need an Android or iOS app built? Email [email protected] or call 07827 443 288. Same-day reply most days, and a first call to scope it costs nothing.
Reading-based business? My studio arm, Noctal Studio, builds fixed-price websites and scoped apps for small businesses in Reading and Berkshire.
Back to home · About · Selected work · Web development in Reading · Get in touch