You need an app that runs on the Android phones and tablets your users really have, from recent models to rugged work devices. We build it in Kotlin, test it on devices we pick with you and prepare the Google Play release.
Android runs on thousands of models from many manufacturers, with several OS versions in use at once. Building for it is like taking a play on tour: every theater has different lights and a different stage, and the show still has to work on opening night. An app can feel great on a new flagship and crawl on the older phone one of your customers still uses. So we start by deciding with you which devices and versions to support, using your own numbers when you have them. It's an unglamorous decision, and no other one carries as much weight.
The second thing is sneakier. To save battery, the system shuts down apps running in the background, and some manufacturers add rules of their own. Think of a building manager switching off the lights without checking whether anyone's still working. A sync, a notification or a connection to a device can stop with no error message at all, while your user assumes everything went through. We design for that from day one and check how the app behaves on real hardware.
We like this terrain. It rewards patience, and a modest phone will tell you more truth about an app than the latest flagship ever will. We write in Kotlin, the language Google recommends, with Jetpack Compose, its current toolkit for building screens. Codetics is a French company working remotely, and if you also need iPhone, that means a second app, priced on its own.
A new app, an older one to modernize, or that problem only some customers hit and nobody can reproduce.
An Android screen doesn't know its size ahead of time. It has to stay readable on a small phone and on a tablet.
What changes from one Android version or manufacturer to the next, and rarely shows up on the phone of whoever's writing the code.
One of the real pleasures of Android. It opens up easily to equipment, with constraints that vary by device. Cables get pulled, links drop, and the app has to recover.
Google Play lets you send a new version to a share of users first. We like that, because a bug is easier to clean up when it has reached only a few people.
It works fine for you and crashes on one manufacturer's devices. Notifications stopped arriving, a background task keeps dying. These failures like to hide, and we track down the cause remotely. A one-hour diagnosis for €149 or two priority hours for €390, with a written report. How much gets fixed depends on the time and on device access. VAT not applicable, art. 293 B CGI.
People often pick it for its device choice and its hardware connections. These are examples of needs.
Your crews use devices you choose and control. That's a gift on Android: you finally know the hardware, so the app can be tuned for it and keep working without a connection.
Connected over Bluetooth or USB, it shows the machine's status and sends settings. Machine safety functions stay outside the app and need a separate scope.
It has to hold up on modest phones and slow connections. Nobody's going to tell you their phone is old. They'll tell you your app is slow.
It crashes on some devices or no longer meets Google Play's rules. We fix what's blocking you first, then modernize in stages.
A short list of what Google recommends, so someone else can pick up the app someday without starting from scratch.
The app's language, including background tasks and communication with hardware.
For building screens that adapt to very different device sizes, without hand-drawing every case.
For connecting the app to equipment, tested on the actual hardware, since no simulator can stand in for a real cable.
For getting the app to people, through closed testing and then a staged rollout.
Together we list the models and Android versions to support. That choice has a direct effect on the budget, since every device added needs its own testing.
If Bluetooth, USB or background work is involved, we try it early on real devices, before building the rest. A bad surprise costs less at the start.
You get test versions on the chosen devices, and differences between models are handled within the agreed scope.
Release goes through the testing Google asks for, then a staged rollout. You get the source code and documentation.
The quote spells out the supported devices, the hardware to connect and the store release, so everyone's talking about the same thing. VAT not applicable, art. 293 B CGI.
Send an Android briefA behavior to explain or a blocker in an existing app, at a fixed price. VAT not applicable, art. 293 B CGI.
See Express InterventionDecide which devices to support, get code reviewed or prepare a move to Jetpack Compose. VAT not applicable, art. 293 B CGI.
See the consulting dayA precise list or just a rough picture of your users is enough to start. We'll tell you what it involves and what it costs.
Codetics