Mobile app developers for Darwin businesses

A cross-platform app shares most of its code across iOS and Android. It suits products built around accounts, forms, bookings, payments, maps or content. We usually use React Native, which renders each platform’s own interface components. It gives your app a shared codebase, with native modules where a feature needs them. Some logic can also be shared with a React web app.

Flutter is another cross-platform option. It draws its own interface, so it suits a heavily branded app whose screens need to look identical across both platforms. Your team will need to work in Dart. A progressive web app is another route for a staff tool: it skips store review, though it will not appear in the app stores unless packaged for them. On iPhone, it can only request notification permission after someone adds it to the Home Screen.

The right choice starts with the work the app needs to do. We learn about your business, audience and goals, then agree the scope with you before design begins.

Australian guidance recommends WCAG 2.2 at a minimum of Level AA for equal access to digital goods and services. We use that target when setting up the app’s screen designs and flows, so accessibility is part of the design work.

The removal of surcharging on debit, prepaid and credit card payments across the eftpos, Mastercard and Visa networks affects checkout settings. We set up the checkout without those card surcharges and include the payment flow in the build.

Bring what you know about the tasks, systems and accounts involved.

• First releaseList the actions users must complete, in the order they will do them.
• Existing systemsNote your website, CRM, booking or payment software, whether each has an API, and who holds admin access.
• Staff tasksNote who will edit content, look up customers, issue refunds or block abusive accounts.
• Developer accountsStart registering Apple and Google accounts in your company’s name; organisation verification needs a D-U-N-S number.
• TestingFor a new personal Google Play developer account, plan a closed test with at least 12 testers opted in for at least 14 days.

• !

  Wrapping a website in an app shell

  Give people useful app functionality beyond the existing site, since a repackaged website risks rejection.

• !

  Putting sign-up first

  Let people see and use the app before login when it has no significant account-based features.

• !

  Asking for notifications at launch

  Ask when the benefit is clear, such as after an order. On Android 13 and later, users must allow notifications before they are enabled.

• !

  Adding an SDK without updating privacy answers

  Include data collected by third-party SDKs in Google Play’s Data safety form.