App developers NZ businesses can hire remotely for one iOS and Android codebase

What do app developers in NZ build, and does your business really need an app?

App developers design, code, test and publish software that people install from the Apple App Store or Google Play. For a New Zealand business that usually means one of three things: a customer app (bookings, loyalty, ordering, member content), a staff app (job sheets, inspections, stocktakes) or a startup product where the app is the business.

Before paying any app developers NZ or offshore, ask whether people will open it often. An app earns its keep when customers or staff use it weekly or daily, when it needs the phone's camera, location, push notifications or offline storage, or when a logged-in experience is faster than a browser. If people would visit once a year, a fast mobile website usually does the job for a fraction of the effort. Our comparison of a website or an app for your business walks through that decision.

• Good app candidates: repeat bookings, loyalty schemes, field work with offline needs, subscription content, marketplaces with two sides.
• Weak app candidates: brochure information, one-off purchases, anything customers only look at before their first visit.
• Grey zone: ordering for a single café or shop. A progressive web app may be enough until volume justifies the store fees and upkeep.

If you are unsure, send us a description of who will use it and how often. We would rather tell you to start with a website than build an app that sits unopened on phones in Hamilton and Whangārei.

Remote app developers vs a local NZ app studio: which suits you?

Choose a remote team when your budget is tight, your requirements can be written down, and you are comfortable reviewing work on your phone and giving feedback in writing. Choose a local studio when you need in-person discovery workshops, on-site testing, or a large team moving at once.

The honest trade-off is communication, not code quality. Flutter and React Native are the same frameworks whether they are typed in Newmarket or in India. What changes is that you cannot pop round to the office, and meetings happen on video in a window that suits both time zones. In return you get a lower quote, because salaries and overheads in India are lower, and the time gap means work continues while you sleep.

Among app developers NZ businesses shortlist, local studios often bundle services a startup may not need yet: brand strategy sessions, lengthy discovery phases, dedicated account managers. Those have value for a bank or a government agency. For a founder testing an idea, or a trades business wanting a job-sheet app, they can double the bill without changing the app.

How much do app developers in NZ charge compared with an offshore team?

Quotes from app developers in NZ vary widely, and most studios do not publish rates because scope drives the number far more than the hourly figure. What reliably pushes a quote up is the same everywhere: the number of distinct screens, how many user roles there are, payments, real-time features such as chat or live tracking, integrations with other systems, and how polished the design must be.

An offshore team is usually cheaper for the same scope because the team's cost base is lower, not because corners are cut. With us, a cross-platform app starts at US$600; an app with a meaningful admin portal and integrations starts at US$900. Every quote is itemised so you can see which feature carries which cost and drop items to fit your budget.

• Two native codebases (Swift and Kotlin) instead of one cross-platform codebase: roughly doubles the build effort.
• Custom animations and illustration-heavy design: more design and front-end hours.
• Offline sync with conflict handling: one of the hardest features to get right.
• Integrations with Xero, a booking system or a legacy database: depends on the quality of their APIs.
• Compliance-sensitive data (health, children, finance): more security work and review.

For NZD cost bands by app type, our separate NZ app development cost breakdown goes further. We never quote other providers' prices, because we cannot verify them; ask two or three for itemised quotes and compare line by line.

One codebase, two stores: how cross-platform apps work

A cross-platform framework lets developers write the app once and compile it for both iPhone and Android. Flutter, maintained by Google, uses the Dart language and draws its own interface. React Native, maintained by Meta, uses JavaScript or TypeScript and renders native interface components. Either way, roughly the whole codebase is shared, with small platform-specific pieces for things like payments, notifications and permissions.

For most NZ business apps this is the sensible default. You pay for one set of features, one set of tests and one set of bug fixes, and both stores get updates on the same day. The cases where fully native Swift and Kotlin make more sense are narrow: heavy 3D or augmented reality, deep integration with a brand-new Apple or Android feature on release day, or an existing native codebase you want to keep extending.

Cross-platform does not mean identical. iPhone users expect a back swipe; Android users expect the system back button to work. Date pickers, share sheets and permission prompts look different on each. Good app developers respect those differences instead of forcing one design onto both, and we test on real devices from both families before every milestone.

• Shared: screens, business logic, API calls, validation, most of the tests.
• Platform-specific: push notification set-up, in-app purchases, app icons and splash screens, permission wording.
• Released separately: each store reviews and publishes its own build, usually within days of each other.

Flutter or React Native: which should NZ app developers use for your project?

Pick Flutter when the app has a strong custom look and you want it to render the same on every phone. Pick React Native when you already run a React website or web app and want to share code and developer skills across both. Both are mature, both reach the App Store and Google Play, and both are used by large and small products.

We recommend one or the other after reading your brief, and we explain why in the quote. Our guide to working with a Flutter developer goes deeper, but the practical signals are simple enough to apply yourself.

Whatever we pick, the choice is written into the quote so a future developer, in NZ or anywhere else, knows exactly what they are inheriting.

Who should own the App Store and Google Play accounts?

Your organisation should, always. The developer accounts are where your app lives, where reviews and revenue land, and where updates are published. If they sit under a developer's personal account, you do not truly own the app, and moving it later is slow or impossible.

Apple's own enrolment page says an organisation needs to be a legal entity, have a D-U-N-S Number, use a work email on its own domain, and have a working public website; the Apple Developer Program costs US$99 a year. Google Play charges a one-time US$25 registration fee, and its help centre says organisation accounts verify their legal name and address against the Dun & Bradstreet profile. A NZ limited company can do both; a sole trader can open personal accounts, with limits.

One limit matters for timelines. Google's Play Console help says personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in for 14 consecutive days before they can publish to production. Organisation accounts are not subject to that rule, which is another reason to register as an organisation if you can.

• Apple: you enrol, then invite us as a Developer or App Manager in App Store Connect.
• Google: you create the Play Console account, then invite us with the permissions we need.
• Firebase, analytics and push services: created under your Google account, shared with us.
• Domain and email used for the app: registered to you, never to the developer.

Who owns the code and IP when you hire app developers offshore?

You do, as long as the written agreement says so, and ours does. When you hire app developers NZ-based or overseas, the contract should state that on payment the intellectual property in the custom code, designs and content created for your project passes to your business, and that the source code is delivered continuously, not at the end.

We work in a Git repository created under your GitHub, GitLab or Bitbucket account from the first week, so every commit is already yours. That removes the classic hostage situation where a developer holds the final build until a disputed invoice is paid. Third-party packages keep their own open-source licences, which we list in the handover notes, and any paid component is bought in your name.

If you want a mutual non-disclosure agreement before sharing your idea, send yours or ask for ours; the specific terms are agreed in writing with the quote. Our terms page covers how we handle project agreements, and anything specific to your project is written into the quote itself.

• IP assignment clause covering code, designs and written content made for you.
• Repository in your account, with our access removable at any time.
• A list of third-party packages and their licences at handover.
• Build and signing instructions, so another developer can release an update without us.
• Credentials register: every login the app depends on, held by you.

The daily build cycle: feedback in your NZ morning, fixes by the next

The time difference works in your favour if the routine is set up well. New Zealand is six and a half hours ahead of India during NZ standard time and seven and a half hours ahead during NZ daylight time, so our working day runs through your afternoon and evening, and a new test build is usually on your phone before you start work.

In practice the loop looks like this. You open the latest build over breakfast, try the new screens and write feedback in the shared tracker or on WhatsApp with screenshots. We pick it up when our day starts, which lands in your early-to-mid afternoon, and there is a short window to clarify anything by message or a quick video call. Fixes and the next feature land overnight your time.

iPhone builds are shared through Apple's TestFlight and Android builds through a Google Play internal testing track, so testers install them like normal apps. You can add staff or friendly customers as testers without them needing to understand anything technical.

• Morning (NZ): install the new build, test, write feedback with screenshots.
• Early afternoon (NZ): our day starts; questions answered by message.
• Afternoon (NZ): optional 20–30 minute video call on milestone days.
• Overnight (NZ): fixes and the next feature built, tested and uploaded.

Weekly, you get a short written summary: what shipped, what is next, anything blocked waiting for you. That paper trail is also useful if you ever change developers.

Milestone billing for NZ clients: USD quotes, NZD accounts

Quotes are itemised and written in USD, and you pay from your NZD bank account by Wise, bank wire or PayPal. Payments are tied to milestones you can see and test, so money always follows working software rather than promises.

A typical split for an app from US$600 is a first payment once the quote is approved in writing, a second when the clickable design and first working build are on your phone, a third when all agreed features are in the test build, and the last when the app is accepted by both stores. The exact percentages are agreed in your written quote, and nothing is billed before that approval.

Invoices come from India, and we cannot advise on how GST or tax applies to services you import; your accountant can, using Inland Revenue guidance. Store fees, cloud hosting and paid third-party services such as SMS or maps are billed to you directly by those providers, so there is no hidden mark-up inside our quote.

• Milestone 1: approved quote and kickoff.
• Milestone 2: design screens and first installable build.
• Milestone 3: feature-complete build in TestFlight and Play testing.
• Milestone 4: live on the App Store and Google Play, handover delivered.

How do you vet app developers in NZ or offshore before signing?

Ask for evidence you can check yourself and a quote you can read line by line. Good app developers will happily show you apps they worked on in the stores, explain their testing approach, and put ownership terms in writing before you pay anything.

Use this checklist on every shortlist, including us. It works equally well for app developers NZ studios employ and for freelancers on marketplaces such as Upwork or Fiverr, where profiles and reviews are a start but not proof of who wrote the code.

• Can they show live apps in both stores and explain their own part in each?
• Is the quote itemised by feature, with a timeline per milestone?
• Will the store accounts and code repository be in your name from week one?
• Who will actually write the code, and can you talk to that person?
• How do they test: real devices, automated tests, or just the simulator?
• What happens after launch: free fix period, then what does ongoing care cost?
• How do they handle your customers' personal information during development?

Red flags: a quote with no breakdown, pressure to pay most of the budget up front, reluctance to share the repository, a store account in the developer's name, or a promise that the app will be "just like Uber" for a price that cannot cover it. Our list of questions to ask an app developer adds more.

Where your app's data lives, and the Privacy Act 2020

Most business apps need a backend: a database, user accounts, file storage and an API. We usually build on Firebase or Supabase for simpler apps and a Node.js or Python API on AWS or Google Cloud for heavier ones, deployed to a Sydney or Melbourne region when you want data close to New Zealand. All of these accounts are opened in your name.

Personal information needs more thought when an offshore team can see it. The Privacy Commissioner's page on information privacy principle 12 explains that a NZ agency may disclose personal information overseas only on grounds such as the recipient being subject to comparable safeguards, contractual clauses that provide them, or the individual's authorisation after being told. We keep this simple by working with test data during development and asking for production access only when a fault genuinely needs it.

• Test and staging databases filled with made-up records, not real customers.
• Role-based access, so each staff member sees only what their job needs.
• Encryption in transit and at rest, using the hosting provider's built-in options.
• Audit logs on admin actions for apps that hold sensitive data.
• Collect only the fields the app actually uses.

Whether your app meets its Privacy Act obligations is your organisation's call, confirmed by your own adviser or lawyer. Our job is to build the controls in and document them clearly.

Getting through App Store review and Google Play's Data safety form

Both stores review apps before they go live, and both ask you to declare what data the app collects. Planning for this from the first week avoids the most common rejections and last-minute delays.

Google Play's help centre says nearly every app must complete the Data safety section, disclosing what user data it collects or shares, including data gathered by third-party SDKs, and that even apps collecting nothing must fill it in and link a privacy policy. Apple asks for similar privacy details in App Store Connect. We prepare draft answers from the actual code and packages used, and you confirm them, because the declaration is made by your organisation.

Typical rejection reasons we design around: login walls with no demo account for reviewers, broken links, placeholder content, asking for permissions without explaining why, and apps that are just a website wrapped in a frame. If an app of yours has already been bounced, our page on fixing a Google Play rejection covers the usual fixes.

• A reviewer demo account with sample data.
• A privacy policy URL on your own domain.
• Clear permission prompts explaining why the camera or location is needed.
• Account deletion available from inside the app where the stores require it.
• Screenshots and descriptions that match what the app actually does.

Store fees and commissions NZ app owners should budget for

Beyond the build, three kinds of cost recur: developer account fees, store commission on digital sales, and running costs for the backend. None of them go through us; you pay the providers directly.

Apple's Developer Program is US$99 a year and Google Play registration is a one-time US$25. On commission, Apple's Small Business Program page says developers with up to US$1 million in proceeds in the prior calendar year, and new developers, qualify for a reduced 15% commission on paid apps and in-app purchases. Google's help centre lists a 15% service fee on the first US$1 million a developer earns each year for markets outside the EEA, UK and US, where a different structure applies.

The commission applies to digital goods sold inside the app, such as subscriptions to premium content. Physical goods and real-world services (a booked massage, a delivered pizza, a tradie's call-out) are generally paid through a normal card checkout instead. Getting that distinction right in the design stage can make a large difference to your margins, so we flag it in the quote.

• Apple Developer Program: yearly, paid by you.
• Google Play registration: once, paid by you.
• Backend hosting, push notifications, SMS and maps: monthly, usage-based, billed by each provider.
• App care after the free months: from US$120/mo with us, optional.

After launch: why apps need care that websites often do not

Apps need regular updates even when you add no features, because Apple and Google release new operating system versions every year and periodically raise the minimum requirements for apps they will accept. An app left alone for a couple of years can stop installing on new phones or be hidden from the store.

Every app we build includes two months of free maintenance after launch: crash fixes, compatibility patches and small adjustments. After that, care starts at US$120/mo and covers framework and package upgrades, store policy changes, crash monitoring and small content edits. You can also pause care and bring it back when you plan the next version; the code is in your repository either way.

• Crash and error monitoring checked weekly.
• Flutter or React Native upgrades tested on real devices before release.
• Store policy and target API level changes handled before deadlines.
• Security patches for backend packages.
• A short monthly note: what changed, what is coming.

More detail on what that looks like month to month is on our mobile app maintenance page.

Getting your app found: store search, Google and AI answers

Publishing an app does not mean anyone will find it. Discovery comes from three places: the stores' own search, Google results for your brand and category, and increasingly AI assistants that answer questions like "what's a good app for booking a physio in Christchurch".

Inside the stores, the app name, subtitle, keyword field on Apple, short description on Google, screenshots and ratings all matter. We write draft listings in NZ English, set up screenshots for each required device size, and prompt happy users for a rating at a sensible moment rather than on first launch.

Outside the stores, a fast landing page on your own domain does the heavy lifting. It should explain what the app does in plain sentences, answer common questions, carry app store badges and structured data, and be the page Google and AI engines quote. For ongoing work on that side, see our SEO services for NZ businesses. Nobody can guarantee a ranking in either the stores or Google, and we will not pretend otherwise.

Worked example: a hypothetical Wellington sports-club rostering app

This scenario is invented to show how a project typically unfolds; it is not a past client. Say a Wellington founder wants an app that lets community netball and football clubs roster volunteers, swap shifts and send reminders, starting with five clubs she already knows.

Week one, she sends a two-page brief and sketches on paper. We reply with questions (Do clubs pay? Do parents need accounts? Does it work offline at grounds with poor signal?) and then an itemised quote starting from the US$600 app plan: sign-up, club and team set-up, a roster screen, shift swaps, push reminders, a light admin web page and store submission. We recommend Flutter because there is no existing web app and the design matters.

Weeks two to three, she opens her Apple and Google organisation accounts under her limited company and creates the Git repository. Clickable screens arrive; she tests them with two club coordinators. Weeks four to eight, a build lands most mornings. The coordinators find the swap flow confusing, so we simplify it to two taps. Weeks nine and ten, the reviewer demo account goes in, both stores approve, and the five clubs start using it.

Payments to clubs and a web dashboard for regional associations are held for version two, quoted separately once real usage shows which matters more.

Working with app developers in India from New Zealand: the first two weeks

You talk directly to the three people building your app, mostly in writing, with video calls in the overlap between your afternoon and our morning. Here is what the first fortnight usually looks like once you have sent a brief.

One of us leads the Flutter or React Native build, another of us handles cloud hosting, AI features and data, and the third of us manages the plan and your updates. We work in English (and Hindi, if that suits anyone on your team). There are no site visits, so anything physical, such as hardware testing, stays on your side.