Mobile App Development

It depends on your requirements, timeline, and budget. Native gives you the best platform performance and access to the full range of platform APIs, but means two codebases to maintain. Cross-platform with React Native reduces that overhead and is the right call for most projects. We will give you our honest view on which fits your situation based on what you are building.

A focused first version is typically a few months; a fuller product with a backend and several integrations runs longer. We work in sprints with builds you can install as we go, so you see progress continuously rather than waiting for one reveal at the end.

Yes. We set up your developer accounts if needed, manage the submission process, and handle reviewer feedback. App Store review can be unpredictable, so we build submission time into the project plan rather than treating it as a formality at the end.

Yes, if the job needs it, and we decide that at scoping rather than discovering it on site. An offline app stores the data a person needs for the day on the phone, lets them keep working without signal, and sends their changes when the connection returns. The hard part is not storing data, it is deciding what happens when two people change the same record while one is offline. We agree those rules with you up front, such as the office's change winning or the latest change winning, and test them on real devices in flight mode, in lifts and at the edge of coverage before launch.

A rejection usually means a few days of changes and a resubmission, not a lost launch. Apple and Google both publish review guidelines, and the common reasons for rejection are predictable: missing privacy disclosures, a login reviewers cannot get past, permissions the app asks for without a clear reason, or a feature that looks like a website wrapped in an app. We design to those rules from the start, give reviewers a test account and notes, and submit a test build early so problems surface before launch week. If a rejection does come, we read the reviewer's notes, fix the issue and resubmit, and we keep that time in the plan.

The yearly running cost of an app is mostly hosting, store fees and the work to keep it current, not the app itself. Apple charges an annual developer fee and Google a one-off one, both small. Hosting for the backend and any third-party services, such as maps, push notifications or text messages, scale with how many people use the app. The larger cost is upkeep: Apple and Google release major OS updates every year, and an app that is not updated starts to break or gets pulled from the stores. We set out these costs at scoping, so the yearly figure is known before you approve the build.

Yes. We do a technical review of the existing codebase first so we both understand what we are working with. Sometimes extending what exists is the right call. Sometimes starting clean is faster and cheaper in the long run. We will tell you which, with a reason.

iOS and Android both release major platform updates annually that can affect how your app behaves. We offer ongoing support agreements that keep your app current, handle OS compatibility updates, and give you a team to call when something needs to change.

Yes. Mobile apps that connect to existing backends, CRMs, or databases are a significant part of what we build. We scope the integration requirements upfront and build the API layer as part of the project, not as an add-on at the end.

Yes. CodeFish Studio is an Adelaide software studio, and the people who scope your app are the people who build it. We work with businesses across Australia: workshops can run in person in Adelaide or online, and the build runs the same way either way.

Yes, outright. The codebase, the repository, and the app store listings are yours, published under your own developer accounts rather than ours. That matters more than it sounds: apps published under an agency account are painful to move later. We set it up your way from the start.

Mobile adds two problems a web app does not have: data sitting on a device you do not control, and app store privacy disclosures. We design for both — sensitive data kept off the device or stored in the platform's secure storage, tokens handled properly rather than cached in plain text, and the permissions your app requests kept to what it actually needs. App store data disclosures are prepared as part of release rather than rushed at submission. Where your obligations require Australian hosting for the backend, we build it that way.