Flutter App in New Zealand

What Flutter actually does differently

Most cross-platform frameworks translate your code into the platform's own interface components. Flutter does not — it draws every pixel itself, using its own rendering engine.

That has real consequences, in both directions.

In your favour: the app looks and behaves identically on both platforms. A distinctive design survives intact rather than being reinterpreted by two different systems. Animation is smooth and performance is consistent, because nothing is being translated.

Against you: nothing is free from the platform. New iOS or Android interface conventions arrive when Flutter implements them, not on launch day. And an app built without care feels subtly foreign on one platform, because the conventions have to be chosen deliberately rather than inherited.

The staffing question matters more than the framework

Flutter uses Dart. It is a pleasant, straightforward language, and there are fewer people writing it in New Zealand than there are writing JavaScript.

That is not an argument against Flutter. It is an argument for asking the question early:

• Who at your firm works in Flutter, and how many of them?
• If we parted ways, who else in New Zealand could pick this up?
• Are they here, or offshore?

Businesses that already run a React web application often find React Native the easier answer purely because it shares a talent pool. Businesses with no existing web team, or with a strong design, frequently find Flutter the better one. Both are defensible; only one of them is defensible for your situation, and the answer usually comes from who maintains it in year three.

Design for each platform even with one codebase

Flutter ships both Material and Cupertino widget sets precisely because the platforms differ, and a good team uses them appropriately.

The details that make an app feel native:

• Navigation — where the back action lives, and whether the edge swipe works.
• Date and time pickers, which look quite different on each platform.
• The share sheet and system dialogs.
• Scroll physics, which iOS users notice without being able to name.
• Typography and spacing conventions.

Ask to use an app the firm has shipped, on an iPhone specifically. Apps built Android-first and shipped unchanged to iOS are the common failure here, and it is obvious within thirty seconds of holding one.

Check the plugins you will depend on

Flutter reaches camera, Bluetooth, biometrics, payments and everything else through plugins. The ecosystem is good and uneven: some are maintained by Google, some by companies, some by one person who has since moved on.

An abandoned plugin becomes your problem at the next OS release, and fixing it means writing native code — which is exactly the work you were trying to avoid.

Ask for a list of the plugins the app will rely on, who maintains each, and what happens if one is abandoned. It is a five-minute conversation during quoting and an expensive discovery in year two.

Offline is a design decision, not an afterthought

If the app is going into a van, onto a farm, into a basement or out of coverage, it will lose signal. Flutter handles offline work well, and none of it happens by default.

Settle during quoting:

• What can the user still do with no connection?
• Where is that data stored on the device, and is it encrypted?
• What happens when signal returns and two people edited the same record?
• What does the user see while it catches up?

Offline-capable is materially more expensive than online-only, and it is the difference between an app your field staff use and one they abandon in week three.

Do not let it build your website

Flutter can target the web, and for a public site you should decline. It renders to a canvas, which makes text selection, search indexing and screen reader support worse than ordinary HTML.

For an internal tool or a dashboard behind a login, where nobody needs to find it on Google, it is a reasonable way to reuse a codebase. For your marketing site, ask how the pages will be indexed — the answer will end the conversation.

Own the store accounts, and budget for year two

Apple and Google developer accounts go in your company's name, on your card, with your agency added. Set the Apple one up early; verifying a New Zealand company can take a fortnight.

Then budget 15 to 25 percent of build cost annually. iOS ships a major version every September, Google raises its minimum API level every year, Flutter itself releases regularly, and plugins need updating. An app untouched for two years usually needs real work before it will pass review again.

Comparing five quotes

Read for:

• Whether the backend is in the quote or assumed to exist.
• Who could maintain the codebase if you parted ways.
• Which plugins it depends on and who maintains them.
• Whether offline behaviour is specified or hand-waved.
• The year-two figure, and what it covers.

Describe who uses the app, on what device, in what conditions, and the three things they must be able to do. Firms who ship Flutter regularly will ask about signal and about your design before they ask about screens.