Mobile App Development for Australia

Offline is a requirement, not a resilience feature

Australia is the sixth largest country on earth with a population concentrated along a thin coastal strip, and mobile coverage reflects that geometry. Drive an hour out of most capital cities and connectivity becomes intermittent; go further and it disappears for long stretches. Any app used by tradespeople, agricultural operations, field service teams, logistics, mining, inspections or regional healthcare will spend part of its life with no signal at all.

An app built on the assumption of connectivity does not degrade gracefully in that situation — it fails at the moment of use. A form that cannot submit loses the work. A screen that cannot load shows nothing. A user in a paddock cannot wait for a bar of reception to appear, and the practical result is that the app gets abandoned and the job goes back on paper.

Building for it properly means the local device is the primary store and the server is a synchronisation target rather than the source of truth for the current session. Data is captured locally and queued, uploads retry on their own when connectivity returns, and the interface shows the user honestly what has synced and what has not. That last part matters more than the engineering: a user who cannot tell whether their morning's work has been saved does not trust the app, and an app they do not trust gets used badly or not at all.

Consumer guarantees reach into your subscription flow

Australian Consumer Law applies to digital products, which means the consumer guarantees — that what you supply is fit for purpose, matches its description and is of acceptable quality — apply to your app and to anything sold inside it. They cannot be excluded by your terms and are not displaced by the app store's own refund policy.

For subscription apps this has concrete design consequences. Renewal terms, price and billing period have to be genuinely clear before purchase rather than technically disclosed. Cancellation has to be findable and workable rather than buried behind a support email. Free trials that convert to paid subscriptions need the conversion to be obvious in advance, because a customer surprised by a charge has both a consumer law argument and a chargeback.

There is also a practical wrinkle that catches Australian businesses: the platform handles the billing relationship for in-app purchases, but your customer will still come to you first, and your obligations under the ACL do not disappear because the money was collected by a store. Designing the support path for that — so your team can see what a customer bought and advise them properly — is part of the build rather than something operations discovers in month two.

Whether you should build an app at all

A meaningful proportion of the Australian businesses that come to us asking for an app should not build one, and we would rather establish that in the first conversation than in month four. An app is justified when you need something a good mobile website cannot do: reliable offline operation, hardware access such as sustained GPS or barcode scanning, background processing, or genuinely useful push notifications to an audience that will keep the app installed.

It is not justified by wanting to be on the app store, or by a competitor having one. If your customers interact with you a few times a year, the download is a barrier rather than a convenience, and the app will be installed once and deleted or forgotten. A well-built responsive site reaches everyone immediately, costs less to build and does not need a review process to fix a typo.

The genuine cost people underestimate is not the build, it is the perpetuity of it. An app has to be maintained against two operating systems that release annually, store policies that change without asking you, and library deprecations that force work you did not plan. That is a permanent commitment, and it is worth entering deliberately. Where the case is real — field work, offline requirements, daily use — we will build it and it will be worth it. Where it is not, we will say so.

Questions worth asking any vendor

These apply to us as much as to anyone else bidding for your work.

• Ask what the app does with no signal for two hours. If the answer is a spinner or an error, it will be abandoned by anyone who works outside a capital city.
• Ask what happens when two people edit the same record offline. If the answer is last-write-wins, somebody's work is being silently discarded.
• Ask how sync status is shown to the user. An app that cannot tell you whether your morning's work is saved will not be trusted, however good the sync engine is.
• Ask how the app handles a user in Brisbane and a user in Sydney during daylight saving. Timezone bugs surface to customers, not to test suites.
• Ask the supplier to argue against building an app. If they cannot make the case for a responsive site in any circumstance, they are selling rather than advising.