What regulations apply to a mobile app?

A mobile app typically sits under five overlapping layers of rules. Cross-sector regulation such as UK GDPR, CCPA and children's online safety law applies because of what the app does with data and audiences. Territorial jurisdiction determines which versions of those rules apply. Sector regulation applies because of what the company does (finance, health, gambling, telecoms). Product-specific requirements apply because of what the particular software does (such as software as a medical device). Platform rules from Apple and Google apply because of where the app is distributed. Which rules bite hardest depends on the specific app and sector.

Does HIPAA apply to every health app, and what makes an app HIPAA compliant?

No, HIPAA does not apply to every health app. HIPAA applies when the organisation providing or using the app is a covered entity (such as a healthcare provider, health plan, or healthcare clearinghouse) or a business associate working with one. A consumer wellness app from a company that is not a covered entity is not within HIPAA's scope, even if it handles health-related data. That data may still be regulated under other laws, including state privacy laws, FTC Act section 5, and the FTC Health Breach Notification Rule, but not HIPAA specifically. For an app that does fall within HIPAA's scope, "HIPAA compliant" means satisfying the Privacy Rule, the Security Rule and the Breach Notification Rule as they apply to the app's specific functions, including administrative, physical and technical safeguards around protected health information (PHI). Compliance is an organisational determination, not something an app can claim on its own.

What does COPPA compliance mean for a mobile app?

COPPA is the US Children's Online Privacy Protection Act, enforced by the FTC. For a mobile app, COPPA compliance applies when the app is directed to children under 13, or when the operator has actual knowledge that it is collecting personal information from children under 13. Compliance requires verifiable parental consent before collecting such information, limits on the data that can be collected, specific disclosures in the privacy policy, parental rights to review and delete, data retention limits, and reasonable security practices. In practice, COPPA shapes the sign-up flow, the data a child-directed app can collect from its users, and the SDKs the app can integrate (because the operator carries liability for data its SDKs collect too). COPPA sits alongside the UK's Age Appropriate Design Code and, in the EU, GDPR's provisions on children's data.

Does FCA Consumer Duty cover app design?

Yes, in effect. The Consumer Duty requires firms to deliver good outcomes for retail customers, and the FCA has reviewed how digital acquisition journeys, including app and website design, affect customer understanding and decisions. The regulator has published good and poor practice findings on default settings, friction, risk warnings, and information sequencing in digital design. For firms in scope, the Consumer Duty reaches into UI and product design decisions that would previously have been seen as commercial choices rather than regulatory ones.

Do UK GDPR and US state privacy laws both apply to one app?

They can, yes. If an app has UK users, UK GDPR applies to the processing of their personal data. If the same app has users in California, CCPA/CPRA applies to those users. The same app may fall under Virginia, Colorado, Connecticut, Utah, Texas, Oregon and other state privacy laws depending on where its users are. In practice, apps serving users across territories either implement a common approach that meets the strictest applicable regime, or implement different approaches by jurisdiction. Neither is cheap, and both require decisions that are often invisible to the product roadmap.

What is SaMD, and when does an app become a medical device?

SaMD stands for Software as a Medical Device, a classification used internationally through the International Medical Device Regulators Forum (IMDRF) and recognised by the FDA, the MHRA and other national regulators. The classification covers software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. SaMD classification is function-driven, not platform-driven: an app becomes a medical device when its intended function falls within the regulatory definition, which generally covers diagnostic, therapeutic, monitoring and treatment-related functions. A workout tracker like Strava is not SaMD. A continuous glucose monitor companion app from Dexcom or Abbott Libre usually is. The specific class and regulatory pathway depend on the function, the intended user, and the clinical risk level, and often require a formal determination.

Who does GLBA apply to?

The Gramm-Leach-Bliley Act (GLBA) applies to US financial institutions, defined broadly to include banks, broker-dealers, insurance companies, mortgage brokers, tax preparers, consumer credit services, and non-bank lenders. For a mobile app, GLBA applies when the app is operated by or for a financial institution and handles non-public personal information about consumers. The FTC enforces GLBA for most non-bank financial institutions; the Office of the Comptroller of the Currency, Federal Reserve and FDIC enforce it for depository institutions.

How does the regulation pyramid apply in the EU?

The pyramid is the same shape in the EU, with different specific regulations at each layer. Cross-sector rules include GDPR (the European original), the ePrivacy Directive, the Digital Services Act (DSA) and the Digital Markets Act (DMA). Jurisdiction operates at the EU level with member-state variations. Sector regulation applies through EU directives transposed into national law, with regulators like the European Banking Authority, the European Medicines Agency and ESMA for financial services (which also carries DORA obligations). Product-specific requirements include the EU AI Act (phasing in through 2026 and 2027, with specific obligations on high-risk and general-purpose AI systems), the Medical Device Regulation (MDR), the European Accessibility Act (in force since June 2025, applying to digital products including many mobile apps), and sector-specific technical standards. Platform rules from Apple and Google apply, with the DMA additionally requiring Apple and Google to allow alternative app stores and sideloading in the EU, which adds a new sub-layer the UK and US do not yet have. If you want to work out which EU rules apply to a specific app, ask Appnalysis is a reasonable first stop, especially while the AI Act's enforcement bedding in is still live.

Does Apple or Google check that my app complies with the law?

No, not in the way most new developers assume. Apple and Google review apps against their own platform rules, which cover content, payments, data use, privacy disclosures and more, and reject apps that fail those rules. They do not check that an app complies with GDPR, HIPAA, the FCA Consumer Duty, state privacy laws, sector regulations or any of the lower layers of the regulation pyramid. Both platforms' terms explicitly place that responsibility on the developer. Apple's App Store Review Guidelines state in the Legal section that apps "must comply with all legal requirements in any location where you make them available" and that it is the developer's responsibility to make sure of that. Google's Play Developer Distribution Agreement makes the equivalent point. In practice, platform rules function as a faster-feedback layer (rejection or removal in days versus regulatory action in quarters) but satisfying Apple or Google does not demonstrate compliance with any of the lower layers of the pyramid.

Does the Online Safety Act apply to mobile apps?

Yes, where the app meets the Act's definition of a user-to-user service or a search service accessible in the UK. The Online Safety Act, enforced by Ofcom, imposes duties around illegal content, protection of children, and transparency. A social app, a messaging app, a user-generated-content platform or a search product that reaches UK users is likely in scope. A pure utility app with no user content is likely not. Scope decisions can be nuanced and often need legal input for marginal cases.

The hidden regulation pyramid: app regulatory compliance

No app is governed by one law. A mobile product can sit under broad privacy and consumer rules, territorial law, sector regulation, product-specific requirements and the policies of the platform distributing it. The closer you get to the individual app, the more specific those obligations become. Most teams only see the top layer, the one that got them into the App Store or the Play Store this week. The ones that bite hardest are often lower down. Software teams know the saying that the devil is in the detail. In regulation, the detail usually sits at the lower layers of the pyramid, not the headline ones. This is especially acute for teams building apps for the first time, often with AI-assisted or vibe-coded tools, where the muscle memory established teams have built up around compliance does not yet exist.

Open a regulated gambling app in the UK and this stops being abstract. UK GDPR affects how personal data is handled. UK law determines the jurisdiction. The Gambling Commission's licence conditions govern the sector. The Remote Gambling and Software Technical Standards reach directly into product behaviour. Apple or Google then add another set of distribution requirements. One app, five layers of rules, every one of them real.

The Gambling Commission's RTS 12 does not merely say operators should encourage responsible gambling. It specifies that financial limit controls must be readily accessible, visible from relevant screens, and designed to minimise the number of steps needed to reach them. Regulation reaching into what a button does, where it sits on the screen, and how many taps away it is. That is the point where "regulation" stops being lawyers and policies and starts being product design.

This article walks through the five layers, uses UK and US examples at each one, and ends with the insight that the search-popularity ranking of regulations and the product-relevance ranking of regulations are not the same list. It is part of the Appnalysis series on how software is growing up, picking up where the institutional context left off.

Key takeaways

Layer 1, cross-sector regulation: broad rules like UK GDPR, CCPA, COPPA that apply because of what the app does with data and audiences
Layer 2, jurisdiction and territory: which versions of the other layers apply, by user location (UK, US federal, US state, EU)
Layer 3, sector regulation: rules that apply because of the business you are in (FCA Consumer Duty, GLBA, Gambling Commission, MHRA, FDA)
Layer 4, product and service-specific requirements: rules that apply because of what the specific software does (SaMD, RTS 12, PCI DSS, Age Appropriate Design Code)
Layer 5, platform rules: Apple App Store and Google Play policies, which explicitly do not substitute for legal compliance

What is regulatory compliance for a mobile app?

Regulatory compliance is the practice of meeting the legal, sector and platform rules that apply to an organisation's activities. For a mobile app specifically, that means meeting the rules that apply to what the app does, where its users are, and how it is distributed. It is not one task but a set of overlapping obligations across cross-sector law (privacy, consumer protection, safety, accessibility), territorial jurisdiction, sector regulation, product-specific requirements, and the policies of the distribution platform. Which rules apply depends on what the app is, who uses it and where.

How to read the pyramid

The regulation pyramid is a mental model. Visualised as a shape, each layer narrows the context until it reaches the individual product at the tip.

The pyramid isn't a hierarchy of legal authority. It is a way of showing increasing regulatory specificity. An app can be subject to several rules at every layer. UK GDPR does not disappear because an app is also covered by the FCA Consumer Duty. The Gambling Commission's RTS does not override the App Store review guidelines. The layers coexist, and the number of rules an app has to satisfy accumulates as it moves up the shape.

That is also why most teams only see the top layer. The App Store rejection email arrives in the inbox this afternoon. The ICO's regulatory interest in the SDK you added two years ago arrives on a different timescale. Both are real. Only one of them tends to get called "compliance" in the Monday standup.

Cross-sector regulation: rules that follow almost every app

The widest base of the pyramid is the rules that apply because an app processes personal data, interacts with consumers, or reaches an audience that includes children, not because of the sector the company operates in.

UK GDPR is the headline cross-sector rule in the UK. It sets the lawful bases for processing personal data, the rights of data subjects, the obligations around breach notification, and the regime that the Information Commissioner's Office (ICO) enforces. The ICO publishes its data protection principles as the practical starting point for compliance. Any app that collects personal data from UK users is in scope, which in practice is almost all of them.

Alongside UK GDPR, several other cross-sector rules routinely apply to mobile apps. The Online Safety Act, enforced by Ofcom, imposes duties on services that host user-generated content, with specific obligations around protecting children. The Equality Act 2010 and its accessibility obligations apply to digital services. In the US, the equivalent cross-sector layer includes CCPA (and its growing patchwork of US state privacy laws), COPPA for apps aimed at children under 13, and the ADA's accessibility expectations as interpreted by federal courts.

None of this is sector-specific. A fitness app (think Strava or MyFitnessPal), a bank (think Monzo or Revolut), a gambling operator (think bet365 or Paddy Power) and a social network (think TikTok or Instagram) all meet this layer in similar ways, differing only in the specific data they process and the audience they reach.

This is the layer most teams recognise as "compliance", because it is the layer the general press writes about, the one the privacy officer worries about, and the one that generates the largest search volume. It is also the layer with the loosest connection to product behaviour. UK GDPR tells you a lot about what you can and cannot do with the data, but relatively little about how the data flows through the app, which SDKs touch it, or what the user sees when consent is sought.

For the governance work that sits around this layer, app compliance covers the operational roadmap. For how compliance obligations accumulate quietly inside a shipped app, compliance debt covers the sibling concept to tech debt.

same mobile app facing different cross-sector rule sets in uk and us, showing how uk gdpr, ccpa, state privacy laws and online safety rules overlap for one product

Jurisdiction and territory: where the app and its users are

The second layer is not really another type of regulation. It determines which versions of the other layers apply. An app available in both London and Austin is subject to different privacy regimes, different consumer protection rules, and different sector regulators depending on which user is opening it at which moment.

In the UK, the jurisdiction stack is relatively compact: UK GDPR, UK regulators (ICO, Ofcom, FCA, Gambling Commission, MHRA), and UK sector regimes. In the US, the picture is harder to draw neatly. Federal rules sit alongside state rules, and the state layer has become a working category of its own with the growth of US state privacy laws. California (CCPA/CPRA), Virginia, Colorado, Connecticut, Utah, Texas, Oregon and others have each produced their own regime, overlapping in principle, differing in detail.

An app that collects personal data from users in multiple US states is now choosing between implementing the strictest common denominator or operating state-by-state. Either is legitimate. Neither is cheap. And both are invisible to a trend forecast or a feature-prioritisation discussion that focuses only on what the app does.

The territory layer is where the "we comply with GDPR" claim earns its scrutiny. GDPR is a European regime. UK GDPR is the UK's own version, which differs in ways that have been diverging further over time. Neither applies in exactly the same form to US users. Compliance claims that are not scoped to a territory are claims without a frame.

The EU adds its own territorial layer with regulations that reach beyond GDPR: the Digital Services Act (DSA), the Digital Markets Act (DMA), the Digital Operational Resilience Act (DORA) for financial services, the EU AI Act coming into force in stages, and the European Accessibility Act applying to digital products from June 2025. Each is a distinct regulation. Together they form the European version of the stack the UK and US each have their own version of.

Sector regulation: what business are you in?

The third layer is often the one software teams miss hardest. Regulation at this layer does not apply because the product collects data or has UK users. It applies because of what the company does, regardless of the shape of the software.

The FCA Consumer Duty is the headline example in UK regulated finance. The duty requires firms to deliver good outcomes for retail customers, with specific attention to products and services, price and value, consumer understanding, and consumer support. In 2026 that includes the design of digital acquisition journeys. The FCA's own good and poor practice review of digital design examined how app and website design affects customer understanding and decisions, with findings on default settings, friction, risk warnings, and the sequence in which information is presented. This is a financial regulator issuing specific guidance on how a product's screens are laid out.

The Gramm-Leach-Bliley Act (GLBA) is the US equivalent in retail finance, imposing privacy and safeguards obligations on financial institutions that reach beyond general privacy law. The FTC enforces GLBA's privacy and safeguards rules, and the specifics apply differently to banks, broker-dealers, and non-bank financial services providers.

Health has its own stack. MHRA regulates medical devices in the UK, with specific guidance on software and apps. The FDA regulates in the US, with the Digital Health Center of Excellence covering device software functions including mobile medical applications. HIPAA sits inside this layer in the US but applies conditionally: a health app is only within HIPAA's scope when the organisation using or providing it is a covered entity or business associate under the law. An over-the-counter wellness app from a company like Fitbit or Whoop usually sits outside HIPAA. A patient-facing app from a hospital network inside it. Not every app that touches health data is a HIPAA app, and claiming otherwise is a common source of overstatement.

Gambling has the Gambling Commission in the UK, with licence conditions and technical standards (RTS) that apply across its licensees. Telecoms has Ofcom, with its own sectoral obligations. Children's services have additional overlays on the cross-sector base.

This is the layer where regulation starts to shape software behaviour directly, not just data handling. The FCA's attention to digital design, the MHRA's definition of what counts as medical device software, and the Gambling Commission's RTS all live here. The rules at this layer are often invisible to teams who do not identify primarily as a regulated-sector operator but who, in practice, are one.

Product and service-specific requirements: when software becomes a medical device (SaMD)

The fourth layer narrows further. It applies not to the whole sector but to what the specific software does.

Software as a medical device (SaMD) is the clearest example. A health app is not automatically a medical device because it deals with health. The question is what the software does. The FDA treats regulation as function-specific rather than platform-specific: its guidance on device software functions covers specific functions running as mobile medical applications, with different categories of regulatory oversight depending on whether the function is diagnostic, therapeutic, administrative, or wellness-oriented. The MHRA takes a similar function-driven approach for UK devices, under the SaMD classification used internationally through IMDRF. A workout tracker like Strava is not a medical device. A continuous glucose monitor companion app from a brand like Dexcom or Abbott Libre usually is. The progression goes:

Health → healthcare product → diagnostic or therapeutic function → potential medical-device regulation.

Each step is a filter, and only software that passes all four lands in the regulated class.

The gambling worked example sits at this layer alongside the medical case. RTS 12 is the specific product-and-service requirement that reaches into financial limit controls. It is not the Gambling Commission's general licence conditions, which belong one layer down. It is the technical standard that specifies what the UI must do and how it must behave. For teams building regulated gambling apps (bet365, Paddy Power, Sky Bet, DraftKings, FanDuel), this is the layer where the regulator effectively becomes a product reviewer, with specific opinions on screens, placements and tap counts.

Other product-specific layers show up across other sectors. In payments, PCI DSS specifies controls that apply to systems handling cardholder data. In children's online services, the UK's Age Appropriate Design Code applies specific obligations to apps likely to be accessed by children (relevant for anything from Roblox to BBC iPlayer Kids). In accessibility, WCAG success criteria operate at the specific-UI level.

The product-specific layer is the one where "we comply with the law" stops being a company-level claim and becomes a feature-level claim. It is also the layer where regulation starts to resemble product specification, which is why engineering teams who have never read it often discover they have been building against it without knowing.

Platform rules: who lets you distribute it?

The fifth layer, at the tip of the pyramid, is Apple and Google. These are not government regulations. They are private platform rules, written by the two companies that between them account for essentially the entire mobile app distribution market in most countries.

Apple's App Store Review Guidelines and Google's Play Store policies impose their own set of requirements, covering content, payments, data use, privacy disclosures, child safety, security practices and more. The specifics change regularly, often with limited notice. For a mobile product team, the practical consequence is that satisfying every legal and regulatory requirement is still not enough if the app also fails Apple or Google's own rules. Breaking a platform rule can restrict or prevent distribution, which for most apps is as consequential as breaking a law.

The platform layer is distinct from the regulatory layers in two useful ways. It is enforced faster, usually by rejection or removal within days rather than regulatory action within quarters. And it is enforced through the shipped app itself, by review processes that inspect the binary and its behaviour. For both reasons, the platform layer is the one teams instinctively prioritise. It is also the layer with the least connection to the harm the other layers exist to prevent. An app can satisfy App Store review and still fail UK GDPR. The platform does not check for that.

For the vendor and SDK evidence layer that cuts across both platform rules and sector regulation, vendor risk assessment covers the outward-facing version of the work. For continuous compliance operations that sit alongside platform submission, compliance automation covers the operational layer.

worked example of a uk health app sitting under five regulatory layers, from uk gdpr at the base to app store review at the tip

The muscle-memory gap in the vibe-coding era

Established mobile teams tend to carry scar tissue from previous compliance work. Someone on the team has been through an ICO investigation, a Play Store policy strike, an FCA review, a HIPAA assessment or a legal letter about a tracking SDK that should not have been there. They know which layer bites first in their sector, who to call when it does, and roughly when in the roadmap to raise the question. The pyramid is partly implicit knowledge.

The new wave of app builders in the vibe-coding era does not have that scar tissue yet. The economics have changed. An individual can ship a working app in a weekend, and many are doing exactly that. The question that dominates on Reddit, in indie developer communities and in the AI-assistant transcripts of these new builders is "how do I get Apple to approve my app?" The lower layers of the pyramid rarely come up, because nobody in the conversation has been bitten by them yet.

Apple and Google do not help with this. Both platforms explicitly place compliance with applicable law on the developer, not on themselves. Apple's App Store Review Guidelines state, in the Legal section: "Apps must comply with all legal requirements in any location where you make them available. It's your responsibility to understand and make sure your app complies with all local laws." The Apple Developer Program License Agreement makes the same point as a contractual term. Google's Play Developer Distribution Agreement does the equivalent. Platform approval is explicitly not legal clearance. It never was, but the terms now say so in plain language.

The place a new builder might reasonably turn for help, their AI assistant, usually declines to give specific legal advice. Most modern LLMs, including Claude, add consult-a-professional caveats when asked whether a specific app complies with a specific regulation. That caveat is accurate. It is also not actionable for someone who shipped an app over a weekend and is asking because they do not know a professional.

For a new builder, the pyramid is not an abstract framework. It is a map of the layers that platform approval does not cover, that LLMs cannot advise on, and that nobody is going to find for them. For the broader pattern of what gets shipped when the muscle memory is missing, vibe coding security risks in mobile apps covers the specific angle.

Why the most searched regulation may not matter most to your app

The regulations that get the most search volume are not necessarily the ones that most directly shape mobile apps.

Regulation	Approximate UK searches per month	Approximate US searches per month	Where it reaches into the shipped app
UK GDPR	~6,600	n/a	Mostly through data flows and SDK choices
Consumer Duty	~3,600	n/a	Directly into digital design and user journeys per FCA review
GLBA (Gramm-Leach-Bliley Act)	~170 to 210	~5,400 to 6,600	Through safeguards obligations on financial app providers
SaMD (acronym)	~720	~6,600	Directly into product function classification
Software as a medical device (full phrase)	~320	~720	Directly into product function classification
Gambling Commission RTS	~20	n/a	Directly into UI controls and screen layout

Approximate monthly searches (Semrush, UK / US, October 2026).

The gap is informative. The regulations the industry talks about are not always the regulations that shape the shipped app most directly. UK GDPR has the largest awareness and the largest search demand in the UK. SaMD and GLBA together draw more than 10,000 US searches a month. Gambling RTS has around twenty searches a month and dictates specific UI behaviour down to the button placement.

Search popularity tells you what people know about. It does not tell you which regulation most directly shapes the software being built. For a team working inside a regulated sector, the hidden layers are often where the real product-affecting rules live, not the famous ones.

This connects to the wider story about how software is growing up. Regulators are reaching further into product behaviour than they used to. The FCA is reviewing digital design. The FDA is defining device software functions. The Gambling Commission is specifying UI controls. These are the lower layers of the pyramid becoming more specific, and more visible in the shipped app, over time.

regulation search volume versus product-behaviour impact for a mobile app, showing the inversion between what the industry talks about and what shapes the shipped build

How Appnalysis fits

Some regulatory obligations remain organisational and cannot be observed externally. Whether a company has the right data processing agreements in place, whether its board has reviewed its Consumer Duty implementation, whether its risk register names the relevant obligations. These sit above the shipped app and need their own governance.

Others leave evidence in the shipped product. Permissions, SDKs, disclosures, consent flows, account controls, user journey behaviour, and changes between releases. Appnalysis produces the observable-evidence layer for these: what the shipped app actually contains, does and depends on, measured from the binary rather than the documentation.

Observable evidence is not the same thing as proving compliance. It supports a compliance assessment that someone with the right authority can make. It does not replace that assessment, and it does not cover the organisational layer. For teams working across several of the pyramid's layers at once, it is one input into the compliance picture, not the picture itself.

For teams building with AI-assisted development, Appnalysis can be added as an agent into Claude Code, Codex and other AI coding workflows. The evidence it produces (SDK inventory, runtime behaviour, permission use, disclosure matching) becomes available to the AI assistant during development, so the assistant can reason against what the shipped build actually contains rather than generating code without that context. It is not a substitute for legal advice, and it does not turn the AI into a compliance oracle. It does close one of the gaps the muscle-memory section covered: the ability for a new builder's primary tool to know what their shipped app actually does. For how specialist knowledge gets added to AI coding workflows, Your AI Coding Agent Only Sees Half the Picture covers the pattern.

For how teams already running compliance programmes use the evidence layer in practice, mobile app audit covers the owner-inward version of the work.

The /product and /agencies pages cover how different teams use the platform. The /ask demo is open if you want to try it against a specific app.

Closing

The hidden regulation pyramid is not about hiding anything. It is about naming what has been there all along. Every app sits under a set of overlapping rules that get more specific to the individual product as you move up the shape. Most teams see the top layer because it generates the fastest feedback (platform review) and the layer immediately below it because the general press writes about it (cross-sector privacy).

The layers in between, where sector regulation and product-specific requirements actually shape what the software does, are the ones most often missed. They are also the ones most likely to turn up as a regulator's specific finding on a specific feature in a specific release, long after the standup where someone said the app was "fully compliant".