MOBILE APPS
Mobile apps that make it through review and stay there
Building an app is the straightforward part. Getting through App Store review, handling the accounts and certificates, supporting the phone someone bought four years ago, and shipping an update without breaking the version already installed is where most first apps come unstuck. We have taken our own product, WashMoose, through that entire path and it is live on the App Store today, so this is not theory.
WHAT YOU GET
Deliverables
One codebase for iOS and Android
Unless there is a specific reason not to. Two native codebases means two of every bug and two of every release, and very few businesses have a reason to pay that twice.
Store submission handled properly
Developer accounts, certificates, provisioning, privacy declarations, screenshots and listing copy. Rejections are usually paperwork, not code, and they are avoidable.
Offline behaviour that is designed, not accidental
What the app does in a carpark with one bar is a design decision. Deciding it deliberately is the difference between an app people trust and one they delete.
Push notifications that respect the user
Set up properly on both platforms, and used for things the user actually asked to know about. Notification permission is granted once and lost permanently.
Crash reporting from the first build
You find out about a crash from your dashboard, not from a one star review a fortnight later.
A release process anyone can run
Documented, repeatable and automated where it can be, so shipping a fix is routine rather than an event.
HOW IT RUNS
The process
Challenge whether it needs to be an app
A well built mobile web experience beats a mediocre app for a lot of businesses, with no install friction and no review queue. If that is the honest answer for you, we will say so before you spend anything.
Define the smallest version worth installing
The first release should do one thing so well that a user keeps it on their phone. Everything else is version two, and version two is much cheaper than a bloated version one.
Build with real devices in the loop
Tested on actual phones across a spread of ages and screen sizes throughout, not only on the newest simulator.
Beta with real users
TestFlight and Play internal testing before public release, so the first public review comes from someone who is not surprised by anything.
Submit and iterate
We handle the submission and any review back and forth. Then the real work starts: watching how people actually use it and fixing what they trip over.
TOOLS WE USE
The stack
- Flutter for cross platform builds
- React Native where an existing web codebase makes it the better fit
- Firebase for authentication, push and realtime data
- Supabase and PostgreSQL backends
- Google Maps and location services
- Stripe and in app purchase
- App Store Connect and Google Play Console
WHO IT SUITS
Best for
- Businesses whose customers genuinely need something on their phone, not just a link
- Marketplaces and booking platforms with two sided user flows
- Founders with a validated idea who need it built and shipped properly
- Companies with an app that was built once, abandoned, and now needs rescuing
HOW WE WORK TOGETHER
Engagement
- TYPICAL TIMELINE
- A focused first release is typically eight to twelve weeks including store review.
- WHERE WE START
- A scoping engagement covering platforms, store requirements, the realistic first release, and a fixed quote.
- COMMITMENT
- Post launch support is strongly recommended and priced separately. Apps that stop being maintained stop working, because the platforms move underneath them.
QUESTIONS
Frequently asked
Should I build an app or a mobile website?
Build an app when you need something a browser cannot do well, such as reliable push notifications, background location, camera driven workflows or offline use, or when customers will genuinely open it repeatedly. Build a mobile website when the goal is reach, discovery or a single transaction, because you avoid the install barrier entirely. The install barrier is real and it is the reason a lot of business apps sit unused.
How long does it take to get an app into the App Store?
Development for a focused first release is typically eight to twelve weeks. Apple review itself is usually a day or two once submitted, but a first submission commonly comes back with something to fix, so the honest planning assumption is a week or two of buffer around the submission date. Google Play is generally faster.
Do you build native or cross platform?
Cross platform by default, using Flutter, because one codebase means one set of bugs and one release process. We recommend native only when the app depends heavily on platform specific capabilities or performance that cross platform genuinely cannot match, which is less common than it used to be.
What does it cost to maintain an app after launch?
More than most people expect, and it is not optional. Apple and Google both push breaking platform changes and periodically require apps to be rebuilt against newer requirements to stay listed. Budgeting an ongoing amount for maintenance from the start is the difference between an app that is still working in three years and one that quietly stops.
Have you actually shipped an app?
Yes. WashMoose is our own mobile car wash booking platform, built in house and live on the Australian App Store. It is the reason we can be specific about the store process rather than vague about it.
KEEP EXPLORING
Related work
Web Application Development
Fast, accessible websites and web applications that search engines and answer engines can actually read.
Read moreCustom Software Development
When off the shelf software nearly fits but not quite, and the workarounds are now the job.
Read moreWe deliver mobile app development remotely across Australia, from our base in Sydney, New South Wales and Launceston, Tasmania.
Want to know if this is worth building?
Tell us the process that is costing you the most time. We will tell you honestly whether software fixes it, what it would take, and whether an off the shelf tool would do the job for less.