Intunio builds cross-platform apps in Flutter — one codebase for iOS and Android, with design and engineering in the same team.
Intunio is a design and development studio in Gothenburg. When an app needs to reach both iOS and Android with one team, one design foundation, and a shared release cadence, Flutter is often the right call — and a framework we've shipped several products with.
Flutter development here is part of our app development: the same way of working, where designers and engineers share the backlog, but focused on when and how one codebase ships to two platforms without feeling like a compromise.
The platform choice is often the most consequential decision in an app project. Flutter fits when speed, a shared design foundation, and one codebase outweigh perfect platform-specific feel:
You need to reach both iOS and Android but don't want to maintain two separate codebases and two teams.
Design is load-bearing — Flutter renders its own UI, giving pixel-exact control and an identical expression on both platforms.
Release cadence and iteration matter — hot reload and a mature component toolkit let design and function develop quickly and in parallel.
The product has complex, custom interactions (animations, real-time views, graphics) where Flutter's rendering model is a strength.
Flutter is less right when large parts of the product are pure native platform functionality, or when an existing web team already lives in React — then we look at native or React Native instead. How the choice is made in practice is covered in Native vs. cross-platform.
AI has shifted the calculus toward native. When even native development becomes efficient with AI tools, the old time savings of a shared codebase shrink, so for new apps we increasingly land on native — because it delivers the best result. Flutter is still right when speed and a shared design foundation matter most.
One codebase, two platforms. Shared logic, shared components, and a common design foundation — without losing the platform feel where it counts.
Its own UI toolkit. Flutter draws its own components, giving full control over the expression and making a design system directly translatable to code.
Fast iteration. Hot reload shortens the loop between a design decision and a working interface — valuable when design and engineering work in parallel.
Embedded targets. We've used Flutter beyond mobile, on embedded screens where it's one of the few realistic options — relevant for connected products and vehicles.
Strong performance for animation- and interaction-heavy interfaces.
A few of the products we've built in Flutter:
[Swanholm Technology](/en/projects/swanholm-technology) — companion app for a smart safety vest. We rebuilt the app in Flutter for iOS and Android as it scaled, with Bluetooth integration and AI-controlled alert features tied to the hardware.
[RGNT Motorcycles](/en/projects/rgnt) — companion app for Swedish electric motorcycles, a cross-platform update in Flutter with extended mapping (HERE) and an improved dashboard.
Both are cases where the app is the interface to a connected, physical product — one of the situations where a single codebase and tight hardware integration have to coexist.
A Flutter project follows the same setup as our app development: pre-study, design and technical foundation, sprint-based development, release and maintenance — with designers and engineers in the same team. We often start with a pre-study that lands scope, architecture, and whether Flutter really is the right call before a line of code is written. The design system is built into the foundation, which Flutter suits particularly well since the UI is rendered by the framework itself.
Both are cross-platform with one codebase, but they differ fundamentally. Flutter draws its own UI, giving pixel-exact control, strong performance, and an expression identical on iOS and Android — good when design and interaction are load-bearing. React Native uses the platform's own components and has tighter ties to the web stack — good when an existing React/web team will maintain the app. We make the call with you based on product, team, and release cycle; Native vs. cross-platform walks through the reasoning.
Yes. Flutter's rendering model — where the framework draws every pixel — makes it strong for animation- and interaction-heavy interfaces, real-time views, and custom graphics. It's one reason we've chosen Flutter for products where the interface to a connected device needs to feel alive and responsive.
Yes. We often come in mid-flow — into an existing Flutter codebase for continued development, a rebuild, or as a complement to your team. When a first version already exists, we like to start with a product validation that maps the current state before we build on.
Yes. Intunio is based on Korsgatan 24 in central Gothenburg. For clients in Gothenburg and Western Sweden, proximity is part of the collaboration — workshops and check-ins often happen on-site. We also work with clients across Sweden, Europe, and North America, where Flutter development works well fully remote.
Get in touch with us at Intunio, and we'll take it from there.