The most crowded room in your pocket

Imagine you download a free flashlight app. It does exactly one thing: it turns the camera flash on and off. You would be forgiven for assuming the legal stakes are roughly zero. Yet behind that single button, the app may be reading your precise GPS coordinates, harvesting your device's unique advertising identifier, scanning the list of other apps installed on your phone, and shipping all of it to a half-dozen advertising networks and data brokers you have never heard of. The flashlight is the cover story. The data is the business.

This is not a hypothetical. In a now-famous 2013 enforcement action, the Federal Trade Commission (FTC) settled with the maker of an Android flashlight app that had been transmitting users' precise geolocation and unique device identifiers to third parties while its privacy policy said nothing of the sort. The lesson stuck, and the pattern repeats to this day: the gap between what an app appears to do and what it actually does, data-wise, is where the legal liability lives.

Mobile apps have become the dominant way people interact with software. They manage our money, our medications, our messages, our marriages, and our moods. And precisely because a phone is an always-on sensor package that travels everywhere its owner goes, an app sits at the intersection of nearly every privacy law on the books. Over the past decade the FTC has investigated platform giants like Apple and Google and individual developers like Uber, Snap, and the mobile advertising company InMobi, extracting penalties and settlements that, in the aggregate, run well into the hundreds of millions of dollars. State attorneys general have piled on. Plaintiffs' lawyers have turned app privacy into a class-action cottage industry, with suits against household-name apps over location, contacts, and tracking practices. And that is just the United States; an app distributed worldwide must answer to Europe's General Data Protection Regulation and a growing list of national regimes besides.

This guide is a map of that terrain. It is written so that three very different readers can all follow it: a founder shipping a first app, an in-house lawyer trying to keep one out of trouble, and a curious user who wants to understand what is happening inside their own phone. Every term of art is defined in plain language the first time it appears. We will cover the FTC's foundational authority, the special rules for children's and financial apps, the California-led explosion of state privacy statutes, the platform rules that Apple and Google enforce as a kind of private law, the thorny problems of location and biometric data, breach-notification duties, and the newest battleground of "dark patterns" and deceptive consent. If you also need the intellectual-property side of app law, start with protecting your mobile app and the broader post-launch legal checklist; this article is the privacy half of that story.

Why mobile is different (and harder)

Before diving into specific statutes, it helps to understand why mobile apps create privacy headaches that older web-based services did not. The intuition most of us carry around about online privacy was formed in the era of the desktop web browser, and that mental model quietly misleads us when applied to apps.

On the desktop web, the browser is a referee. It sits between the user and the website, sandboxing what a site can see, surfacing permission prompts, storing cookies the user can clear, and generally giving a savvy person tools to push back. A native mobile app is different in kind. Once installed, it runs much closer to the metal of the device, and it can reach sensors and data stores a website never could: the precise GPS chip, the accelerometer and gyroscope, the camera and microphone, the address book, the photo library, the list of other installed apps, health and fitness data, and a persistent advertising identifier that follows the user across services. Practitioner literature on the subject, including Thomson Reuters Practical Law's note on mobile app privacy risks, emphasizes exactly this point: apps "collect, store, use, and share end user information in ways different from browser software" and therefore can surprise even web-savvy users.

Four structural features make mobile privacy uniquely treacherous:

First, invisible collection. Much of an app's data gathering happens at a technical layer the user cannot observe. A user who taps "Allow" on a location prompt rarely understands that the same coordinates may be sold to data brokers, used to infer where they sleep at night, and combined with thousands of other signals to build a behavioral profile.

Second, the small-screen problem. A mobile screen is a poor medium for the long, dense disclosures that privacy law often demands. Squeezing a meaningful notice and a genuine choice into a few hundred pixels is a real design challenge, and regulators know that a "privacy policy" buried three taps deep and written in nine-point legalese is not real notice.

Third, the SDK supply chain. Modern apps are assembled, not written from scratch. Developers bolt in third-party software development kits (SDKs)—pre-built code libraries for analytics, advertising, crash reporting, maps, and login—and each SDK can have its own data appetite. The developer is legally responsible for what those SDKs do, even when the developer does not fully understand it. This is the "data leakage" problem, and it is where many app makers get blindsided.

Fourth, speed and scale. Apps ship updates constantly and reach millions of users instantly, leaving little time for the deliberate legal review that a traditional product launch might receive. A bad data practice can be live in every market on Earth within hours.

Keep these four features in mind. Nearly every legal rule that follows is, at bottom, the law's attempt to grapple with one of them.

The FTC and Section 5: the all-purpose privacy cop

There is no single, comprehensive federal privacy statute in the United States. Instead, the workhorse of American privacy enforcement is a 1914 statute written long before anyone imagined a smartphone: Section 5 of the FTC Act, codified at 15 U.S.C. § 45, which prohibits "unfair or deceptive acts or practices in or affecting commerce." Those two words—unfair and deceptive—do an enormous amount of work.

A practice is deceptive, in the FTC's long-standing framework, when there is a representation, omission, or practice likely to mislead a reasonable consumer, and the misleading point is material—that is, likely to affect the consumer's conduct. In the app world, the classic deception case is the privacy-policy mismatch: the app says it does one thing with data and actually does another. The flashlight app from the introduction is the archetype. When an app's privacy policy promises that location data stays on the device and the app then transmits it to advertisers, the FTC treats the policy as a deceptive misrepresentation, full stop.

A practice is unfair, under the codified three-part test in 15 U.S.C. § 45(n), when it causes or is likely to cause substantial injury to consumers, that injury is not reasonably avoidable by consumers themselves, and it is not outweighed by countervailing benefits to consumers or competition. Unfairness is the FTC's tool for reaching practices that are not technically lies but are simply too harmful or too sneaky—lax security that exposes sensitive data, for example, or default settings that funnel data to third parties without any real chance for the user to object. For a fuller treatment of the agency's powers, see our overview of the FTC Act and consumer-protection enforcement.

Two features of FTC enforcement matter enormously in practice. The first is that the FTC has built, case by case, a kind of common law of data practices through its consent decrees. There is no statute that says "thou shalt not share precise geolocation without express consent," but there is a thick stack of settlements that, read together, tell developers exactly that. Sophisticated counsel read FTC consent orders the way litigators read appellate opinions.

The second is that the consequences are not limited to a one-time fine. FTC orders routinely impose obligations that last twenty years: mandatory privacy programs, independent third-party assessments, recordkeeping, and—most painfully—the threat of substantial civil penalties for any future violation of the order. In several recent matters the FTC has gone further still, ordering algorithmic disgorgement: the deletion not only of unlawfully collected data but of the models and algorithms trained on it. For an app built around machine learning, an order to destroy the model can be an existential event.

The FTC has also issued mobile-specific guidance that, while not binding law, functions as the agency's stated expectations and is therefore a roadmap to enforcement. Its guidance for app developers and platforms stresses transparency, just-in-time disclosures for sensitive data (showing the user a clear notice at the moment the data is collected, not buried in a policy), privacy by design, and honoring the choices users are offered. A developer who ignores that guidance is, in effect, volunteering to be a test case.

A worked example

Consider "Acme Steps," a hypothetical pedometer app from Acme Corp. Its privacy policy, drafted hastily before launch, says the app collects step counts "to provide the service." In reality, Acme integrated a popular analytics SDK and an advertising SDK, both of which collect the device advertising identifier and approximate location, and the advertising SDK shares that data with a network of brokers. Acme never disclosed any of this. Even if Acme's own engineers barely understood what the SDKs did, the FTC's deception theory does not care: the policy said one thing and the app did another. Acme's blind spot about its own supply chain is exactly the kind of thing that turns a flashlight-app fact pattern into a consent decree. The fix is not glamorous—inventory every SDK, understand what each one collects, disclose it plainly, and offer real choices—but it is the whole ballgame.

COPPA: the bright line around children

If there is one privacy area where the law is strict, specific, and unforgiving, it is children. The Children's Online Privacy Protection Act of 1998 (COPPA), 15 U.S.C. §§ 6501–6506, and the FTC's implementing COPPA Rule, 16 C.F.R. §§ 312.1–312.13, govern the online collection, use, and disclosure of personal information from children under the age of 13. The statute's purpose is to put parents in control of what commercial websites and online services—very much including apps—do with their young children's data.

COPPA applies to an operator of a website or online service that is either directed to children under 13, or that has actual knowledge it is collecting personal information from a child under 13. That trigger is broader than many developers assume. An app does not have to be a cartoon-covered kids' game to be "directed to children"; the FTC looks at subject matter, visual content, use of animated characters or child-oriented activities, music, the age of models, the presence of child celebrities, and advertising directed to kids, among other factors. And a general-audience app that learns a particular user is under 13 acquires "actual knowledge" and must comply as to that user.

When COPPA applies, the obligations are demanding. The operator must post a clear online privacy notice describing its information practices; obtain verifiable parental consent before collecting, using, or disclosing a child's personal information; give parents the ability to review and delete their child's information and to refuse further collection; refrain from conditioning a child's participation on disclosing more information than is reasonably necessary; and maintain the information securely. (See 15 U.S.C. § 6502(b); 16 C.F.R. § 312.3.) "Verifiable parental consent" is a genuine hurdle—a checkbox claiming to be a grown-up does not cut it. Acceptable methods have included signed consent forms, credit-card or government-ID verification, and knowledge-based authentication, and the FTC has approved certain newer methods over time.

The definition of "personal information" under COPPA is expansive and notably includes persistent identifiers—such as device IDs and cookies—that can recognize a user over time and across services. That matters for apps because behavioral advertising in a kids' app, which depends on exactly such identifiers, can itself be a COPPA violation absent parental consent. The FTC and the New York Attorney General drove this point home in the landmark Google/YouTube settlement, which produced a $170 million civil penalty over the collection of persistent identifiers from viewers of child-directed content for targeted advertising—at the time the largest COPPA penalty ever.

COPPA enforcement has only intensified. The FTC has pursued app developers, ad networks, and ed-tech providers, and in early 2025 it finalized a significant update to the COPPA Rule—the first major overhaul in over a decade—tightening requirements around the disclosure and retention of children's data, addressing the use of persistent identifiers, and requiring separate verifiable parental consent before sharing a child's information with third parties for targeted advertising. Developers of anything that might appeal to kids should treat COPPA as a hard constraint designed into the product from day one, not a policy bolted on at the end. For the post-launch context in which COPPA sits alongside age ratings and app-store rules, see legal considerations after developing a mobile app.

A related and fast-moving development: many states are enacting their own age-appropriate design codes and minor-protection laws aimed at teens (not just under-13s), modeled loosely on the United Kingdom's Children's Code. California's was partially enjoined on First Amendment grounds, and litigation over these laws is ongoing, but the direction of travel is clear. An app with a meaningful teen audience now faces a patchwork of state obligations on top of federal COPPA.

State privacy laws: the California earthquake and its aftershocks

For most of the internet era, the United States had no broad consumer-privacy statute of the European kind. California changed that. The California Consumer Privacy Act (CCPA), effective in 2020 and substantially amended by the California Privacy Rights Act (CPRA), gives California residents a suite of rights over their personal information and imposes corresponding duties on businesses that meet certain thresholds.

At a high level, the CCPA/CPRA gives consumers the right to know what personal information a business collects and how it is used and shared; the right to delete personal information; the right to correct inaccurate information; the right to opt out of the "sale" or "sharing" of personal information (with "sharing" defined broadly enough to capture much cross-context behavioral advertising); and, for a special category of sensitive personal information—which includes precise geolocation, biometric data, and information about health, sex life, race, religion, and the contents of certain communications—the right to limit its use. The CPRA also created a dedicated enforcement agency, the California Privacy Protection Agency (CPPA), and embedded a data-minimization principle: a business may collect and use personal information only as reasonably necessary and proportionate to the purpose for which it was collected. That minimization duty deserves its own study; see data minimization and avoiding the over-retention of personal information.

For app developers, several CCPA/CPRA features bite hard. The law requires a comprehensive privacy policy and, where a business sells or shares data, a conspicuous "Do Not Sell or Share My Personal Information" mechanism—and it requires honoring opt-out preference signals like the Global Privacy Control, a browser/device signal that automatically communicates a user's opt-out. The treatment of advertising identifiers and SDK-mediated data flows as a "sale" or "share" means that the typical free, ad-supported app is squarely within scope. And the CPRA's data-minimization and purpose-limitation rules cut against the old "collect everything, decide later" instinct that drove a generation of app design.

California was the earthquake; the aftershocks are a wave of comprehensive state privacy statutes. As of 2026, a substantial and growing majority of states—Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, and well over a dozen more—have enacted their own consumer-privacy laws. They share a common architecture borrowed largely from Virginia's Consumer Data Protection Act: access, deletion, correction, and portability rights; opt-outs for targeted advertising, sale, and certain profiling; heightened protection (usually opt-in consent) for "sensitive data" that typically includes precise geolocation and biometrics; and obligations to conduct data protection assessments for higher-risk processing. They differ in their thresholds, their definitions, their cure periods, and their enforcers (most are enforced by the state attorney general; California is the outlier with its dedicated agency).

The practical upshot for an app developer is sobering: there is no longer a single American privacy standard to comply with, but a patchwork that grows every legislative session. The sane strategy is to build to the highest common denominator—generally California, often supplemented by the most demanding features of the other states—so that a single privacy program and a single set of in-app controls satisfy the whole country. Building fifty bespoke compliance regimes is not realistic; building one good one usually is. The blueprint for that program is the subject of developing a privacy compliance program.

Sectoral laws: when the app's subject triggers special rules

Layered on top of the general FTC and state-law framework are sectoral privacy laws—statutes that regulate data not by who collects it but by what kind of data it is or what industry it comes from. Two matter constantly for apps.

The first is the Gramm-Leach-Bliley Act (GLBA), also called the Financial Services Modernization Act of 1999. Title V, Subtitle A of GLBA governs how "financial institutions" collect, use, protect, and disclose consumers' nonpublic personal information (NPI). GLBA defines "financial institution" broadly—any entity engaged in activities that are financial in nature, which sweeps in lenders, payment apps, "buy now, pay later" providers, robo-advisors, and many fintech apps that would not call themselves banks. Covered institutions must provide privacy notices, allow consumers to opt out of sharing NPI with non-affiliated third parties (subject to exceptions), respect limits on reuse and redisclosure, and—critically—implement the Safeguards Rule, a mandatory information-security program. (See 12 U.S.C. § 1843(k); 12 C.F.R. § 1016 (Financial Privacy Rule); 16 C.F.R. § 314 (FTC Safeguards Rule).) The FTC's revised Safeguards Rule, which took full effect in 2023, requires specific technical and administrative controls—access controls, encryption, multi-factor authentication, a qualified individual to run the program, and more—and the FTC has added a breach-notification component. If an app touches money, GLBA is probably in play, and the security obligations are not optional.

The second great sectoral regime is HIPAA—the privacy and security rules for protected health information. HIPAA's scope is narrower than people assume: it binds "covered entities" (providers, plans, clearinghouses) and their "business associates," not every app that happens to touch health data. A direct-to-consumer wellness or fitness app that is not handling data on behalf of a covered entity often falls outside HIPAA—but it is not therefore unregulated, because the FTC's separate Health Breach Notification Rule has been revived and expanded to reach exactly these consumer health apps, requiring notification when identifiable health information is disclosed without authorization. Many health apps live in a confusing in-between zone. If your app does operate as a HIPAA business associate—say it provides cloud services to a clinic—the rules are exacting, and we treat them at length in HIPAA business associates and cloud computing.

A third sectoral wrinkle worth flagging: video and "viewing history" data. The decades-old Video Privacy Protection Act (VPPA), born from a Supreme Court nominee's video-rental records being leaked, has been resurrected as a class-action engine against apps and sites that share users' video-viewing data with third parties (often via advertising pixels and SDKs). Any app that streams or recommends video should understand the VPPA's surprisingly broad modern application.

The platforms as private regulators: Apple and Google

Here is a feature of app law that lawyers from other fields find startling: for most developers, the most immediate and consequential "privacy regulator" is not a government agency at all. It is Apple and Google. The two app stores set the rules of distribution, and because they control access to essentially the entire smartphone market, their policies operate as a kind of private law—often stricter and faster-moving than the statutes.

Apple's App Tracking Transparency (ATT) framework, rolled out in 2021, is the marquee example. ATT requires an app to obtain the user's explicit, opt-in permission—through a standardized system prompt—before it can "track" the user across apps and websites owned by other companies, or before it can access the device's advertising identifier (the IDFA). The prompt is blunt ("Allow [App] to track your activity across other companies' apps and websites?"), and most users decline. ATT reshaped the entire mobile advertising economy overnight and wiped out a meaningful share of some companies' revenue. Apple also requires every app to display a privacy "nutrition label" on its App Store listing, summarizing what data the app collects and whether it is linked to the user or used to track them—and that label had better match what the app actually does, because a mismatch is both an Apple violation and FTC-grade deception.

Google Play's Data Safety section is the analogous requirement on Android: developers must complete a detailed disclosure form describing what data the app collects and shares, why, and whether it is encrypted in transit, and Google surfaces that summary on the listing page. Google has also moved to restrict the most sensitive permissions, curtailed the old practice of apps scanning the full list of other installed apps, and tightened rules around background location, requiring developers to justify any access to precise or background location.

Two practical lessons follow. First, platform compliance is a gating requirement: a privacy practice that is arguably lawful under statute can still get an app rejected or removed if it violates Apple's or Google's rules, and removal from the store is often a death sentence for the product. Second, the platform disclosures create a paper trail. The nutrition label and the Data Safety form are sworn-style representations to millions of users; regulators and class-action plaintiffs read them as admissions. An accurate label is a compliance asset; an inaccurate one is Exhibit A. The economics and antitrust dimensions of the platform relationship (the 30% commission, the post-Epic v. Apple landscape) are covered in legal considerations after developing a mobile app; here the point is simply that the platforms set privacy rules you must obey.

Location data: the most sensitive ordinary data

Of all the data an app routinely collects, precise geolocation may be the most legally radioactive relative to how casually it is gathered. A person's location over time reveals where they live, where they work, where they worship, where they seek medical care, who they spend nights with, and which protests or clinics or support groups they visit. Courts and legislators increasingly treat it as inherently sensitive.

The constitutional backdrop is Carpenter v. United States, 585 U.S. 296 (2018), in which the Supreme Court held that the government's acquisition of historical cell-site location records is a Fourth Amendment search requiring a warrant, recognizing that location data over time provides "an intimate window into a person's life." Carpenter constrains the government, not private developers, but it crystallized a cultural and legal consensus that location is different. That consensus shows up everywhere in private-sector privacy law: nearly every comprehensive state statute classifies precise geolocation as "sensitive data" requiring opt-in consent or a use-limitation right, and the CCPA/CPRA gives Californians a specific right to limit the use of precise geolocation.

The FTC has made location a clear enforcement priority. In a series of actions beginning in 2024, the agency targeted data brokers that collected and sold consumers' precise location data, including data that could reveal visits to sensitive locations like medical facilities, places of worship, and shelters. The FTC's theory blended deception (misleading consent flows) with unfairness (selling sensitive location data that consumers could not reasonably avoid disclosing and that exposed them to real harm), and the resulting orders banned the sale of sensitive location data and required deletion. For app developers, the message is unmistakable: collecting precise location requires a genuine, specific, just-in-time justification and real consent; selling or "sharing" it to brokers without that is asking for an enforcement action.

There is also a quieter litigation risk. Older state and federal wiretap and "anti-tracking" theories, plus the general state privacy statutes, give plaintiffs' lawyers hooks for class actions over surreptitious location tracking. And the SDK supply-chain problem is at its worst here: many developers do not realize that an advertising or mapping SDK they embedded is independently exfiltrating location in the background. The fix is the same disciplined inventory and minimization recommended throughout this guide—collect location only when the feature truly needs it, prefer coarse over precise, prefer foreground over background, and never assume an SDK is behaving.

Biometrics and the BIPA bombshell

If location is radioactive, biometric data is plutonium—because of one state statute that has reshaped the litigation landscape. Illinois's Biometric Information Privacy Act (BIPA), 740 ILCS 14, regulates the collection, use, storage, and disclosure of "biometric identifiers" (fingerprints, voiceprints, retina or iris scans, and—crucially for apps—face geometry) and "biometric information" derived from them. An app that uses facial recognition, voice authentication, or face-based features (filters, "find your celebrity lookalike," age estimation, liveness checks) can be squarely within BIPA's reach.

What makes BIPA fearsome is the combination of three features. First, it requires informed, written consent before collecting biometric data, along with a published retention-and-destruction policy. Second, it bans selling or profiting from biometric data. Third, and decisively, it provides a private right of action with statutory damages—$1,000 per negligent violation and $5,000 per reckless or intentional violation—and no need to prove actual injury. The Illinois Supreme Court confirmed that a plaintiff need not allege actual harm to sue (Rosenbach v. Six Flags Entertainment Corp., 2019 IL 123186) and, more explosively, that a separate claim accrues with each unlawful scan or transmission (Cothron v. White Castle System, Inc., 2023 IL 128004)—a holding that turned routine, repeated biometric scans into potentially ruinous aggregate exposure. The result has been enormous settlements, including a $650 million resolution of facial-recognition claims against a major social-media company.

The Illinois legislature amended BIPA in 2024 to soften the per-scan accrual problem somewhat, but the statute remains the most dangerous privacy law in the country for products that touch biometrics. Other states (Texas and Washington, for example) have biometric laws, but without Illinois's private right of action they have generated far less litigation. And the comprehensive state privacy statutes now uniformly treat biometric data as "sensitive," requiring opt-in consent. The intersection of biometrics with artificial intelligence—face and voice models trained on biometric data—is a frontier of its own, explored in biometric data privacy laws and their impact on AI development. The practical rule for app developers: treat any face, voice, or fingerprint feature as a high-risk system requiring explicit written consent, a retention policy, strict access controls, and serious legal review before launch.

GDPR and the global app

The moment an app is available to users in the European Union—which, for an app in a global app store, is essentially automatic unless you actively block those markets—the General Data Protection Regulation (GDPR) enters the picture. The GDPR applies to the processing of personal data of individuals in the EU regardless of where the processor is located, so a developer in Ohio with European users is subject to it. The penalties are not theoretical: up to the greater of €20 million or 4% of global annual turnover.

The GDPR's architecture differs from the American patchwork in a fundamental way: it requires a lawful basis for every act of processing personal data. The bases include the data subject's freely given, specific, informed, and unambiguous consent; performance of a contract with the data subject; the controller's legitimate interests (balanced against the individual's rights); and a few others. For the advertising and analytics that fund most free apps, consent is usually the operative basis, and the GDPR's consent standard is exacting—pre-ticked boxes and "take it or leave it" bundling are not valid consent, a point reinforced by the separate ePrivacy regime governing cookies and device access. The GDPR also grants data subjects robust rights (access, rectification, erasure or "right to be forgotten," portability, objection), requires data protection by design and by default, mandates data protection impact assessments for high-risk processing, imposes a 72-hour breach-notification duty to regulators, and requires many organizations to keep records of processing and appoint a Data Protection Officer.

For apps, two GDPR topics generate the most trouble. One is children's data: the GDPR sets a default digital-consent age of 16 (which member states may lower to 13), echoing COPPA but on a different threshold. The other is international data transfers. The GDPR restricts sending Europeans' personal data to countries without "adequate" protection, and the United States has spent years on the receiving end of that restriction. After the Court of Justice of the European Union invalidated successive transfer frameworks, transfers now typically rely on Standard Contractual Clauses plus a "transfer impact assessment," and on the EU-U.S. Data Privacy Framework for certified U.S. importers. Because so many apps run on U.S. cloud infrastructure and embed U.S.-based SDKs, nearly every globally distributed app is making cross-border transfers and must paper them correctly. The full mechanics are the subject of international data transfers after Schrems II. The United Kingdom maintains its own post-Brexit version of the GDPR with similar contours, and a growing list of other countries—Brazil's LGPD, Canada's privacy regime, India's new data-protection act, and more—impose comparable obligations, so a truly global app faces a stack of overlapping consent and transfer rules.

"Find Friends," contact-list harvesting, and the consent problem

One feature deserves a section of its own because it has spawned a remarkable amount of litigation and enforcement: the "Find Friends" / contact-upload feature. Many social and messaging apps invite users to find people they know by uploading the user's address book to the app's servers. Sounds friendly. The legal problem is layered.

First, the non-user problem: when the app uploads a user's contacts, it acquires personal information about hundreds of other people who never consented to anything and may not even use the app. Those non-users' names, phone numbers, and email addresses now sit on the app's servers, often used to build "shadow profiles" and to power friend recommendations. Regulators and plaintiffs have repeatedly challenged this as collection without consent.

Second, the consent-flow problem: courts and the FTC scrutinize how the upload was solicited. If the interface implies that the app is merely scanning the device to suggest connections while quietly uploading and retaining the entire address book, that gap between appearance and reality is a deception. The FTC's enforcement record includes actions targeting apps that uploaded contacts without adequate disclosure, and several well-known social apps have faced class actions over the same conduct.

The lesson generalizes well beyond "Find Friends": consent must match conduct, and disclosure must be honest about scope and retention. It is not enough to obtain a tap of approval; the approval has to be informed about what is really happening (uploading versus on-device matching), how long the data is kept, and who else gets it. And collecting data about non-consenting third parties is uniquely fraught, because those people had no opportunity to agree at all. The cleanest designs match contacts on the device, never upload non-users' raw data, and delete promptly. This is the data-minimization principle (discussed at length here) showing up in a specific, recurring fact pattern.

Dark patterns and the new law of deceptive design

The newest front in app-privacy enforcement is dark patterns—user-interface designs that manipulate or trick people into choices they would not otherwise make, especially choices that surrender privacy. A consent dialog where "Accept All" is a big bright button and "Reject" is gray, tiny, and three taps away; an "unsubscribe" flow engineered to be maddening; a default toggle pre-set to share data; "confirmshaming" copy that guilts the user ("No thanks, I don't care about my health")—these are dark patterns, and they are increasingly illegal.

The FTC has put dark patterns at the center of its agenda, issuing a staff report on the practice and bringing enforcement actions treating manipulative design as deceptive or unfair under Section 5. The CCPA/CPRA goes further and defines dark patterns in its regulations, providing that consent obtained through a dark pattern is not valid consent at all—meaning a developer who tricks a user into "agreeing" has, in the eyes of California law, obtained nothing. The comprehensive state statutes increasingly contain parallel provisions, and the GDPR's "freely given" consent standard reaches the same conclusion from the other side of the Atlantic. Regulators have also targeted negative-option and auto-renewal traps—the "subscribe easily, cancel never" pattern—through the FTC's Negative Option Rule and the federal ROSCA statute, which require clear disclosure of recurring charges and simple cancellation.

For developers, the takeaway is liberating once internalized: the safest consent interface is also the most honest one. Symmetrical choices ("Accept" and "Reject" given equal visual weight), neutral language, no pre-checked boxes for non-essential data, and a cancellation path as easy as the sign-up path are not just good ethics; they are increasingly the legal floor. A consent obtained by manipulation may be worth less than no consent at all, because it can convert what might have been a defensible practice into an affirmative act of deception.

When things go wrong: data-breach notification

No security program is perfect, and when an app suffers a breach, a second body of law kicks in: breach-notification statutes. Here the United States is again a patchwork. All fifty states (plus the District of Columbia and several territories) have data-breach notification laws, each defining "personal information," the trigger for notice, the timing, the content of the notice, and whether and when regulators (and credit bureaus) must also be told. The definitions and deadlines vary, so a breach affecting users nationwide typically requires a fifty-state analysis under time pressure.

Several sectoral overlays add their own breach duties. The HIPAA Breach Notification Rule governs breaches of protected health information; the FTC's Health Breach Notification Rule reaches consumer health apps outside HIPAA; the GLBA framework now includes breach notification for financial institutions; and the GDPR imposes its 72-hour clock for EU users. Many comprehensive state privacy laws also reference or reinforce breach obligations. Because notification deadlines are short and the analysis is jurisdiction-by-jurisdiction, the only workable approach is to plan the response before an incident—an incident-response playbook, a forensics relationship, notification templates, and clear internal escalation. The intersection of breach response with protecting confidential business information is covered in cybersecurity incident response and IP protection.

It is worth underscoring that the substantive duty to have reasonable security sits upstream of any notification rule. The FTC's unfairness authority, the GLBA Safeguards Rule, the state privacy statutes' security mandates, and the GDPR's "appropriate technical and organizational measures" all require reasonable safeguards, and a breach caused by sloppy security (default credentials, unencrypted sensitive data, no access controls) invites enforcement on top of the notification headache. Security is privacy's foundation, not a separate department.

Putting it together: a pre-launch privacy program for an app

The volume of law above can feel paralyzing, but in practice a disciplined developer can address nearly all of it through a handful of repeatable steps. Think of this as the privacy half of the broader launch checklist in legal considerations after developing a mobile app.

The first and most important step is a data inventory and SDK audit. Map every category of data the app collects, where it comes from, where it goes, and why. Crucially, this means auditing every third-party SDK and what each one collects and transmits—because you are legally responsible for all of it. You cannot comply with rules you do not know you are triggering, and most app-privacy disasters trace back to a developer who did not know what was inside their own product.

The second step is data minimization. For each data element, ask whether the app genuinely needs it for a feature the user wants. If not, do not collect it. Minimization is now an affirmative legal duty under the CPRA and the GDPR, not merely a best practice, and it is the single most effective risk reducer available: data you never collected cannot be breached, subpoenaed, mis-shared, or made the subject of an access request. See data minimization and avoiding the over-retention of personal information for the full treatment.

The third step is honest, layered notice and genuine choice. Write a privacy policy that accurately describes the practices revealed by your inventory, then surface the most important points through just-in-time, in-context prompts—especially for location, contacts, camera/microphone, and biometrics. Make the platform disclosures (Apple's nutrition label, Google's Data Safety form) match reality exactly. Offer real opt-outs and honor opt-out preference signals. Avoid dark patterns; make "no" as easy as "yes."

The fourth step is special handling for the high-risk categories. Children's data means COPPA (and possibly state design codes) and verifiable parental consent. Biometric features mean written consent and a retention policy, with BIPA front of mind. Financial features mean GLBA and the Safeguards Rule. Health features mean the Health Breach Notification Rule (and HIPAA if you are a business associate). European users mean a GDPR lawful basis and a transfer mechanism. Identify which of these apply to your app and design for them up front.

The fifth step is security and incident readiness: reasonable safeguards proportionate to the sensitivity of the data, encryption of sensitive data in transit and at rest, access controls, and a written incident-response plan with notification templates ready to go.

The sixth step is governance and documentation: assign an owner for privacy, keep records of your decisions and assessments (the data-protection impact assessments that the GDPR and several states require for high-risk processing are also excellent evidence of diligence), and revisit the program every time the app meaningfully changes—because every new SDK and every new feature can shift the analysis. The full architecture of such a program is laid out in developing a privacy compliance program.

Do these six things and you will have addressed the overwhelming majority of the legal exposure described in this article—not because they are magic, but because nearly every rule above reduces, in the end, to know what data you handle, collect only what you need, be honest about it, protect it, and treat the sensitive stuff with extra care.

Key takeaways

Mobile privacy law is not one statute but a stack of overlapping regimes, and an ordinary app can trigger several at once. The FTC's Section 5 authority is the general-purpose enforcer, punishing the gap between what an app says and what it does, and building a de facto common law through its consent decrees. COPPA draws a strict bright line around children's data. California's CCPA/CPRA started a wave of state laws that now blanket a majority of the country, all converging on rights of access and deletion, opt-outs for advertising data, heightened protection for sensitive categories, and a duty of data minimization. Sectoral laws (GLBA for finance, HIPAA and the Health Breach Notification Rule for health, the VPPA for video) attach to specific data types. The app stores function as private regulators whose rules are often stricter than the statutes. Location and biometric data carry outsized risk—location because it is so revealing and now an FTC priority, biometrics because of Illinois's BIPA and its ruinous statutory damages. The GDPR reaches any app with European users. Dark-pattern consent can be worth less than no consent. And when a breach happens, a fifty-state-plus notification analysis kicks in. The good news is that a single disciplined program—inventory, minimize, disclose honestly, secure, and handle the sensitive categories with care—addresses the great majority of it.

Frequently asked questions

Does my small app really need a privacy policy? Almost certainly yes. Apple and Google both require every app to have a privacy policy as a condition of distribution, California's CalOPPA and CCPA require one for apps collecting personal information from California residents, and an inaccurate or missing policy is exactly the kind of thing the FTC treats as deceptive or unfair under Section 5. A "small" app is not exempt; thresholds in some state laws can limit certain obligations, but the baseline duty to be honest about your data practices applies to everyone.

My app is for adults—do I still have to worry about COPPA? Possibly. COPPA reaches not only apps "directed to children" under 13 but also general-audience apps that gain "actual knowledge" they are collecting personal information from a child under 13. If your app is likely to attract kids, or if you learn a particular user is a child, COPPA's verifiable-parental-consent rules can apply. Many developers also now face state "age-appropriate design" laws aimed at teens. When in doubt, design age screening and data practices conservatively.

I just embed other companies' SDKs—am I responsible for what they collect? Yes. From a regulator's and a plaintiff's perspective, it is your app and your privacy policy. If an embedded analytics or advertising SDK exfiltrates location or device identifiers that your disclosures do not mention, you can be liable for the resulting deception or unfair practice regardless of whether you wrote the code. Auditing every SDK and what it collects is not optional housekeeping; it is core compliance.

Can I collect users' precise location to show them nearby content? You can, but only with genuine, specific consent obtained through an honest prompt, and you should collect the least precise location that supports the feature, prefer foreground-only access, and refrain from selling or "sharing" it with brokers. Precise geolocation is "sensitive data" under most state laws and a top FTC enforcement priority; treat it as high-risk and justify every use.

My app uses facial recognition for a fun filter. Is that a problem? It can be a serious one. If you have users in Illinois, the Biometric Information Privacy Act requires informed written consent before collecting face-geometry data, a published retention-and-destruction policy, and a ban on selling it—backed by statutory damages and a private right of action that has produced nine-figure settlements. Most comprehensive state laws also treat biometric data as sensitive. Get explicit consent and legal review before shipping any biometric feature.

I'm a U.S. developer with no European customers on purpose. Do I still have to think about the GDPR? Maybe. If your app is freely downloadable in EU app stores and you do nothing to block European users, you may be processing EU residents' data and within the GDPR's reach. If you genuinely do not target or serve the EU, the case for application is weaker, but the safest course is to decide deliberately—either build to a GDPR-aware baseline or actively restrict the EU market—rather than discover the issue after a complaint.

What happens if I have a data breach? You will likely face notification duties under the breach-notification laws of every state where affected users live, plus possible sectoral duties (HIPAA, the FTC Health Breach Notification Rule, GLBA, or the GDPR's 72-hour rule) and, often, regulatory scrutiny of whether your security was reasonable in the first place. Deadlines are short and vary by jurisdiction, so prepare an incident-response plan in advance. See cybersecurity incident response and IP protection.

Is "I clicked Accept" the end of the analysis? No. Consent has to match conduct and be honestly obtained. If the interface tricked the user—a dark pattern, a pre-checked box, a misleading prompt—California law and the GDPR may treat the "consent" as invalid, and the practice may be deceptive under FTC standards. Build symmetrical, neutral consent interfaces; an honestly obtained "yes" is the only one worth having.

Related articles

This article provides general information about mobile application privacy law and is not legal advice. Privacy law is fast-moving and varies by jurisdiction; for guidance on your specific app and data practices, consult qualified counsel.