Intunio builds native apps for iOS and Android — Swift/SwiftUI and Kotlin/Jetpack Compose — when hardware integration, performance, or platform feel is decisive.
Intunio is a design and development studio in Gothenburg. When an app needs the best possible experience on each platform, deep access to the hardware, or the latest OS features right at release, native is often the right call — and we've built native for apps that interface with connected products and vehicles.
Native development here is part of our app development: the same way of working, where designers and engineers share the backlog, but focused on when a platform-specific codebase is worth its cost.
The platform choice is often the most consequential decision in an app project. Native iOS and Android are often right when hardware integration, performance, or platform-specific UX is central:
The app needs to reach deep into the device — sensors, Bluetooth, camera, HealthKit, background processes, security features.
You need the latest OS APIs right at release — new capabilities from Apple or Google that can't wait for a cross-platform layer.
Performance and platform feel are business-critical — the app must feel exactly right on each platform.
Large parts of the product are pure native platform functionality rather than shared logic.
Native delivers the best possible experience on each platform, at the cost of two codebases and two skill sets. When speed and a shared design foundation outweigh that, we look at Flutter 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. The classic advantage of cross-platform — one shared codebase, less time — carried weight when development was expensive. With AI tools (Claude, Cursor, Codex) making even two native codebases efficient, that advantage shrinks. Increasingly, native is our first choice for new apps: it delivers the best result, without the old cost-and-time penalty.
Full access to the platform. Swift/SwiftUI on iOS and Kotlin/Jetpack Compose on Android give direct access to every OS API, sensor, and system feature — with no layer in between.
The best platform feel. The app follows the platform's own guidelines and interaction patterns, and feels at home on each device.
Latest features at release. New OS capabilities are available immediately, not when a framework has caught up.
Top performance for demanding, hardware-near, or real-time-heavy products.
Tight hardware integration — relevant for connected products, instruments, and vehicles, where the app is the interface to something physical.
Native isn't a theory for us — we've delivered live native apps for both iOS and Android:
[Matlistan](/en/projects/matlistan) — a native iOS app that collects recipes and generates the week's shopping list, sorted by store layout. Familiar patterns in an everyday, fast flow.
[Nira Dynamics](/en/projects/nira-dynamics) — a native Android client in Kotlin that visualises vehicle sensor data (Road Surface Alerts, Road Roughness), with a Go server handling large data volumes.
[Swanholm Technology](/en/projects/swanholm-technology) — we initially built a native Android app for a smart safety vest, with Bluetooth integration to the hardware (before it was later scaled to cross-platform).
Several of these cases are apps to a connected, physical product — one of the situations where native truly pays off.
A native 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 native really is the right call. When the app is the interface to a connected product, industrial UX is our adjacent service, with deeper methodology around hardware integration and safety-critical flows.
Native (Swift/Kotlin) gives the best platform feel, full access to hardware, and the latest OS features right at release — at the cost of two codebases. Cross-platform (Flutter, React Native) ships to both platforms from one codebase, faster and cheaper to maintain, but with a layer between you and the platform. The choice depends on how important hardware integration, performance, and platform feel are. We make the call with you; Native vs. cross-platform walks through the reasoning.
Yes. We build native iOS in Swift/SwiftUI and native Android in Kotlin/Jetpack Compose. Choosing native for both platforms means two codebases — we plan team and release cycle accordingly, and keep the design foundation shared through a design system so the product feels unified despite two implementations.
Yes. We often come in mid-flow — into an existing Swift or Kotlin codebase for continued development, modernisation, 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 native development works well fully remote.
Get in touch with us at Intunio, and we'll take it from there.