How to Develop a Mobile Health App

Someone opens a health app for the first time at midnight, after reading something online that frightened them, or in a waiting room, or on the morning a test kit lands on the doormat. That's the emotional state most people are in when they arrive, and mobile health app development usually plans for everything except that. The regulatory work gets a project plan. The security work gets a budget line. The feeling of opening the thing when you're scared gets whatever's left.

We've designed and built products across health insurance, genetics, fitness and wellness, and the pattern holds. The compliance work decides whether you're allowed to launch. The emotional design decides whether anyone comes back.

A health app's first job is calming someone down, and almost everything else depends on that working.

There's no shortage of competition either. In the second quarter of 2024 there were 36,200 medical apps in the Google Play Store, according to Statista, 2024, and 35,000 on the Apple App Store. So the question isn't whether you can ship one. It's whether yours is the one a worried person trusts.

What follows is how we approach health app development in practice, from working out whether you're building a medical device, through discovery, design and security, to what to track once real people are using it.

Deciding Whether Your App Is a Medical Device

This is the first question, and it changes everything downstream. Regulators in the UK and the EU look at what you say your product is for, which is called its intended purpose. Two apps can process the same heart rate data and land on opposite sides of the line, because one of them displays a number and the other one tells you what the number means for your health.

The wording in your marketing counts as well as the code. We've seen teams write a perfectly unregulated product and then describe it on the website in a way that claims diagnosis, which pulls the whole thing into scope.

Get a regulatory view in writing before design starts. If you're a medical device, you need a quality management system, a clinical evaluation and a technical file, and all of that shapes your timeline and your team. Finding out six months in is the expensive version.

The Rules You Have to Build Around

We learned the cost of a late rule on a peer-to-peer currency exchange product, where travellers swapped leftover foreign currency with each other at interbank rates and skipped the commission. The core transfer mechanism was good. What we hadn't factored in was anti-money laundering. Apple looked at the unlimited transfer capability and flagged the product as a possible vehicle for laundering, so we went back and retrofitted stricter know-your-customer checks, extra transfer security and hard limits on how many transfers any two people could make between them.

That wasn't a health product, and the lesson transfers directly. Rules you discover after the build become rebuild work, and rebuild work always costs more than design work.

For health, the stack you're building around usually includes UK GDPR, where health data is special category data and needs a lawful basis plus an extra condition, the medical device route if chapter two put you in scope, HIPAA if you're touching US patient data, and the NHS Digital Technology Assessment Criteria if you want to sell into the NHS. Clinical risk management standards sit on top of that for anything connecting to NHS systems.

Write your data map before your wireframes. One page listing every piece of personal data, where it's stored, who sees it and how long you keep it will catch more compliance problems than any later audit.

Discovery: Finding Out What Users Actually Need

A property developer came to us wanting a concierge app for their high-rise buildings. They arrived with a suggested budget and a fully formed idea of what they wanted, and what they really wanted from us was a signature on it. We talked them into a proper discovery phase instead, with focus groups and user workshops.

What we found was that the product needed to be far simpler than they'd pictured. A lot of the features they'd planned never got built, and the focus moved to creating a human connection with the product rather than replacing systems the building already ran perfectly well. They got a better product for less money.

Discovery looks like a delay on the plan right up until it deletes half the backlog.

For a health product the discovery work has an extra layer, because you're researching an emotional state as well as a task. The sequence we use looks like this.

1. Map the moment someone opens the app, and what's just happened to them
2. Interview real users, including the ones who gave up on something similar
3. Talk to the clinicians or scientists who'll stand behind the content
4. Write the core flow as one sentence, then cut features that don't serve it
5. Agree what evidence you'd accept that a feature isn't working

Step five saves arguments later. Teams that haven't agreed it in advance defend features on instinct.

Designing for Someone Who Is Worried

We worked on a healthcare and health insurance product built for African markets, where a fair number of people arriving at the app were in a heightened emotional state. Somebody's ill, or there's been an accident, or a claim is the only thing standing between them and a bill they can't pay.

We went for a dark UI with green undertones. Green carries associations of calm, safety and medical support, and we wanted that feeling without the product looking clinical, because clinical reads as cold when you're frightened. The language was rewritten to be very, very simple, with the medical jargon stripped out, so the product destressed people rather than adding to what they were already carrying.

Colour and language do the emotional work

Those two choices carry more weight in a health product than almost anything else on screen. A sentence like "your claim is being assessed against policy exclusions" and a sentence like "we're checking your cover now, and we'll tell you either way within an hour" contain the same information and leave the user in completely different states.

Read every error message and every empty state out loud as if you were saying it to someone in tears. If it sounds harsh spoken, it reads harsh on screen.

The First Thirty Seconds: Earning Trust Before You Ask for Anything

Headspace's opening screen is the clearest working version of this we point clients at. There's a single call to action sitting above a simple illustrated character, an orange sun-like figure, and that's it. No sign-up gate. No diagnostic questionnaire. No "how are you feeling today?" prompt, which presumes an intimacy the user hasn't worked up to yet.

The implicit promise in that screen is that this is light, it isn't clinical, and you're not entering a therapy session. You're starting a friendly new habit. By asking for nothing, it avoids the two things that break trust on a health app before the product has had a chance to be any good.

Where the login form belongs

One of the first things we do with clients is work out the core flow, the emotional feeling we want people to have, and the functional and emotional job the product is doing. From there we work out how much use somebody needs before the value lands. If a user needs to experience a five-minute session to understand the point of the product, the login form goes after that, not before it.

Teams resist this because signed-up users are easier to count. The user who signed up and never came back isn't worth much though, and the gate is often the reason they didn't.

Revealing Results Without Causing Panic

On a health and wellness product we worked on, there was a strong push from the people who understood the science to go straight in and show results. Show the data. Show the information. They weren't wrong about the quality of the data, and leading with it was still the wrong call, because stress and anxiety levels are already high when someone opens a health product, and raw numbers push them higher.

What we did instead was frame people emotionally first, so they came into the content understanding the basics. The anxiety drops, and then they can take in detail.

That's what progressive disclosure is for in a health context. The layering follows the user's emotional state rather than the structure of the data. On that product, the top level used very simple, easy-to-understand metaphors about the human body. The science came in gradually as people went deeper, and the people who wanted the underlying numbers could always get to them.

Give every results screen a one-line plain English summary at the top that a worried person can read in two seconds. Charts and reference ranges sit below it.

The test for any health result is simple. If a user reads the top of the screen and immediately searches the internet for what it means, your framing hasn't done its job.

When the Brand Promise and the App Don't Match

We worked on a mobile app in the health and wellness genetics sector where the brand and the product were pulling in opposite directions. The printed packaging and the online presence were luxurious and aspirational, all about transformation, becoming a better version of yourself, reaching your full potential. The app they'd already built was cold and clinical, purely functional in its copy and its design.

Think about the journey that creates. Someone sees the aspirational marketing, buys a kit, waits for it to arrive, spits in a tube, posts it back, waits again, and then opens the app to find out who they are. The whole emotional build-up stops dead at the one touchpoint that was supposed to pay it off. It was a very jarring experience, and the journey broke down entirely at the product.

Your packaging promises transformation and your results screen reads like a lab printout, so the user feels the gear change.

This happens because marketing and product are usually built by different teams at different times, with different briefs. The fix is to treat tone of voice and emotional feeling as part of the product specification rather than something the brand guidelines handle elsewhere. Write the results copy with the same people who wrote the packaging copy, and the join disappears.

Handling Sensitive Data: Location, Identity and Health Records

We worked on a social product for fitness that was originally map based, showing users' real-time locations so people could meet up and train together. The research changed it. We found a high proportion of the user base was going to be female, and precise location sharing turned from a feature into a safety problem.

So we redesigned it. We introduced randomised offsets to the location, so a user saw only the vague area somebody was in. People could then talk, look at each other's profiles, and choose to share their exact location when they were ready. The core value survived, because you still had enough proximity data to judge whether meeting up made sense, and the risk came out.

Ask for less, and say why

Every permission request in a health product is a trust transaction. Six in ten users report abandoning an app installation after finding the data requirements excessive, according to eSpincorp, and that's self-reported, so treat it as sentiment rather than measured behaviour. It still matches what we see in testing.

Request a permission at the moment it does something useful, explain in one line what it buys the user, and let them carry on if they say no. Health records, identity documents and location all deserve that treatment separately.

Security Decisions That Shape the Build

On a performance coaching survey app we built, presenters needed to collect anonymous responses from a room full of people. We used the inbuilt iOS libraries to generate the QR code entirely within the presenter's native app, so none of it was stored externally. The code was only ever live and visible in the venue at the time of the presentation. Once the presenter marked the survey finished, no more responses could be recorded, which meant each survey was time-limited rather than an open-ended hole sitting there forever.

That decision was made at architecture stage, and it cost nothing. Retrofitting the same behaviour later means a server, a key store, an expiry policy and a penetration test.

The baseline matters because the category average is poor. Of 92 mental health apps assessed against the APA framework, only 15% met the first two steps covering accessibility and security and privacy, according to PMC, 2022. The sample was drawn from apps people can actually find in the stores, which is the competition.

Decide early on encryption at rest and in transit, whether sensitive data stays on the device, how long you keep records, how you delete an account properly, and who on your own team can see what. Each of those answers shapes code, so late changes are rewrites.

Choosing Your Technology and Integration Approach

The technology choice follows the product, and in health the deciding factor is usually what you need from the device and from the health platforms. If you're reading from HealthKit on iOS or Health Connect on Android, pulling in Bluetooth readings from a monitor, or running background tasks, that narrows things quickly.

On integration, assume you'll be talking to something clinical eventually. FHIR is the standard worth building towards for health records, even if version one holds everything itself. Of 92 mental health apps assessed, only one met all five steps of the APA framework including interoperability and data sharing, per PMC, 2022, so the bar is low and the differentiation is real.

Design your data model so a clinician could receive it. That single constraint keeps you out of a rebuild when a hospital, an insurer or a trial partner asks for an export.

Testing a Product Where Mistakes Have Consequences

A sports club app we worked on wanted everything live at once. No phased release, no cut-down first version, just the full feature set on launch day. We pushed hard for an iterative approach and incremental releases, and that project taught us how much listening to the process matters, because a product that insists on launching everything simultaneously is at real risk of never launching at all.

Health products carry the same pressure with higher stakes, since a wrong number on a results screen isn't a cosmetic bug.

In a health product, a rounding error is a clinical event, so testing has to cover meaning as well as function.

Beyond normal QA, we test content accuracy with the clinicians or scientists who own it, we test accessibility properly with screen readers and large text, and we test emotional response by watching people read results for the first time and asking what they think it means. That last one catches things no automated suite finds, because a correct number badly framed sends somebody to A&E.

Run your edge cases on real data shapes. Missing readings, a result at the extreme end of the range, a user who stops halfway through onboarding and comes back three weeks later. Those are the states where health apps embarrass themselves.

Getting Through App Store Review and Clinical Assessment

Apple and Google both apply extra scrutiny to health. The currency exchange rejection we had taught us the general shape of it, which is that reviewers consider what your product could be used for, not only what you intended. In health, that means they'll look at whether you're making medical claims, whether a regulated feature has clearance behind it, and whether your privacy labels match what the app actually does.

Prepare the evidence in advance. A demo account that works, a clear note explaining who the product is for and what it does, and documentation of any regulatory status all shorten the cycle.

Clinical assessment is a separate bar

If you're selling into health systems, you're also facing DTAC in the UK, clinical safety documentation and procurement security questionnaires. These ask for things app stores never mention, like named clinical safety officers and hazard logs.

The quality bar in the category is low, which cuts both ways. The mean score across those 92 assessed apps was 3.02 out of a possible 14, according to PMC, 2022. Passing store review is survivable. Passing a clinical buyer's assessment is where most products stop, and it's also where the serious contracts are.

What to Measure Once It's Live

Most teams track the funnel and nothing underneath it, which tells you where people left and never why. The data we want is more granular. Time on screen. People going into a screen, coming back out, and going back into it. Scrolling behaviour, particularly repeated up-and-down scrolling through terms and conditions or a consent screen.

That pattern signals either a lack of comprehension or a lack of trust, and in a health product those are the two failures that matter most. Someone reading a consent screen four times is telling you something a conversion rate never will.

Set up granular event tracking before launch, not after. Retrofitting screen-level timing and scroll events means a release cycle you'll resent spending.

Judging features honestly

We assess every single feature against one question, which is whether it helps the user or works against their stated intentions. A streak that guilts someone back into a wellness app is working against them. A reminder that arrives when they asked for it is working for them.

Watch push notification and in-app message frequency as a number in its own right, and keep everything timely and relevant. Health products get permission to interrupt people's lives, and that permission is withdrawn quietly, through a settings screen you never see.

Budgeting and Timelines for a Regulated Build

Regulated builds cost more, and the increase is predictable rather than mysterious. Development budgets in heavily regulated sectors including healthcare rise by 30-50% because of compliance, security and data protection work, according to GoodFirms. That lands roughly where our own quotes do, and it's a useful number to show a board that thinks the quote looks high.

What drives the difference is worth spelling out.

• Regulatory classification work and the documentation that follows it
• Quality management processes wrapped around normal development
• Security architecture, encryption and penetration testing
• Clinical review of every piece of content that makes a claim
• Accessibility work done properly rather than retrofitted

Scoping mobile health app development realistically

The two things that save money are the two things clients resist. Doing discovery before committing to a feature list, which is how the property developer's concierge app ended up simpler and cheaper, and releasing in stages rather than holding everything back for one launch, which is what the sports club app fought us on.

Budget for the first year, not the launch. A health app that ships and then sits still loses its clinical content accuracy, its OS compatibility and its users, roughly in that order.

Conclusion

The technical parts of health app development are well understood. Classification, data handling, security architecture, store review, clinical assessment. They're demanding and they're knowable, and a decent team gets them right with enough planning time.

The part that separates products is quieter. It's the green undertones on the insurance app for African markets, chosen so a frightened person feels looked after. It's the randomised location offset on the fitness social product, which kept the feature and removed the risk. It's the simple body metaphors at the top level of the wellness product, holding the science back until somebody's calm enough to take it in. And it's the genetics app, where everything was technically fine and the user still felt the floor drop out between the packaging and the results screen.

Build for the emotional state people arrive in, and the compliance work has something worth protecting. Build the compliance alone, and you've made a safe product nobody opens twice.

If you're planning a health product and working out where the risks sit, we're happy to talk it through, whether that's classification, discovery or the design of the first thirty seconds. Let's talk about your health app.

Frequently Asked Questions