Mobile app development company in Auckland

Cross-platform development shares most of the code between iOS and Android. It suits apps built around accounts, forms, lists, maps, bookings, payments or content. We usually use React Native, which renders each platform’s own interface components. We add native modules when a feature needs them, while keeping the shared codebase for the rest of the app.

Flutter is another cross-platform option. It draws its own interface, which suits a heavily branded app where screens need to look identical across both platforms. Your team would need to work in Dart. The choice affects who can maintain the code and how the interface is built.

Native development uses Swift for iPhone and Kotlin for Android. It fits deep device features, heavy graphics, complex background work or a need for new platform features at launch. The trade-off is maintaining separate codebases. Start with the features your users need, then choose the approach that supports them without adding unnecessary work.

New Zealand’s Privacy Act sets principles for collecting, storing, using and sharing personal information. When your app collects customer details, we set up the accounts, data and admin tools behind it and plan what information each part needs to use.

For a business selling physical goods or services, we can set up a card checkout using Stripe, which supports businesses in New Zealand. Digital content and subscriptions used inside an Apple app need in-app purchase, so the type of sale affects the checkout we build.

A few practical details make the first scope discussion more useful.

• First-release tasksList what users must do, in the order they will do it.
• Existing systemsNote your website, CRM, booking software or payment provider, whether each has an API and who holds admin access.
• Developer accountsRegister Apple and Google accounts in your company’s name and start the D-U-N-S verification process early.
• Privacy policyPrepare one that reflects what the app collects; Apple requires a link in the listing and inside the app.
• Review accessFor an app with login, prepare a working demo account and a live backend for Apple’s review.

• !

  Wrapping a website in an app shell

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

• !

  Demanding sign-up too early

  Let people use the app without logging in when it has no significant account-based features.

• !

  Adding an analytics or advertising SDK without revisiting privacy answers: Update Google Play’s Data safety form to cover data collected by third-party SDKs.