Flutter development services

Flutter is the framework we use for iOS and Android applications. Field staff and customers use an app that calls the same Laravel API as the web portal, so business rules stay in one place rather than being copied into the mobile client.

Start a conversation about a mobile application, or read Project initiation.

At a glance

When we use it

We use Flutter when the work is done on a phone or tablet, and a desktop browser is not a practical interface.

• Staff who record jobs, stock, or signatures away from the office
• Customer applications for orders, status, and account tasks, where a mobile application is more suitable than a responsive website
• One codebase for the App Store and Google Play, when the interface does not require extensive native platform features
• A mobile client for a platform that already has a web portal, so both use one API

A marketing site, or a form used only on a desktop, is built with Nuxt.

What we rely on

• Screens organised around the process, rather than a generic starter project
• The same API contract as the web client, including error responses
• Secure storage for tokens. Secrets are not included in the application binary
• Defined behaviour when the network is unavailable, the application is in the background, or an installed version is behind the API
• Release through the app stores, with a versioning approach that later releases can follow

Why it fits the work

• One codebase for iOS and Android. Both stores are served from one Dart project. This is suitable when the interface can be delivered in Flutter.
• Responsive lists and forms. Those screens are compiled, which keeps them responsive on typical mobile devices.
• Security remains on the server. The application is a client. Authentication, permissions, and data rules remain in Laravel, where they are tested once.
• Lower cost than two native applications. Separate iOS and Android teams are appropriate when the product requires them. For most operational applications, one codebase is more practical to maintain after the first release.

How we build with it

The engagement follows Project initiation. On a Flutter project, that work includes the following.

• Architecture. Which screens are required, what they should do offline, and which calls belong to the shared API. Mobile scope is included in the first release.
• Development. Models that match the API, and tests for conditions that occur in the field: an unreliable network, an interrupted capture, and an expired session.
• Hardening. Secure token storage, expected certificates, and no privileged logic that exists only on the device. Store listing and signing are part of the build.
• Release and support. A path for the next version. A mobile application that cannot be updated becomes difficult to support. The API remains compatible with versions already installed on users’ devices.

How it sits in the stack

Flutter is a client. Laravel holds the business rules, and MySQL holds the records. Nuxt is often the desktop portal alongside the application. AWS runs the API. Cloudflare provides the edge in front of it.

The application does not connect to the database, and it does not contain a separate copy of the pricing rules.

In practice

The mobile application and the web portal should use the same definitions for an order, a job, or a customer. We build Flutter against that shared backend. The application is specified for the process it has to support. It is not a generic store listing added after the web application is finished.

Questions

Is Flutter suitable when we also need a web portal?

Yes, when both are clients of one API. Nuxt provides the web portal. Flutter provides the mobile application. Business rules belong in the API. If they are implemented in either client, the two interfaces diverge.

What about offline use?

Some field work has to continue on a poor connection: capture the data, then synchronise when the network returns. That behaviour is specified at the start. It is not added after the online application is complete, and it does not mean every screen works without a connection.

Do you publish to the App Store and Google Play?

Yes. Accounts, signing, store review, and the update after launch are part of delivering a mobile application. A build that runs only on a developer device is not a finished release.

Next step

If the process has to run on a phone or tablet, the API and the application should be scoped together. Start a conversation.

Related: Laravel, Nuxt, Technology.