Health apps: how HDS, GDPR and medical device rules change your project
10 min read
Key takeaways
- If only one person knows how to publish the app, you have a business risk, not a technical detail.
- Automate the build first, then the tests, and finally publication.
- Distribution to internal testers is the most immediate gain in the whole chain.
- Every version must be traceable to the line of code that produced it.
- A complete chain represents five to ten days of work and pays for itself within a quarter.
In many teams, publishing a mobile version still looks like this: one person, on their own machine, three hours of manual steps, two certificates that have to be tracked down, a version number incremented by hand, and a prayer before hitting send.
This isn't a comfort issue. It's a business risk: that person can be on leave, ill, or gone.
The four levels of automation
Each brings its own benefit; you can stop at any level.
Level 1 — Reproducible build (1 to 2 days)
One command produces a signed binary, from any machine, with no manual configuration. Certificates and keys are stored encrypted and retrieved automatically.
What it eliminates: "it builds on my machine", dependence on a single machine, and the panic when a certificate expires — a classic incident described in our article on maintenance.
Level 2 — Automatic checks (1 to 2 days)
On every proposed change: build, static analysis, unit tests, style check. Nothing can be merged if the build fails.
What it eliminates: the silliest regressions, and style discussions in code review — the machine settles them, humans talk about architecture.
Level 3 — Automatic distribution to testers (1 day)
Every merge produces an installable build, distributed automatically to the team and business testers, with release notes generated from the changes.
It's the most immediate gain in the whole chain. Business feedback goes from "at the next delivery" to "tomorrow morning", and misunderstandings are settled before they become costly.
Level 4 — Automated publication (1 to 3 days)
Sending the build to the stores, updating metadata and screenshots, automatic numbering, tagging the repository.
The platform's review remains an external step, and it's sensible to keep a manual trigger for the final release — but everything before it happens without intervention.
The test that reveals a team's maturity: ask someone who has never published the app to do it, alone, with the existing documentation. The time it takes them — and the number of times they have to ask for help — measures exactly your dependence on one person.
What to test, and what not to
The classic mistake is to aim for exhaustive coverage. On mobile, it's costly and not very profitable: the interface changes often, and tests that are too fine-grained break with every design change.
What's worth it:
- pure business logic — calculations, rules, transformations: quick to test, stable over time;
- the three to five critical end-to-end journeys — login, the main journey, payment;
- serialisation of the data exchanged with the server, a frequent cause of silent crashes;
- a visual regression test on the most sensitive screens, if the product justifies it.
What's not worth it: testing every screen, every animation, every visual state. The maintenance cost of these tests quickly exceeds their value.
Traceability, often forgotten
Every version installed by a user must be traceable to the line of code that produced it. Concretely: the version number shows the identifier of the change, the repository is tagged at each release, and the crash-tracking tool receives the corresponding symbol files.
Without this, a crash report on a version published three months earlier is indecipherable, and you fix things blind.
5–10 dTo set up a complete pipeline on both platforms
1 qtrTypical payback time
3–5Critical journeys are enough for end-to-end tests
The payback calculation
A team that publishes twice a month, with three hours of manual steps per release and one hour fixing last-minute problems, consumes about 96 hours a year on manual publishing.
A complete pipeline represents seven days of setup, or about 56 hours. It pays for itself in seven months on time spent alone — not counting the removal of the dependency risk, the regressions avoided, or the speed of business feedback.
For a team that publishes every week, payback comes in under a quarter.
Automating delivery doesn't make the team faster in the moment. It makes delivery boring — and a boring delivery is one you dare to do often.
Where to start tomorrow
Level 1, nothing else. One command that produces a signed binary, from any machine. Two days, and you've removed the most serious risk.
The rest can wait until the following quarter: each level delivers its value independently, and nothing requires you to build everything at once.
Sources
- TestFlight — Apple
- Configurer un test ouvert, fermé ou interne — Google Play Console
- Signer votre application (in French) — Android Developers
