Mobile app development
Native iOS and Android apps for demanding work: field conditions with no network, sensitive data, deployment across entire fleets. From prototype to an estate of several hundred devices.
What we build
We develop iOS and Android apps in each platform's native language: Swift and SwiftUI on the Apple side, Kotlin on the Google side. No intermediate layer, no web engine dressed up as an app. Interfaces follow each platform's conventions, performance is measured on real devices, and system integration is complete: notifications, biometrics, camera, Bluetooth, widgets, smartwatch.
Our clients are industrial SMEs, international groups and public institutions. Their projects have one thing in common: a constraint that off-the-shelf products do not cover, whether hardware, regulatory or confidentiality related.
Native or cross-platform
The question deserves asking on every project, and the answer is not always the same. A catalogue consulted for a few minutes a month does not need native. An app used eight hours a day by operators wearing gloves, in a warehouse with no network, with barcode scanning and on-device inference, does.
We recommend native when performance, hardware access or longevity matter. A cleanly written native app survives five or six major iOS releases without a rewrite. Cross-platform frameworks impose their own migration schedule, over which you have no control.
Pixel-perfect interfaces
SwiftUI and Jetpack Compose, smooth 120 Hz animations, respect for the system's text size and contrast settings.
Full hardware access
Camera, LiDAR, Bluetooth Low Energy, NFC, Secure Enclave, sensors. Without third-party plugins or a JavaScript bridge.
Genuine offline
Encrypted local database, synchronisation queue, explicit conflict resolution. The app works in a basement, a tunnel or in flight.
Longevity
Code that stays maintainable for five to ten years, without depending on a third-party framework's roadmap.
The field comes first
A large share of our projects happens where the network is poor or absent: workshops, warehouses, construction sites, aircraft cabins, trade fairs. So we design the app as though connectivity were the exception rather than the rule.
Data is stored locally and encrypted, user actions are queued, and synchronisation resumes when the network returns, with a conflict strategy decided up front rather than endured in production. Nobody ever waits on a server to carry on working.
On-device intelligence
We embed vision and classification models directly on the device, through CoreML on iOS. Local inference removes network latency, works offline and, often the deciding argument, means no image ever leaves the device.
For quality control in a workshop, an on-site inspection or reading a confidential document, this is the only architecture that satisfies both the technical and the confidentiality constraint. Where useful we train on synthetic data, which avoids having to assemble a real image set before even starting.
Publishing and fleet deployment
Publication on the App Store and Google Play, or private distribution when the app is not meant to be public: Apple Business Manager, ad hoc distribution, or silent installation on a fleet managed through MDM.
We handle certificates, provisioning profiles, test channels and version upgrades. Developer accounts are opened in your name: you remain the owner of your apps and their listings.
What you receive
The same commitments as on every project of ours, written into the proposal.
- The complete source code, in your repository, from the first sprint.
- Technical documentation and a user guide with every delivery.
- Developer and distribution accounts opened in your company's name.
- A reproducible build pipeline, so another team can take over.
- A maintenance contract sized on the application's actual criticality.
An example
iPad app for cutting food waste in airline catering: embedded CoreML inference, analytics dashboard and a sovereign self-hosted backend. From what is recorded on board to the procurement decision.
Frequently asked questions
Native or cross-platform: how do you decide?
We start from three criteria: daily time in the app, the need for hardware access, and the expected lifespan of the application. If none of the three is demanding, a cross-platform solution may be enough and we will say so. Otherwise native costs less over five years.
How long until a first version?
Eight to sixteen weeks for a first version usable in production on a well-defined scope. The scoping itself takes one to two weeks and determines everything that follows.
Who owns the code and the distribution accounts?
You do. Source code sits in your repository from the first sprint, and the Apple Developer and Google Play accounts are opened in your company's name. Reversibility is complete and contractual.
Can you take over an existing app?
Yes. We start with an audit of the code, the dependencies and the technical debt, then propose either a maintenance handover or a progressive module-by-module rewrite. We never recommend a full rewrite without having costed the alternative.
Can the app work with no connection at all?
Yes, and that is the case for most of our line-of-business apps. Data is stored and encrypted locally, and actions are replayed on reconnection. All that is needed is an up-front decision about what happens when two people edit the same record offline.
Let's talk about your project.
Describe your need in a few lines. We answer within 48 working hours, with a first technical opinion rather than a sales pitch.