Cross-platform mobile apps built from one maintainable codebase
One codebase covering both platforms halves the build and roughly halves the maintenance for the rest of the app's life. It is the right default, and we will tell you the specific cases where it is not.
What is mobile apps?
Mobile App Development is designing and building applications for iOS and Android, most often from a single cross-platform codebase using React Native or Flutter, then publishing them through the App Store and Google Play. It suits Australian businesses whose customers or field staff need something on their phone rather than in a browser.
Get a fixed written quote- Typical timeline
- 12 to 24 weeks
- What drives cost
- The number of distinct screens and user roles, whether the backend already exists, offline requirements.
- Best for
- Apps needing both platforms, push notifications, offline use or device features
- You own
- The codebase, the developer accounts and the store listings
- Built with
- React Native or Flutter, native modules where required, automated release pipelines
Your handover
What app store review actually involves
Two separate gatekeepers with different temperaments. Apple reviews manually, applies its guidelines with some inconsistency, and rejects for reasons that are frequently about policy rather than defects. Google is largely automated with policy checks and is faster, but a policy violation can suspend a live app with limited warning, which is the more frightening failure mode.
- 01Cross-platform codebase covering iOS and Android
- 02Automated build, signing and distribution pipeline
- 03Store listings with screenshots, copy and privacy disclosures
- 04Push notification infrastructure with segmentation
- 05Offline behaviour and data sync where the workflow needs it
- 06Crash reporting and analytics wired to real events
- Staged rollout and remote configuration
- Developer accounts registered to your business
- Release runbook and maintenance schedule
The rejections we see most often are avoidable and we design around them from the start
The rejections we see most often are avoidable and we design around them from the start. Apple requires that anything unlocking digital content or features inside the app uses its in app purchase system, which has commercial implications you need to understand before choosing a monetisation model. Both stores require a working demo account for reviewers, a published privacy policy, accurate data collection disclosures, and account deletion available from within the app if users can create an account in it. Apps that are essentially a wrapper around a website get rejected by Apple with some regularity. Permission requests must explain themselves in specific terms rather than generically. We prepare the submission package properly, so first submissions usually pass and rejections come back in days rather than weeks.
Native becomes the right call in specific circumstances rather than as a general preference.
Notifications, permissions and not getting switched off
Push notification is the main reason many organisations want an app at all, and it is the capability most often squandered. Both platforms now require permission, users grant it based on the first request they see, and once denied it is difficult to recover. Asking on first launch, before the person understands what the app does, is the reliable way to lose the channel permanently.
More on notifications, permissions and not getting switched off
We design the permission moment deliberately: request it when the value is obvious, such as immediately after a booking is made or a job is assigned, with a short in app explanation first so a decline does not consume the real system prompt. Notifications are then segmented and rate limited, because the fastest route to an uninstall is three marketing messages in a week to someone who wanted delivery updates. The same care applies to location, camera and contacts, where the platform requires a written justification that users read. Where notification content is driven by a marketing calendar rather than an event, it belongs alongside SMS and email automation in one contact strategy rather than being decided separately by whoever has access to the console.
How the engagement runs
Releases, versions and users who never update
Shipping to the web means everyone is on the current version within seconds. Mobile app development does not work like that. A meaningful share of your users will be running a build from eight months ago, on an operating system two versions behind, and they will contact your support desk about a bug you fixed in March.
- 01Stage 1Store accounts opened under your business, with your organisation as the developer of record
- 02Stage 2Automated build and code signing pipeline configured before the first internal release
- 03Stage 3Internal testing builds distributed to your team every fortnight from early in the project
- 04Store listing preparedScreenshots per device size, description, privacy disclosures and demo credentials
- 05Stage 5Submission to both stores with review lead time built into the launch date
- 06Stage 6Staged rollout on Android and phased release on iOS, with crash rates monitored at each step
- 07Stage 7Post-launch monitoring of crash free sessions, adoption of the new version and store reviews
Two decisions on your side that keep the project moving
So the release process has to be built rather than improvised. We set up automated builds and signing, distribute test versions through TestFlight and Google Play internal testing, and use staged rollout so a new Android release reaches a small percentage first with crash rates watched before it goes wider. Remote configuration lets features be switched on or off without a store submission, which is valuable when something misbehaves. A forced update mechanism handles the case where an old client can no longer safely talk to the backend, and the API is versioned so it does not have to be used often. Crash reporting with source maps tells you what actually broke rather than what users guessed at, and we treat the crash free session rate as the health metric that matters.
Choose the right level
Cross-platform or native, decided from your feature list
The cross-platform debate in mobile app development is stale, because the answer is now mostly settled by what the app does. Modern cross-platform frameworks render native components and perform indistinguishably for the large majority of business applications: forms, lists, maps, camera capture, payments, push notifications, offline storage. If that describes your app, building it twice is spending double for no user visible benefit.
Approach
01
Cross-platform, one codebase
Suits
Business apps, portals, booking, field tools, loyalty and commerce
The trade off
A small number of platform specific behaviours still need native code
02
Two native codebases
Suits
Graphics heavy products, sustained background work, platform led feature adoption
The trade off
Roughly double the build cost and double every future change
03
Progressive web app
Suits
Content and simple transactions where install friction is the main barrier
The trade off
Weaker device access, no store presence and limited notification support on iOS
04
Cross-platform with native modules
Suits
Mostly standard apps with one or two demanding features
The trade off
You need a team comfortable in three environments rather than one
How we work this out during scoping
Native becomes the right call in specific circumstances rather than as a general preference. Heavy real time graphics or games. Continuous background processing such as sustained location tracking or audio. Deep integration with platform features that arrive first on native. Very tight performance requirements on older devices. Or a product where the app is the entire business and you intend to employ platform specialists anyway. We assess against the actual feature list rather than a preference, and if only one platform matters we will point you at a native iOS build or a native Android build instead.
The ongoing cost that first year budgets always miss
Mobile app development does not end at launch. A mobile app is a subscription to maintenance whether you plan for one or not. Apple and Google each ship a major operating system release annually, both periodically raise the minimum requirements for submitting an update, and both change policies that can require code changes with a deadline attached. An app left untouched for two years is usually broken, sometimes removed from sale, and always more expensive to revive than it would have been to maintain.
Budget for a maintenance allocation from launch
Budget for a maintenance allocation from launch. It covers framework and dependency updates, testing against new operating system versions each spring and autumn, responding to store policy changes, renewing certificates and provisioning profiles before they expire, and a modest amount of improvement work. Certificates in particular cause avoidable outages, because an expired signing credential is discovered at the worst possible moment. We also keep the developer accounts in your name so renewals never depend on an agency relationship continuing.
When you should not build a mobile app
The blunt test is whether people will use it more than once a month. An app used less often than that gets deleted when someone runs out of storage, and you will have paid for a build plus ongoing maintenance to reach an audience that shrinks every quarter. Occasional use belongs on the web.
Many other organisations do not, and we would rather say so during scoping
If the requirement is a mobile friendly version of your website, that is responsive web development and it costs a fraction as much. If the barrier is install friction for a simple transactional experience, a progressive web app gives you home screen presence and offline capability without store review, though notification support on iOS remains weaker. If field staff need to submit forms and photos, a mobile optimised web application is often enough. Build a native or cross-platform app when you genuinely need offline operation, reliable push, camera or sensor access, background behaviour, or when frequent use makes an icon on the home screen commercially valuable. Fitness studios, transport operators and retailers with loyalty programmes usually clear that bar. Many other organisations do not, and we would rather say so during scoping.
How we scope it
Four ways to scope your Mobile Apps project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Discovery build
A scoped build with the architecture settled first
Fixed written quote, agreed before work starts
- Cross-platform codebase covering iOS and Android
- Automated build, signing and distribution pipeline
- Store listings with screenshots, copy and privacy disclosures
Product build
A working product your customers or staff use daily
Fixed written quote, agreed before work starts
- Everything in Discovery build
- Push notification infrastructure with segmentation
- Offline behaviour and data sync where the workflow needs it
- Crash reporting and analytics wired to real events
Platform build
A platform with SSO, audit trails and a security review
Fixed written quote, agreed before work starts
- Everything in Product build
- Staged rollout and remote configuration
- Developer accounts registered to your business
- Release runbook and maintenance schedule
Product care
A named engineer, a roadmap and real service levels
Rolling monthly, quoted in writing
- A named engineer rather than a ticket queue
- A roadmap you set, worked through each month
- Dependency patching, monitoring and incident response
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
How long does it take to build a mobile app?
Most cross-platform apps run 12 to 24 weeks from kickoff to published, including store review time. A focused app with a clear feature set and an existing backend sits at the shorter end. Building the backend at the same time, supporting offline use, or integrating with payment and identity systems pushes it longer. We build store review lead time into the launch date rather than treating it as a formality.
What drives the cost of a mobile app?
The number of distinct screens and user roles, whether the backend already exists, offline requirements, and how many device capabilities are involved such as camera, location, biometrics or payments. Store submission and the release pipeline are fixed costs that apply regardless of size. We quote in writing after scoping, and separately note the annual developer programme fees you pay to Apple and Google directly.
Who owns the app and the store listings?
You do. The Apple Developer and Google Play accounts are enrolled under your business with your ABN, so the app is published by your organisation and stays with you regardless of who maintains it. The codebase sits in your repository. We are added as team members with access you can remove. An app published under an agency account is a hostage situation and we do not work that way.
What happens if Apple or Google rejects our app?
We handle the response. Most rejections cite a specific guideline and are resolved with a change and a resubmission within a few days, and we prepare the submission to avoid the common causes in the first place. Where a rejection reflects a genuine conflict with a business model, such as a monetisation approach Apple will not permit, we would rather identify that during scoping than at submission.
Can the app work without a mobile signal?
Yes, and this is worth planning properly if your staff work in regional areas, basements or warehouses. We store data locally, queue actions taken offline and sync when connectivity returns, with defined handling for conflicts when two people changed the same record. The interface tells the user what is pending rather than pretending everything saved. It does add build time, so we confirm early whether you genuinely need it.
Can you take over an existing app from another developer?
Frequently. We start with a paid review of the codebase, dependency currency, build process and store account access, then give you a written assessment. The common findings are outdated frameworks blocking new submissions, no automated build, and accounts still controlled by the previous developer. Sorting out account ownership is usually the first job and occasionally the most tedious one.
Related services
Find out whether you need an app at all
Tell us who the users are and how often they would open it. We reply within one business day with a straight answer and, if it is a fit, a fixed written quote.