App development, starting with whether you need an app at all
Most businesses that ask for an app need a faster website. The ones that genuinely need an app usually know why, and it is rarely marketing. This category covers the build types, what each one costs you in maintenance, and how to tell them apart.
In short
App development covers native iOS and Android builds, cross platform apps built from one codebase, and progressive web apps that install from a browser without an app store. Australian businesses commission native work when they need camera, background location, offline use in the field or push notifications at scale. Everything else is usually better served by a responsive site or a progressive web app, which avoids app store review entirely.
Android Apps
Native Kotlin apps optimised for the device fragmentation your users actually have.
Read moreApp Design
Product design for iOS, Android and web apps, from information architecture through to a build-ready UI kit.
Read moreMobile Apps
Cross-platform apps from a single codebase, native performance, half the maintenance.
Read moreProgressive Web Apps
Installable, offline-capable web apps that feel native without an app store.
Read moreiOS Apps
Native Swift apps built to Apple guidelines and shipped through App Store review.
Read moreDo you actually need an app?
The honest test is whether the thing you want needs the device, not the browser. Background location for a driver, a camera used offline in a warehouse, Bluetooth to a piece of equipment, or push notifications that people will actually keep switched on. If your list is content, forms, bookings and a login, a good mobile site does all of it, costs less, and nobody has to install anything.
Where the device matters but the audience is small, a progressive web app sits in between. It installs to the home screen, works offline, and sends push on both platforms, without an app store review cycle standing between you and a bug fix. It cannot do everything native can, and we will tell you when you have reached that line rather than after you have paid for it.
Native, cross platform, or both
Cross platform development builds iOS and Android from one codebase. For most business apps this is the right default: one team, one set of bugs, roughly half the ongoing maintenance of two native builds. The trade is that anything unusual at the device layer needs native code written alongside it, which erodes the saving.
Native iOS and native Android make sense when performance, device integration or platform conventions are the product rather than a detail. Two codebases means two of everything afterwards, so it is a decision worth making deliberately. App design runs ahead of either path, because an app is judged in the first thirty seconds and there is no second visit to recover in.
What happens after it ships
An app is not finished when it is approved. Apple and Google both change their requirements on their own schedule, and an app that is not rebuilt against the current SDK eventually stops being accepted. Budget for a release every few months whether or not you have new features, because the alternative is a large forced rebuild in two years.
You get the source code, the signing certificates and the store accounts in your own name. Store accounts registered to an agency are the single most common reason a business cannot move developer, and we will not set yours up that way.
Questions buyers usually ask
Frequently asked questions
Ownership and handover
Who owns the App Store and Play accounts?
You do. They are registered to your business, with your billing details, and we are added as a developer. Accounts registered to an agency are the most common reason a business finds it cannot change developer without republishing from scratch and losing its reviews and ranking.
What does it cost to keep an app running after launch?
There is a floor you cannot avoid: the annual Apple developer fee, the one off Google fee, and a release every few months to stay compatible with current operating systems and store requirements. On top of that sits whatever changes you want. We quote the ongoing scope in writing alongside the build rather than leaving it as a surprise.
Detail and edge cases
How long does an app take to build?
A first release that real people can use is typically 10 to 20 weeks for cross platform, longer for two native codebases. The variables that move it most are integrations with systems you already run, offline behaviour, and whether payments happen inside the app, since both stores have their own rules about that. Store review adds days, not weeks, unless something is rejected.
Should we build native or cross platform?
Cross platform unless something specific rules it out. One codebase means one set of bugs and roughly half the maintenance. Rule it out when the app leans hard on device capability, when performance is the product, or when platform specific interface conventions matter more than shipping to both at once. We work through that in a scoping call rather than defaulting to whichever is easier for us.
Do we need an app if we already have a good website?
Often not, and we would rather say so early. If the requirement is content, forms, bookings or an account area, a responsive site does it without asking anyone to install anything. An app earns its place when it needs the device itself, or when it is used often enough that a home screen icon changes behaviour.
Can you take over an app someone else built?
Usually yes, and the first step is a short review of the code, the dependencies and the store accounts before anyone promises anything. What decides it is whether the codebase is current enough to build against today's SDKs. If it is three or four versions behind, rebuilding parts of it can be cheaper than untangling it, and we will say so with reasons rather than as a sales position.
Not sure whether you need an app or a better website?
Tell us what people are trying to do and where it breaks today. We will tell you which of the two solves it, in writing, including when the answer is the cheaper one.