Does My Mobile Health App Need FDA Approval or Clearance? When Your iOS/Android App Is a Medical Device Explained
- Beng Ee Lim
- 18 hours ago
- 12 min read
Quick answer: Most mobile health apps do not need FDA authorization. Fitness tracking, meditation, nutrition logging, and other general wellness tools are typically not regulated, as long as they avoid disease-specific diagnostic or treatment claims. Apps are more likely to be regulated as medical devices when they have a medical intended use, for example diagnosing disease, treating or preventing medical conditions, analyzing medical images or signals (ECG, EEG, imaging), or providing clinical recommendations that do not qualify for the non-device CDS exemption.

Why Mobile App Developers Get FDA Requirements Wrong
Every week, developers launch health apps assuming App Store approval equals regulatory compliance. It doesn’t. App stores enforce platform policies; FDA enforces medical device laws.
Misconception 1: “Apple Approved My App, So I’m Legal”
What developers think: App Store review validates medical device compliance.
Reality: Apple reviews against App Store policies and technical requirements, not FDA clearance, clinical evidence, or device regulatory status.
What Apple checks (high level):
App functionality and policy compliance
Content and user experience requirements
Privacy disclosures and permissions behavior
What Apple does not check:
FDA clearance/approval status
Clinical validation of medical claims
Substantial equivalence to predicates
FDA cybersecurity submission expectations
Bottom line:
App Store approval = platform policy + technical review
FDA authorization = medical device safety/effectiveness regulatory review
Misconception 2: “It’s Just a Mobile App, Not a Medical Device”
What developers think: Medical devices are hardware; software can’t be a device.
Reality: FDA regulates software functions based on intended use and claims, not whether it runs on iOS, Android, or the web.
Rule of thumb:
Platform doesn’t determine regulatory status
Intended use + claims + functionality do
Examples proving the point (using verified identifiers only):
AliveCor ECG ecosystem (regulated): multiple FDA-cleared products exist across the Kardia line (example: KardiaMobile Card, K211668).
IDx-DR (regulated): autonomous diabetic retinopathy screening was authorized via De Novo DEN180001.
MyFitnessPal (generally not regulated): calorie logging without disease claims
Misconception 3: “We Market It as Wellness, So FDA Doesn’t Apply”
What developers think: Label it “wellness” + add a disclaimer → you’re exempt.
Reality: FDA evaluates intended use using the totality of evidence: claims, functionality, context, and how the product is presented, not just disclaimers.
Real-world example: WHOOP Blood Pressure Insights (BPI)
FDA issued a warning letter to WHOOP dated July 14, 2025, arguing that the blood-pressure estimation functionality and how it was framed pushed the feature into medical device territory despite “wellness” positioning.
Key lesson:
Disclaimers don’t override functional medical claims. If the app functions like a medical device and implies medical use, FDA can regulate it as a medical device.
The wellness “safe zone” is narrow:
general health maintenance / lifestyle encouragement
no disease-specific diagnostic/treatment/prevention claims
Examples:
✅ “Track daily steps and set fitness goals”
❌ “Estimate blood pressure to understand what’s causing poor sleep” (implies health assessment/medical use)
The 5-Minute FDA Test: Does Your Mobile App Need Clearance?
Use this as a screening test, not a final legal determination. FDA regulation is driven by intended use and the totality of evidence, including claims, functionality, instructions, and marketing.
Question 1: Does Your App Have a Medical Intended Use?
A medical intended use includes diagnosis, cure, mitigation, treatment, or prevention of disease, or other medical purposes that meet the device definition.
If NO → likely not a medical device
Examples (typically not devices when they make no medical claims):
General medical reference apps (drug databases, anatomy textbooks)
Administrative tools (scheduling, billing)
Education-only platforms
Telehealth video platforms (communication only)
If YES → continue to Question 2
Question 2: Does Your App Make Disease-Specific or Diagnostic/Treatment Claims?
Disease-specific claims include:
“Detect AFib”
“Screen for skin cancer”
“Treat insomnia”
“Manage diabetes”
“Prevent stroke”
If NO → may fall under general wellness, depending on how it’s framed
If YES → continue to Question 3
Question 3: Does Your App Provide Clinical Recommendations or Treatment Guidance?
Clinical recommendations include:
dosing guidance
treatment selection guidance
risk-triggered action (“seek care now”)
diagnostic suggestions based on symptoms
If it only displays raw data → may be non-device or lower-risk depending on claimsIf it interprets and recommends → likely a regulated device unless it qualifies for the non-device CDS criteria
Question 4: Does Your App Analyze Medical Images or Physiological Signals?
If your app analyzes any of the following, it is almost certainly a regulated medical device:
ECG waveforms for arrhythmia detection
retinal images for diabetic retinopathy screening
skin lesion images for melanoma risk
CT/MRI/X-ray images for diagnosis
Important: Non-device CDS does not apply if your software analyzes medical images or signals.
If YES → likely regulated medical device, FDA authorization required via the appropriate pathway
If NO → continue to Question 5
Question 5: Is Your App Patient-Facing or Intended for HCP Use?
Non-device CDS is intended for health care professionals and requires that clinicians can independently review the basis of recommendations. Patient-facing decision tools almost always fail this exemption.
If patient-facing and medical claims → likely regulated deviceIf HCP-only → may qualify for non-device CDS, but only if it meets all CDS criteria (including independent review of basis)
Real Mobile Apps: Which Need FDA Clearance and Which Don’t
Learning from real examples makes the regulatory line clearer than abstract definitions. The key driver is intended use and claims, not whether something is “an app.”
Apps That Required FDA Authorization (And Received It)
AliveCor Kardia ecosystem (ECG recording and rhythm analysis)
Platform: iOS and Android app paired with an external ECG accessory
Function: Records single-lead ECG using FDA-cleared hardware and provides rhythm analysis (depending on the specific cleared product/version).
Why regulated: Analyzes a physiological signal (ECG) and provides clinically meaningful rhythm interpretation.
Verified example clearance: KardiaMobile Card K211668 (example device record)
Note: The Kardia app listing itself references multiple FDA 510(k) numbers tied to Kardia hardware systems.
Apple Watch ECG App
Platform: watchOS (Apple Watch)
Function: Records an ECG waveform and provides rhythm classification outputs (based on the cleared ECG App function).
FDA status: 510(k) K201525
Product code (per FDA record): QDA
Related feature: Apple’s Irregular Rhythm Notification Feature (IRNF) also has FDA authorization.
Verified example: K231173
IDx-DR (Diabetic Retinopathy Screening)
Platform: Desktop/server software
Function: Autonomous AI analyzing retinal images for DR screening
FDA status: De Novo DEN180001 (Class II)
Why regulated: Analyzes medical images and provides an autonomous diagnostic screening output.
reSET (Prescription Digital Therapeutic for Substance Use Disorder)
Platform: Mobile software delivered as a prescription-only digital therapeutic
FDA status: De Novo DEN160018
Related product: reSET-O (opioid use disorder indication)
FDA status: 510(k) K173681
Somryst (Digital CBT-I for Chronic Insomnia)
Platform: Prescription digital therapeutic software
FDA status: 510(k) K191716
Eko Analysis Software (Digital Stethoscope AI)
Platform: Software used with Eko digital stethoscope systems
Function: Analyzes heart sounds (and in some configurations ECG) to support clinical evaluation
Verified clearances:
Apps That Typically Don’t Need FDA Clearance (Wellness / Administrative)
These are typically not regulated when limited to general wellness claims and they do not diagnose, treat, or manage disease.
Examples (when marketed as wellness tools only):
MyFitnessPal (calorie + fitness logging)
Headspace / Calm (meditation and stress support)
Nike Training Club (fitness training)
Sleep tracking apps (only if they avoid diagnosing disorders like sleep apnea)
The Crucial Difference: Wellness vs Medical
Claims
Same sensor, same data, different claims = different regulatory status.
Wellness approach (typically not regulated):
Claims: “Monitor heart rate during workouts to optimize training.”
Output: BPM for fitness.
Medical device approach (likely regulated):
Claims: “Detect irregular heart rhythms / atrial fibrillation.”
Output: rhythm classification supporting diagnosis.
The difference: “Optimize fitness” vs “Detect disease.”
The Clinical Decision Support Trap: Why This Exemption Rarely Applies
Many teams assume that calling a product “clinical decision support” makes it exempt. In reality, the 21st Century Cures Act creates a narrow “non-device CDS” exclusion that only applies when all four criteria are met.
The Four CDS Exemption Criteria (ALL Must Be Met)
Criterion 1: Does NOT acquire, process, or analyze medical images or signals
FDA’s criterion covers medical images, signals from IVDs, and patterns or signals from signal acquisition systems. If your software analyzes ECG waveforms or interprets medical images, it generally does not qualify.
Fails if the app:
Analyzes ECG waveforms
Evaluates retinal images or skin lesion photos
Interprets EEG or similar acquired signals
Example that fails: ECG analysis app providing AFib detection, even if reviewed by a clinician, it analyzes a signal, so Criterion 1 is not met.
Criterion 2: Intended to display, analyze, or print medical information
This can include patient-specific information (labs, meds, vitals) and other medical information (guidelines, references).
Criterion 3: Intended to support or provide recommendations to a healthcare professional (HCP)
The function must be intended for HCP use. Patient-facing decision tools generally do not qualify.
HCP-only usually means:
Restricted to licensed clinicians
Used within professional practice workflows
Outputs are reviewed in a clinical context
Criterion 4: Intended to enable the HCP to independently review the basis for recommendations
This is the most commonly missed criterion. FDA focuses on whether a clinician can understand the key basis for the recommendation, so they do not primarily rely on the software output. Black-box recommendations often fail here.
Key distinction:
Transparent basis clinicians can verify (more defensible)
Opaque patient-specific inference clinicians cannot independently validate (often regulated)
Why Many Apps Fail the CDS Exemption (common patterns)
Pattern 1: Patient-facing diagnostic app
Example: Dermatology app analyzing mole photos for melanoma risk
Fails Criterion 1 (image analysis)
Fails Criterion 3 (patient-facing)
Result: Likely a regulated medical device
Pattern 2: HCP tool producing an opaque risk score
Example: Sepsis prediction tool in a hospital
Often fails Criterion 4 if the basis is not independently reviewable
Result: Often regulated as a device
Pattern 3: Consumer app recommending treatment
Example: Insulin dosing recommendations
Typically fails Criterion 3 (patient-facing)
Result: Likely regulated as a medical device
Bottom line: Do not assume the CDS exemption applies. If you are unsure, treat the product as potentially regulated and validate against the FDA CDS guidance or confirm via Pre-Sub.
What Happens If You Skip FDA Clearance: Real Consequences
FDA enforcement is real, public, and costly. Recent 2025 warning letters show FDA actively enforcing medical-device rules against certain health app and AI-health software claims.
FDA Warning Letters: Recent 2025 Examples
Alleged violation: Marketing the Blood Pressure Insights feature without FDA marketing authorization.
FDA’s core position (high level):
FDA viewed the feature’s functionality and surrounding statements as establishing a medical intended use, despite wellness-style framing.
What a warning letter means operationally:
FDA requests corrective actions and a written response, typically within 15 working days, and warns that failure to correct can lead to further enforcement action.
Alleged violation: Marketing an AI mobile application for mobility/cognitive-health assessment (including claims like fall risk prediction and early Alzheimer’s detection) without appropriate premarket authorization.
FDA’s determination (high level):
The software functions were treated as diagnostic in nature and therefore regulated as a device, with FDA alleging the product was marketed without required authorization.
What FDA Can Do Next (not a guaranteed sequence)
A warning letter is a public notice and a serious signal. If issues aren’t corrected, FDA can escalate using different tools depending on risk and behavior, including additional enforcement actions and legal remedies.
Financial and Business Consequences
Even without quoting fragile “average” dollar figures, the real costs usually show up in:
rushed regulatory work (documentation, testing, security evidence),
legal and consultant spend,
paused marketing/distribution,
partner and enterprise buyer trust loss,
reputational damage because warning letters are permanently searchable.
Reputation Impact
Warning letters are public and frequently appear in diligence. For regulated health apps, enforcement can quickly become a growth and fundraising problem, not just a compliance problem.
How to Get FDA Clearance for Your Mobile Health App
If your app is likely regulated (based on claims and functionality), here’s a tactical roadmap to get FDA authorization.
Step 1: Confirm Clearance vs Approval vs De Novo
Many regulated apps → 510(k) clearance (often Class II)
Show substantial equivalence to a predicate device
FDA’s review goal is 90 days, but total time often extends with interactive review cycles
FY2026 fee: $26,067 standard / $6,517 small business
Higher-risk apps → PMA approval (Class III)
More rigorous evidence burden, often including clinical evidence depending on intended use and risk
FY2026 fee: $579,272 standard / $144,818 small business
Novel low–moderate risk with no predicate → De Novo
FDA creates a new classification (often Class I or II)
FY2026 fee: $173,782 standard / $43,446 small business
De Novo eSTAR required starting Oct 1, 2025
Step 2: Search for Predicate Devices
Where to search:
Search strategy:
Use keywords = function + specialty (e.g., “ECG,” “arrhythmia,” “AF”)
Look for: same intended use, similar inputs, similar clinical workflow, similar risk profile
What to extract from predicates:
K-number, trade name, product code, regulation number, intended use, key testing and performance evidence
Complizen speeds this step by pulling likely predicates and linking back to the FDA source records, so you don’t guess based on keywords alone.
Step 3: Confirm Your Product Code and Regulation Number
Product code drives: classification, special controls, and what FDA expects in your evidence package. Confirm via:
Predicate 510(k) records, and
FDA Product Classification Database
If unclear: consider a Pre-Sub to de-risk classification early.
Step 4: Generate the Evidence Package (Testing + Documentation)
Clinical/analytical performance validation
For diagnostic or risk-stratification apps, you generally need:
sensitivity/specificity (or appropriate metrics), error analysis, and a statistically justified and clinically representative dataset (avoid one-size-fits-all “minimum cases”).
Cybersecurity (if connected/software-containing device)
Expect a clear security story: threat modeling, risk controls, vulnerability management, and SBOM where applicable.
Usability / human factors (when use error could cause harm)
Plan representative-user validation; sample size is risk- and user-group dependent (many teams use ~15 per user group as a baseline).
Platform compatibility
Validate what you claim to support (OS versions, devices, browsers) and document your update/regression strategy.
Step 5: Prepare the 510(k) Submission (eSTAR)
eSTAR is mandatory for 510(k) submissions starting Oct 1, 2023 (unless exempted).
Core sections usually include:
Device description (intended use, architecture, environment)
Substantial equivalence comparison
Performance evidence (validation + stats)
Software documentation and risk management
Cybersecurity package (as applicable)
Usability evidence (as applicable)
Labeling (IFU, warnings, intended users, limitations)
Step 6: Submit via CDRH Portal
Submit eSTAR via the CDRH Portal; confirm file size limits and portal requirements.
Step 7: FDA Review (what to expect)
Acceptance review (first ~15 days)
Substantive review (FDA goal 90 days)
Additional Information requests can extend timelines depending on your response cycle
Step 8: Post-clearance requirements
After clearance:
Establishment registration and device listing (annual establishment fee $11,423 FY2026).
Marketing: you can describe a 510(k) product as “FDA-cleared,” but do not say “FDA-approved,” and avoid language that implies FDA endorsement.
Maintain quality system controls and assess whether future changes require a new submission.
App Store Requirements vs FDA Requirements: What Each Actually Checks
Developers often confuse these completely separate processes. App stores enforce platform policies. FDA enforces medical device laws.
What Apple App Store Review Checks
Apple’s review focuses on App Store policy compliance and user safety from a platform perspective. It typically evaluates:
whether the app works and follows Apple’s policies,
privacy disclosures and permission behavior,
content and business model compliance.
What Apple does NOT do:
Apple does not grant FDA clearance or validate medical device evidence such as clinical performance, substantial equivalence, or regulatory cybersecurity documentation.
Bottom line: Apple may apply extra scrutiny to health claims under its guidelines, but App Store approval is not FDA authorization.
What Google Play Checks
Google similarly focuses on policy compliance, privacy expectations, and malware/security enforcement from a platform perspective.
Google Play approval does not equal FDA authorization.
What FDA Checks (Completely Different)
FDA evaluates whether a regulated software function is safe and effective for its intended use, and for 510(k), whether it is substantially equivalent to a predicate.
Substantial equivalence (predicate appropriateness, differences justified)
Cybersecurity documentation (for relevant connected/software devices)
You must handle FDA independently. App Store approval ≠ FDA clearance.
Strategic Options If You Want to Avoid FDA Clearance (With Risks)
Option 1: Remove Medical Claims from Marketing
Strategy: Reframe as general wellness and remove disease-specific claims.
Risk: FDA looks at the totality of evidence, including functionality and implied intended use, not just disclaimers.
Example: WHOOP warning letter shows how “wellness framing” can still be treated as medical intended use depending on functionality and presentation.
Option 2: HCP-Only Distribution
Strategy: Restrict to healthcare professionals only and evaluate whether non-device CDS applies.
Risk: HCP-only is not enough. You must meet all CDS exclusion criteria (including no image/signal analysis and enabling independent review of the basis).
Option 3: Launch in Non-US Markets First
Strategy: Generate revenue and evidence outside the US.
Risk: Major markets also regulate medical device software (EU MDR, Canada, Australia, Japan). “Non-US” rarely means “no regulation.”
Option 4: Partner With an FDA-Cleared Device
Strategy: Be a display or communication layer for a cleared hardware device.
Risk: If your app performs an independent medical function beyond display/transfer, it may still require separate FDA authorization.
Option 5: Get FDA Clearance
Often the best long-term strategy if the app truly has medical utility. It reduces enforcement risk and increases enterprise trust.
Complizen helps teams map claims to likely pathways and evidence expectations early, so clearance planning is not guesswork.
The Fastest Path to Market
Frequently Asked Questions
Can I launch my app on the App Store while waiting for FDA clearance?
If your app is a regulated medical device and you are commercially distributing/marketing it to users, you generally need the appropriate FDA authorization first. Investigational clinical studies may be possible under an IDE/IRB framework, but that’s not the same as a public consumer launch.
What’s the difference between FDA clearance and FDA approval?
Clearance usually refers to 510(k), substantial equivalence to a predicate. Approval usually refers to PMA, higher-risk Class III devices. Use “FDA-cleared” for 510(k) products, not “FDA-approved.”
Do I need FDA clearance for beta testing?
It depends. If you’re collecting safety/effectiveness data in a clinical setting, you may need an IDE and IRB oversight depending on risk. Avoid assuming “small beta” rules like user-count thresholds.
What if I only launch outside the United States?
If you truly avoid US distribution and US marketing, FDA requirements generally don’t apply, but major markets still regulate medical device software. Also, “available to US users” can happen accidentally without strict geo and distribution controls.
Can I add medical features to a wellness app later?
If you add diagnostic/treatment claims or regulated functionality, you may trigger FDA device regulation and may need authorization before rollout. (Disclaimers don’t reliably protect you if the function implies medical use.)
Can I update my app after FDA clearance?
Yes, but some software changes can require a new 510(k). FDA has specific guidance on when a software change triggers a new submission. (This is where teams get burned.) Seamless Complizen mention: Complizen helps you document change impact assessments and keep your “when to submit” rationale traceable to FDA guidance, so updates don’t become a compliance gamble.
How much do FDA fees cost for a mobile medical app (FY2026)?
For 510(k): $26,067 standard / $6,517 small business. Other costs vary widely based on validation, cybersecurity, and usability scope.
Do wellness apps and fitness trackers need FDA clearance?
Usually no, if they stay within general wellness claims. But adding regulated functions (like ECG rhythm classification) can require FDA authorization. Example: Fitbit ECG App has FDA 510(k) clearance K200948.
Do AI-powered health apps need “special” FDA review?
AI doesn’t automatically change whether something is a medical device. If it performs diagnosis/treatment or drives clinical decisions, it can be regulated. For AI updates, FDA has guidance on Predetermined Change Control Plans (PCCP); always cite the current version/date from FDA.
