Service 04
One build, both app stores, submissions handled
We write the app once, test it on real iOS and Android devices, and deal with the store listings, review responses, and the updates that follow.
Why people call us about this
The app is the easy part, shipping it is not
Most app projects stall at review rejections, privacy declarations, signing certificates, and the question of who pushes the next version. We handle that side as part of the job.
- The build works but nobody can get it into the stores
- Two separate codebases meaning every change is done twice
- No crash reporting, so problems arrive as one-star reviews
- Nobody owns the developer accounts
What you get
What an app project includes
We start with whether you need an app at all. Sometimes a good mobile site is the honest answer.
01
Scope and platform call
What the app must do offline, which platforms matter, and whether a web app would do the job cheaper.
02
Design for touch
Screens designed at real device sizes with proper target sizes, not a shrunken desktop layout.
03
One codebase
React Native for both platforms, so a fix lands on iOS and Android in the same release.
04
Device testing
Tested on real phones across screen sizes, plus slow network and offline states.
05
Store submission
Listings, screenshots, privacy details, signing, and the replies to review feedback.
06
Monitoring
Crash reporting and basic analytics from launch day, so you hear about problems from us.
Typical timeline
Eight to fourteen weeks for a first release
Store review adds two to seven days at the end, sometimes more for a first submission.
Step 01
1 week
Scope
Feature list cut to what version one needs, with the rest written down for later.
Step 02
2 to 3 weeks
Design
Screens and a clickable prototype on a phone, tested in the hand before code starts.
Step 03
4 to 8 weeks
Build
Two-week cycles with a test build you can install at the end of each one.
Step 04
1 to 2 weeks
Release
Device testing, store assets, submission, review responses, then launch monitoring.
This service, in the wild
Mobile work from our project list
Open a project to read the full story.
Mobile App Development
Academic platform, nursing and midwifery colleges
Scholarium
The student side of Scholarium as an app: results, fee statements, and timetables, built from the same portal codebase.
Mobile catalogue
Retail, Uromi
Computer accessories store
Catalogue and callback requests designed for phones first, since almost all of the shop’s traffic arrives on mobile.
Tools and platforms
What we build apps with
Developer accounts are registered to you, so the app is yours on both stores.
React Native
Expo
Swift and Kotlin where needed
Firebase
Sentry
TestFlight and Play Console
Placeholder quote, replace with a real client
Students stopped queueing at the office to check results. That was the whole point and it happened in the first week.
Placeholder name
Registrar, placeholder college
Questions we get asked
App questions
Do we really need an app?
Often not. If people use it a few times a year, a fast mobile site is cheaper and easier to keep current. An app earns its cost when you need push notifications, offline use, or a home screen icon people tap weekly.
One codebase for both stores?
Yes, React Native by default, so one fix ships to iOS and Android together. We only write native code when a feature genuinely requires it.
Who owns the store accounts?
You do. We set up Apple Developer and Google Play under your organisation and work as team members, so the app stays yours.
What about updates after launch?
App maintenance is a monthly plan. It covers operating system updates, store policy changes, crash fixes, and small improvements. Apps that stop getting updates eventually stop working.
Previous service
Next service
Thinking about an app?
Tell us what people would do in it weekly. If an app is the wrong answer we will say so on the first call.