Checklist · Technology

Launching a Mobile App: A Practical Legal Checklist

Type
Checklist
Jurisdiction
National
Date
2025-11-24
Topic
Technology

Finishing the build is where the legal work starts, and almost all of it belongs before the launch date rather than after the first demand letter. This checklist takes a founder, an in-house lawyer, or an interested non-lawyer from "feature complete" to "live in the store," ordered roughly by how badly each risk bites: a liability-shielding entity, present-tense IP assignments from every contractor, survival of Apple's and Google's developer agreements in a post-Epic world, an enforceable EULA and terms delivered by conspicuous clickwrap, a privacy policy that actually matches the store labels, the ROSCA and state auto-renewal minefield, ADA and WCAG accessibility, COPPA and the age-appropriate design codes, truthful advertising, open-source license compliance, and export and encryption rules. Each phase pairs checkboxes with the reason behind them, the traps that catch teams, worked hypotheticals, and the governing authority. The law here moves quickly; treat this as a detailed map and a research starting point, not a substitute for counsel who knows your facts.

Launching a Mobile App: A Practical Legal Checklist

Technology > App Development and Launch | Published 24 November 2025 - Updated 25 November 2025 | UpLaw - uplaw.us

A phase-by-phase pre-launch legal checklist for mobile apps, moving from entity and code ownership through platform agreements, EULAs and clickwrap, privacy, subscription law, accessibility, children's data, advertising, open source, and export controls, with the governing authority woven in.

Keywords: mobile app launch checklist, IP assignment, work made for hire, developer agreement, Epic v. Apple, Digital Markets Act, EULA, clickwrap, browsewrap, privacy policy, App Tracking Transparency, ROSCA auto-renewal, click to cancel, COPPA, ADA WCAG accessibility, open source license compliance, export controls encryption

There is a predictable moment in the life of every app. The build passes QA, the demo works twice in a row, and someone with authority over the calendar says the four most expensive words in software: "Let's ship it Monday." Writing the code was the tractable part. Code does what you tell it. The law does not, and it does not care that your sprint ended on Friday. The instant an app collects an email address, charges a card, serves an ad, speaks to a child, or simply sits on a store listing, it steps into a dense weave of federal statutes, state consumer-protection regimes, platform contracts nobody at your company negotiated, and open-source licenses somebody agreed to by copying a folder. None of that is a reason to panic. Nearly all of it is manageable if you take it in sequence and start before launch, while everyone is friendly and the code is still worth nothing.

This checklist is ordered the way risk actually arrives: roughly from "this can sink the company" down to "this generates an unpleasant letter." Each phase gives you the checkboxes, then the reasons, then the traps and worked examples, then the authority you can cite. It is deliberately deeper than a launch memo, because the person who most needs to understand these rules is often the founder reading at midnight, not the lawyer who will eventually paper them. For the companion narrative treatment, see UpLaw's guide From Feature-Complete to Live: A Legal Launch Guide for Mobile Apps; for the intellectual-property half of the story in more detail, see Intellectual Property Strategy for Mobile Apps: A Comprehensive Guide.

How to Read This Checklist

Two organizing ideas run underneath everything below. The first is sequence. Some legal problems are cheap to fix now and ruinous to fix later. Ownership of your own code is the archetype: a signed assignment costs a paragraph today and can cost a financing round in two years. Other problems are genuinely last-mile, like the exact wording of a store privacy label, and can wait until you know what the app finally does. Work the expensive-to-reverse items first. The second idea is documentation. Most of the disputes in this area are not close calls on the law; they are fights about what you actually did, when, and whether you can prove it. Consent logs, a version history for your terms, a software bill of materials, an accessibility audit, and a one-page export classification are not bureaucratic garnish. They are the evidence that decides the case. Build the paper trail as you build the app.

Phase One: Who Owns the Company, and Who Owns the Code

  • [ ] Form a liability-shielding entity (an LLC, or a Delaware C-corporation if you intend to raise venture capital) and have that entity own the app, sign the store agreements, and contract with users, before the app touches a single real user.
  • [ ] Respect corporate formalities: a separate bank account, no commingling of funds, adequate capitalization, and real records, so the liability shield actually holds.
  • [ ] Open an insurance conversation early: technology errors-and-omissions coverage, usually bundled with cyber-liability.
  • [ ] Paper every co-founder relationship in writing: equity splits, vesting, and what happens when someone leaves.
  • [ ] Collect a signed, present-tense IP assignment from every developer and contractor ("Contractor hereby irrevocably assigns all right, title, and interest..."), pairing a work-made-for-hire clause with a backup present assignment and a "further assurances" covenant.
  • [ ] Have every employee sign a proprietary-information-and-inventions-assignment (a PIIA) on day one, not at the exit interview.
  • [ ] Build a bill of materials listing every third-party and open-source component, and confirm you actually have the right to ship each one.

Stand the entity up before the app meets a user

An app is a product, and a product with users is a liability generator. It handles money, holds personal data, makes representations, and occasionally breaks in ways that harm people. If it does those things as you, personally, then a data breach, a payment dispute, or a disgruntled user's lawyer is aiming at your house, your savings, and your car. The entity is the blast wall. Form it first, and route everything through it: the store developer agreements, the payment processor relationship, the SDK licenses, the user contracts. An entity you form after signing the Apple agreement in your own name has not shielded you from the Apple agreement.

Choice of entity is a genuine fork, not a formality. A single-member LLC is cheap, simple, and pass-through for tax. A Delaware C-corporation is the standard vehicle if you plan to raise priced venture money, issue stock options, or hand equity to co-founders on a vesting schedule; investors expect it, and retrofitting it later triggers avoidable tax and legal friction. The mechanics of that choice, founder vesting, 83(b) elections, and the organizational paperwork, are their own subject; see Incorporating a Startup the Right Way: A Founder's Legal Checklist and The Startup Legal Document Stack: What Founders Need and Why.

The shield is not automatic just because you filed a certificate. Courts will pierce the corporate veil when the entity is a sham: commingled funds, no capitalization, no records, the owner treating the company bank account as a personal wallet. Keep the money separate, keep minutes and consents, and capitalize the thing enough to meet its foreseeable obligations. The formalities are boring precisely because they work.

The contractor ownership trap

Here is the fact that surprises nearly every first-time founder, and a fair number of experienced ones. If an independent contractor wrote your app and never signed an assignment, the contractor owns the copyright in that code, not you. Paying the invoice did not buy the intellectual property. It bought you, at most, an implied non-exclusive license to use what you paid for, which is a fragile thing to build a company on and a fatal thing to try to sell.

The reason is statutory and counterintuitive. Under the Copyright Act, a work is a "work made for hire", and thus owned by the hiring party from the moment of creation, in only two situations: (1) it was prepared by an employee within the scope of employment, or (2) it was specially ordered or commissioned and falls within one of nine enumerated categories and the parties signed a writing saying so. See 17 U.S.C. §§ 101, 201(a)-(b). Software is conspicuously absent from the nine commissioned categories. So a freelance developer is neither an employee nor producing a category of work that can be work-made-for-hire by commission. Absent a signed assignment, the copyright vests in the developer. The Supreme Court drew the employee-versus-contractor line using common-law agency factors, control over the manner and means of work, the skill required, who supplies the tools, the tax treatment, and more, in Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989). Most app developers land squarely on the contractor side of that line. UpLaw's Determining Work Made for Hire: A Practical Checklist walks the analysis category by category.

The fix is a drafting move, and it has to be done right. A pure "work made for hire" clause is not enough, because if a court later decides the work was not eligible for that status, the clause does nothing and you own nothing. The belt-and-suspenders solution is language that (1) recites work-made-for-hire status where applicable, and (2) adds a present-tense assignment as a backup: "to the extent any deliverable is not a work made for hire, Contractor hereby irrevocably assigns to Company all right, title, and interest therein." The word "hereby" matters. A promise to assign in the future ("Contractor agrees to assign") can leave a gap that requires a second signature you may never get, a lesson the Federal Circuit taught in the patent context in Board of Trustees of the Leland Stanford Junior University v. Roche Molecular Systems, Inc., 563 U.S. 776 (2011). Add a "further assurances" covenant so the contractor must sign whatever confirmatory documents a future acquirer's lawyers demand. The same present-assignment discipline governs your employees; the drafting nuances, including state carve-out statutes and holdover clauses, are covered in Employee Invention Assignment Agreements: Securing Clean Title Across Jurisdictions.

A worked example. Imagine "Cairn," a hypothetical hiking-route app. Two founders sketch the idea; a freelance iOS developer named Priya builds the core routing engine over four months, invoicing hourly, working from her own laptop, on her own schedule. Everyone is delighted. Eighteen months later a strategic acquirer offers a nine-figure deal, and its diligence team asks a routine question: show us the chain of title to the routing engine. There is no assignment. Priya, now running a competing consultancy, is under no obligation to sign one, and she has read the term sheet too. Best case, Cairn pays her a "further assurances" ransom priced to the deal. Worst case, the acquirer walks. All of it was preventable with one paragraph signed while Priya was still friendly and the engine was worth nothing. Collect the assignments now.

Employees, PIIAs, and the bill of materials

Employees are lower-risk than contractors on ownership, because scope-of-employment work is generally work made for hire, but "generally" is not "always," and side projects, pre-employment code, and moonlighting all blur the line. A proprietary-information-and-inventions-assignment executed on the first day closes those gaps and doubles as a confidentiality agreement. Finally, before launch, inventory everything you did not write: every SDK, library, font, icon set, and open-source package, with its license. That inventory, a software bill of materials, is the foundation for the open-source and export analysis in Phase Six, and it is far easier to build as you go than to reconstruct under deal pressure. For the broader picture of how copyright, patent, trade secret, and contract stack on top of a codebase, see How the Law Protects Software: Copyright, Patents, Trade Secrets, and Contract Rights, and for the app-specific layer map, Protectable Assets in a Mobile App: An IP Layer-by-Layer Guide.

Phase Two: The Gatekeepers, Apple and Google, in a Post-Epic World

  • [ ] Read and comply with the Apple Developer Program License Agreement, the Google Play Developer Distribution Agreement, and the program guidelines that apply to your categories (health, finance, and kids' content carry extra rules).
  • [ ] Understand the commission structure (historically 30%, often 15% for small developers and for subscriptions after the first year) and the platform's unilateral right to reject or remove your app.
  • [ ] Adopt the platform-required EULA pass-through and third-party-beneficiary terms.
  • [ ] Design for review: privacy disclosures, age ratings, permission prompts, and metadata built to pass on the first submission.
  • [ ] Decide your steering strategy jurisdiction by jurisdiction: in the U.S., post-Epic, you may direct users to a cheaper external checkout; in the EU, the Digital Markets Act opens alternative stores, sideloading, and third-party payments.
  • [ ] Comply first; strategize second. Do not attempt an Epic-style deliberate breach.

The developer agreements are contracts, and they are adhesion contracts

The platforms do not think of your app as your app. They think of it as content they distribute under their contract, on their terms, subject to their guidelines, removable at their discretion. The Apple and Google developer agreements are take-it-or-leave-it adhesion contracts, and they are contracts of real force. They dictate your commission, your permitted content, your data practices, your update obligations, and the conditions under which your listing disappears. Read the ones that apply to your categories, because the category-specific rules, HealthKit restrictions, financial-services requirements, the kids' programs, are where launches actually stall.

Two commercial realities deserve emphasis. First, the commission is a tax on your revenue, classically 30%, reduced to 15% under the small-business programs and for long-tenured subscriptions, and it changes the economics of your pricing model before you write a line of your paywall. Second, the platform can reject or remove you, and "we were about to close a round" is not an appeal. Build to pass review the first time: honest age ratings, permission prompts that match what you actually collect, and privacy metadata that lines up with your policy (a mismatch is not just a store problem, as Phase Three explains).

Steering, Epic, and the geography of your rights

For years the received wisdom was that the platform's rules were the whole universe. Then Epic Games deliberately routed around Apple's in-app-purchase system to trigger a test case, and the resulting litigation reshaped the edges of that universe, if not its core. Epic mostly lost on antitrust: the Ninth Circuit affirmed that Apple's model was not an unlawful monopoly under the Sherman Act. Epic Games, Inc. v. Apple Inc., 67 F.4th 946 (9th Cir. 2023); the Supreme Court denied certiorari to both sides in January 2024. Apple's basic business model survived intact. But Epic won on one consequential point: the district court found Apple's anti-steering rules, the provisions that barred developers from telling users about cheaper purchase options outside the app, an unfair business practice under California's Unfair Competition Law, and enjoined them. That injunction has teeth. In 2025 the district court held Apple in contempt for complying grudgingly, having imposed a new commission on external-link purchases and surrounded the links with discouraging "scare screens," and ordered Apple to stop charging on external purchases and to stop degrading the links. The practical upshot: in the United States, you may now steer users to a web checkout and keep more of the revenue, subject to the evolving contours of that order.

Your rights genuinely differ by country. In the European Union, the Digital Markets Act, Regulation (EU) 2022/1925, designates large platforms as "gatekeepers" and forces open what the U.S. antitrust suit did not: alternative app stores, sideloading, and third-party payment systems, along with anti-steering prohibitions of its own. In South Korea, an amendment to the Telecommunications Business Act pushed the platforms toward allowing alternative in-app payment options before either the U.S. or the EU moved. The result is that "our monetization strategy" is now a multi-jurisdiction question. What you may do in Brussels, San Francisco, and Seoul is not the same, and a global launch that assumes one rulebook is a global launch making three different mistakes. The one universal lesson from Epic is procedural: comply first, then advocate for change through lawful channels. Epic's deliberate breach cost it years and most of its claims. Do not reenact it.

Phase Three: The Documents the Law Makes You Write

  • [ ] Draft a EULA that grants a limited, revocable, non-exclusive, non-transferable license, expressly reserves everything else, and houses the warranty disclaimers, the limitation of liability, and the platform's third-party-beneficiary clause.
  • [ ] Draft terms of service covering acceptable use, any user-content license, payment, dispute resolution (arbitration and class-action waiver), governing law, and termination; the EULA and terms are often merged into one document.
  • [ ] Deliver assent through a conspicuous, logged clickwrap: "By tapping Continue, you agree to our Terms and Privacy Policy," with both phrases as live links, capturing timestamp, agreement version, and device or IP.
  • [ ] Publish a privacy policy that accurately describes your real data practices and matches your store privacy labels (Apple's App Privacy and App Tracking Transparency; Google Play's Data Safety section).
  • [ ] Scale your privacy obligations to what you collect and whom you serve (CCPA/CPRA and the growing state patchwork, GDPR, sector-specific rules), and build data minimization and storage limits in from the start.

What the EULA and the terms actually do

The end-user license agreement answers a question users never ask but courts take seriously: what, exactly, did the user get? Not ownership of the software, a license to use it, and the EULA defines that license's edges, limited, revocable, non-exclusive, non-transferable, and reserves every right you did not grant. It is also the natural home for the risk-allocation clauses that decide what a bug or an outage costs you: the warranty disclaimer ("as is," no implied warranties of merchantability or fitness) and the limitation of liability (capping damages, excluding consequential loss). Because the platforms require it, the EULA also carries a clause naming Apple and Google as third-party beneficiaries entitled to enforce it against your users. For the full anatomy of these documents, including the crucial and often-missed distinction between a license covenant and a license condition, see Anatomy of a Software License Agreement: A Comprehensive Guide and Software License Agreements: Key Terms and How to Negotiate Them.

The terms of service govern the relationship rather than the software: what users may and may not do, who owns and who licenses user-generated content, how payment works, and, critically, how disputes get resolved. The dispute-resolution clause, an arbitration provision paired with a class-action waiver, is often the single most valuable paragraph in the document, because it can convert a potential class action into a series of individual arbitrations. Whether that is the right choice, and how to draft it to survive challenge, is a strategic question addressed in Choosing a Dispute-Resolution Forum: Litigation, Arbitration, and Mediation Compared and the Arbitration and ADR Toolkit. If your app hosts user content, the terms are also where you take the content license you need and where Section 230 and DMCA safe-harbor strategy begins; see Section 230, the IP Carve-Out, and Platform Liability for User-Generated Infringement.

Making the agreement stick: clickwrap versus browsewrap

None of these carefully drafted terms is worth anything unless the user is bound by them, and enforceability turns almost entirely on how the user agreed. This is the most litigated, and most avoidable, failure in the whole checklist. Courts sort the presentation methods along a spectrum.

At the enforceable end sits clickwrap: the user is shown the terms, or a conspicuous link to them, and must take an affirmative act, ticking a box, tapping "I Agree", to proceed. Clickwrap is routinely enforced. The lineage runs back to ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996), which upheld terms presented on screen and accepted by conduct, and it has hardened into a reliable rule. The Second Circuit's decision in Meyer v. Uber Technologies, Inc., 868 F.3d 66 (2d Cir. 2017), is the modern template for mobile: it enforced a "sign-in wrap" where a reasonably conspicuous notice told users that creating an account meant agreeing to the terms, and the terms were an obvious hyperlink, holding that a reasonably prudent smartphone user would understand they were assenting.

At the unenforceable end sits browsewrap: terms posted somewhere on the site or in a settings screen, with no notice and no click, on the theory that continued use equals agreement. Courts frequently refuse to enforce browsewrap because the user had no reasonable notice and manifested no assent. The canonical warning is Specht v. Netscape Communications Corp., 306 F.3d 17 (2d Cir. 2002), where terms below the "Download" button, out of view, did not bind users, in an opinion by then-Judge Sotomayor. The Ninth Circuit reinforced the point in Nguyen v. Barnes & Noble Inc., 763 F.3d 1171 (9th Cir. 2014): a "Terms of Use" hyperlink in the page footer, without more, does not put a reasonable user on notice, and there is no duty to hunt for it. The lesson is blunt. Design a real clickwrap: unavoidable, conspicuous, with the terms one tap away, requiring a deliberate act to continue.

Then log the assent, because in litigation the question is not "do you have terms?" but "can you prove this user agreed to this version on this date?" Capture and retain the user identifier, the timestamp, the exact version of the terms and privacy policy accepted, and the device or IP. When the app updates its terms, present the new version and re-collect assent rather than assuming the old click carries forward. Those records are evidence, and the discipline of authenticating them in court is its own craft; see Getting Website Evidence Admitted: A Practical Authentication Checklist. The flip side, how terms-of-service assent interacts with unauthorized-access and scraping claims, is explored in Web Scraping and the Law After hiQ v. LinkedIn.

The privacy policy that must match the label

A privacy policy is not optional decoration. California's Online Privacy Protection Act (CalOPPA), Cal. Bus. & Prof. Code § 22575, requires a conspicuously posted privacy policy for any commercial online service that collects personally identifiable information from California residents, which is to say, effectively every app. Both stores independently require a policy and a privacy label. So you will write one regardless of whether any single statute names your app.

The trap is not the existence of the policy; it is the accuracy of it. A privacy policy that misdescribes what you actually collect, share, or sell is not a paperwork slip. It is a deceptive act under Section 5 of the FTC Act, 15 U.S.C. § 45(a), and the Federal Trade Commission has built a long enforcement record on exactly that theory. The classic cautionary tale is the FTC's action against the maker of a "Brightest Flashlight" app, which told users almost nothing about the fact that it was transmitting precise location data to third parties, precisely the gap between the stated policy and the actual practice that triggers Section 5. The modern version of the same problem is the label mismatch: your Apple App Privacy disclosure or Google Play Data Safety form says one thing, and your privacy policy, or your SDK's actual behavior, says another. Regulators read both. Reconcile the policy, the store labels, and the code before you ship, and treat any divergence as a bug to fix, not a nuance to explain later.

Scaling privacy to what the app does

Privacy obligations are not one-size-fits-all; they scale to your data and your users. The floor is the FTC's Section 5 deception-and-unfairness authority, which reaches everyone. Above that sits a fast-multiplying state patchwork: California's CCPA as amended by the CPRA (Cal. Civ. Code § 1798.100 et seq.) leads, but Virginia, Colorado, Connecticut, Utah, Texas, and more than a dozen other states now have comprehensive consumer-privacy statutes, each with its own thresholds, consumer rights, and definitions of "sensitive" data. If you have users in the EU or the UK, the General Data Protection Regulation, Regulation (EU) 2016/679, imposes a stricter regime built on a lawful basis for processing, genuine consent, transparency, and data-subject rights; cross-border data flows out of the EU carry their own overlay, examined in Moving Personal Data Out of the EU After Schrems II. If your app reads faces or voices, biometric-specific statutes like Illinois's BIPA add consent and liability rules with real bite, surveyed in Biometric Privacy Law and the AI Systems That Read Faces and Voices.

The strategic move that quietly prevents most of these problems is data minimization: collect only what the feature genuinely needs, keep it only as long as you need it, and delete on a schedule. Data you never collected cannot be breached, subpoenaed, mislabeled, or sold in violation of a promise. Minimization is both a GDPR and CCPA obligation and, increasingly, an FTC expectation; UpLaw covers the operational program in Data Minimization and Storage Limitation. For the full app-privacy map, see Mobile App Privacy Law: A Compliance Map for Founders and Counsel, and to stand up the underlying program, Building a Privacy Compliance Program: Governance, Data Mapping, and the Legal Patchwork with its companion checklist.

Phase Four: Charging Money Without Surprising Anyone

  • [ ] If you use an auto-renewing subscription or any negative-option offer, comply with ROSCA (15 U.S.C. §§ 8401-8405): clearly and conspicuously disclose all material terms (the recurring charge, the amount, the frequency, and the deadline to cancel) before obtaining billing information, get the consumer's express informed consent, and provide a simple cancellation mechanism.
  • [ ] Build to the strictest state automatic-renewal law, California's (Cal. Bus. & Prof. Code §§ 17600-17606), and apply it everywhere: clear disclosure in visual proximity to the consent, affirmative consent to the renewal terms, an acknowledgment with cancellation instructions, and online click-to-cancel.
  • [ ] Capture and log the affirmative consent (for example, the "Start Free Trial" tap tied to a specific set of terms) and send a confirmation email restating the terms and how to cancel.
  • [ ] Make cancellation obvious and functional without a phone call. The platform manages in-app subscriptions on its own rails; any web billing flow is entirely your responsibility.
  • [ ] If you process payments directly, use a compliant processor and keep raw cardholder data out of your systems (PCI DSS).

The fastest way to attract a regulator

Nothing draws an enforcement action faster than charging people in a way that surprises them. "Negative option" is the umbrella term for any arrangement in which a seller treats the consumer's failure to act as consent to be billed, the album-of-the-month club reborn as the free trial that silently converts. The federal anchor is the Restore Online Shoppers' Confidence Act, 15 U.S.C. §§ 8401-8405, which for online negative-option sales requires three things: (1) clear and conspicuous disclosure of all material terms before obtaining the consumer's billing information, (2) the consumer's express informed consent before the charge, and (3) simple mechanisms to stop recurring charges. Layered on top are the FTC's Negative Option Rule, 16 C.F.R. Part 425, the Telemarketing Sales Rule where phones are involved, 16 C.F.R. § 310, the FTC's Enforcement Policy Statement on negative-option marketing, and the ever-present Section 5, 15 U.S.C. § 45(a). The FTC treats a hard-to-cancel subscription, a hidden auto-renewal, or a "dark pattern" that nudges users into recurring charges as a deceptive or unfair practice.

The state laws are stricter, and several bite back

The states did not wait for Washington. California's Automatic Renewal Law, Cal. Bus. & Prof. Code §§ 17600-17606, is the strictest and, because compliance is easiest to standardize on the toughest rule, the one to build to nationwide. It requires the automatic-renewal terms to be presented clearly and conspicuously, in visual proximity to the request for consent; it requires the consumer's affirmative consent specifically to those terms; it requires an acknowledgment that includes the terms, the cancellation policy, and how to cancel; and it requires that a consumer who signed up online be able to cancel online, no phone tree, no retention-agent gauntlet. Similar statutes now exist across many states, several carrying private rights of action and statutory-damages exposure, which means the plaintiffs' bar, not just a regulator, is watching. Design one compliant flow to the California standard and deploy it everywhere; maintaining fifty flows is how mistakes happen.

A worked example. Picture "Lull," a hypothetical sleep-and-meditation app. Its growth team ships a paywall: a big "Start 7-Day Free Trial" button, and, in pale gray six-point type well below the fold, the disclosure that the trial converts to $79.99 per year unless cancelled at least 24 hours before it ends. The button captures a tap; nothing captures the user's specific consent to the renewal terms, which most users never scrolled to see. Cancellation requires emailing support and waiting for a reply. Every element of that flow is a violation waiting for a plaintiff: the material terms are neither clear, conspicuous, nor in visual proximity to consent; there is no logged affirmative consent to the renewal; and cancellation is neither simple nor online. The fix is not cosmetic, it is a redesign: renewal terms in plain, legible type directly adjacent to the button, a checkbox or unmistakable action tied to those specific terms, a confirmation email restating everything, and a one-tap cancel inside the app. Cheaper than the class action, and far cheaper than the consent decree.

"Click to Cancel" was vacated, so do not relax

Timing matters here, and the news can mislead. In 2024 the FTC finalized an amended Negative Option Rule, widely called the "Click to Cancel" Rule, that codified much of what the state laws already demanded. In July 2025 the Eighth Circuit vacated that amended rule on procedural grounds, essentially, the Commission's failure to complete a required preliminary regulatory analysis, without blessing hidden subscriptions or hard cancellations on the merits. It is tempting to read the vacatur as a reprieve. It is not. ROSCA itself, unamended, still requires simple cancellation and up-front consent. The FTC still brings negative-option cases under ROSCA and Section 5. And the state automatic-renewal laws, which the vacated rule largely mirrored, remain in full force, many with private enforcement. The safe posture is unchanged: build to the strictest state standard and apply it across the board. A federal rule coming or going does not move the floor.

Finally, on payments themselves: if you charge through the platform's in-app-purchase system, the platform handles the card data and much of the subscription plumbing. If you take payment on the web or directly, you own PCI DSS compliance, and the sane architecture keeps raw cardholder data out of your servers entirely by tokenizing through a compliant processor. Data you never touch is a breach you never have.

Phase Five: What the App Does Triggers Special Duties

  • [ ] Run an accessibility audit against WCAG 2.2 Level AA, use the native iOS and Android accessibility features (screen-reader labels, sufficient contrast, captions or transcripts for audio), publish an accessibility statement, and provide a way to report barriers.
  • [ ] If your app is directed to children under 13, or you have actual knowledge you are collecting their data, build the COPPA machinery: clear notice, verifiable parental consent before collection, data minimization, no behavioral ad tracking on child-directed content, and parental review and deletion, and enroll in the platforms' kids' programs.
  • [ ] Remember that COPPA "personal information" includes geolocation, voice recordings, photos, and persistent identifiers; the FTC amended the COPPA Rule in 2025; and state age-appropriate design codes add further duties.
  • [ ] Make every advertising claim true and substantiated, disclose influencer material connections under the FTC Endorsement Guides, avoid fake or AI-generated reviews, and mind health claims and clear-and-conspicuous mobile disclosures.
  • [ ] Apply CAN-SPAM to commercial email and the TCPA to marketing texts and push notifications, and pick an honest age rating at submission.

Accessibility: the liability nobody sees until the letter arrives

Accessibility is the risk that stays invisible right up until a demand letter lands, because a fully functional app can be completely unusable to someone relying on a screen reader, and the team that built it will never notice. Title III of the Americans with Disabilities Act, 42 U.S.C. § 12181 et seq., prohibits discrimination in the goods and services of "places of public accommodation," and the open question, litigated for two decades, is how far that phrase reaches into software. The law is genuinely unsettled and splits by circuit. The Ninth Circuit, in Robles v. Domino's Pizza, LLC, 913 F.3d 898 (9th Cir. 2019), cert. denied, 140 S. Ct. 122 (2019), held that the ADA covered the pizza chain's website and app because they connected customers to the goods and services of physical restaurants, the so-called nexus theory. Other courts are more skeptical that a purely online business, with no brick-and-mortar tie, is a "place" at all. The doctrinal uncertainty is real, but the practical exposure is not uncertain: thousands of accessibility suits and demand letters are filed every year, and many settle regardless of the underlying merits because litigating is more expensive than fixing.

The engineering answer is to design to the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, the de facto standard courts, regulators, and settlement agreements reference even though it is not itself a statute. That means labeled controls a screen reader can announce, sufficient color contrast, captions or transcripts for audio and video, and support for the native accessibility features Apple and Google already provide. Publish an accessibility statement and give users a channel to report barriers. Doing so both reduces the population you are excluding and, if a suit comes, demolishes the "the company never even tried" narrative that drives up settlements.

Children: COPPA and the age-appropriate design codes

Children's data is the fastest route from "we'll handle it later" to a seven-figure penalty. The Children's Online Privacy Protection Act, 15 U.S.C. §§ 6501-6506, and the FTC's implementing COPPA Rule, 16 C.F.R. Part 312, govern the online collection of personal information from children under 13. COPPA applies to an operator of a website or online service that is directed to children, or that has actual knowledge it is collecting personal information from a child under 13. Where it applies, the obligations are demanding: post a clear online privacy notice describing your practices; obtain verifiable parental consent before collecting, using, or disclosing a child's personal information (16 C.F.R. § 312.5); collect no more than is reasonably necessary; give parents the ability to review, delete, and stop further collection; and keep the data secure. See 15 U.S.C. § 6502(b). Two definitions catch teams off guard. "Personal information" under COPPA is broad, reaching geolocation, voice and video recordings, photographs, and persistent identifiers like device IDs and cookies used for behavioral advertising. And "actual knowledge" is exactly the kind of fact that internal emails and Slack messages establish in discovery, which is why deciding deliberately whether to be a kids' app matters so much.

The enforcement is not theoretical. The FTC's landmark 2022 action against Epic Games over Fortnite produced a $275 million civil penalty for COPPA violations, part of a half-billion-dollar package that also addressed dark-pattern purchasing, a number that concentrates the mind. The FTC amended the COPPA Rule in 2025, tightening consent, data-retention, and third-party-disclosure requirements. And the states have pushed further with age-appropriate design codes, most prominently California's, which impose data-protection-by-default duties for services likely to be accessed by minors; those laws face ongoing First Amendment challenges (a federal court partially enjoined California's version), so their exact contours are in motion. If children are anywhere near your user base, treat COPPA as a design constraint from the first wireframe, not a compliance chore bolted on at the end, and enroll in the platforms' dedicated kids' programs, which carry their own stricter rules.

Truthful advertising, endorsements, and reviews

Everything your marketing says is regulated. Under Section 5 of the FTC Act, advertising claims must be truthful and substantiated before you make them, objective performance claims need a reasonable basis in evidence, not aspiration. If you work with influencers, the FTC's Endorsement Guides, 16 C.F.R. Part 255, require clear disclosure of any material connection between you and the endorser, and "material connection" includes free product, affiliate commissions, and, obviously, cash. Fake reviews and AI-generated testimonials have become a specific FTC target, with a dedicated rule prohibiting them; do not seed your own five-star reviews or buy them. If your app touches health, weight, mental health, or medical claims, you are near the FDA's line and the FTC's heightened substantiation expectations, tread carefully. And on a small screen, "clear and conspicuous" is a real design constraint: a disclosure buried behind a hyperlink or set in three-point gray type is, for legal purposes, not a disclosure. UpLaw's Advertising Law for Small Businesses: A Practical FAQ covers the substantiation and endorsement rules in plain terms; competitor-versus-competitor claims raise separate Lanham Act exposure, mapped in False Advertising Under Lanham Act Section 43(a).

Email and push: CAN-SPAM and the TCPA

Two more regimes govern how you reach users after they leave the app. The CAN-SPAM Act, 15 U.S.C. §§ 7701-7713, governs commercial email: honest headers and subject lines, a valid physical postal address, a clear and working opt-out that you honor within ten business days, and identification of the message as an advertisement where required. The primary-purpose test decides which messages count as "commercial," and the mechanics reward suppression-list discipline; see CAN-SPAM Compliance for Commercial Email: A Comprehensive Guide and its operational checklist. Marketing by text message, and in some readings by push notification with marketing content, implicates the Telephone Consumer Protection Act, 47 U.S.C. § 227, which requires prior express consent for many marketing communications and carries statutory damages per message, an economic structure that has made TCPA class actions a cottage industry. Get consent, keep proof of it, and honor opt-outs promptly.

Phase Six: Components You Didn't Write and Borders You Didn't See

  • [ ] Run a software-composition-analysis scan, generate a software bill of materials (SBOM), identify the license on every component, and confirm that nothing copyleft (GPL or AGPL) has entered your distributed binary in a way you have not isolated or fully complied with.
  • [ ] Satisfy the easy obligations: attribution and license-text notices for MIT, BSD, and Apache components, typically surfaced in an "Open Source Licenses" screen in settings.
  • [ ] Audit commercial third-party agreements too, the analytics SDK, the maps provider, the push service, the ad network, the font license, because a single data-hungry SDK has been the root of more than one enforcement action.
  • [ ] Confirm your encryption is standard, publicly available, and qualifies for the applicable EAR license exception (most mass-market apps do, often with only a self-classification).
  • [ ] Do not distribute to sanctioned or embargoed destinations or to prohibited parties, and keep a one-page export-classification record.

Open source is free as in freedom, not free of obligation

Modern apps are assembled as much as authored, and most of the assembled parts are open-source software. Open source is not public domain; every open-source component arrives under a license, and the license carries conditions. The permissive licenses, MIT, BSD, Apache 2.0, ask only for attribution: preserve the copyright and license notices, usually surfaced in an "Open Source Licenses" screen. That is the easy tier, and skipping even it is a needless breach.

The hard tier is copyleft. The GPL family is engineered to be "viral": if you incorporate GPL-licensed code into your program and distribute the result, the license can obligate you to release the entire derivative work under the GPL, including your own source code. For a networked service, the ordinary GPL contains a distribution loophole, running software on a server is arguably not "distributing" it, and the AGPL exists specifically to close that loophole by treating network interaction as a trigger. Getting the copyleft analysis wrong is not a mere contract problem. Violating an open-source license can be copyright infringement, with the license conditions functioning as limits on the scope of the grant; the Federal Circuit established that framing in Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), holding that the conditions in an open-source license are enforceable copyright conditions, not merely covenants. Courts have since enforced the GPL as both a copyright license and a contract, including in disputes brought by the Free Software Foundation's allies and by individual developers. The practical program, scanning, an SBOM, license classification, copyleft isolation, and remediation, is laid out in Open Source Software Compliance: A Practical Checklist, with the doctrinal background in Open Source Software Licenses, Compliance, and Risk: A Comprehensive Guide and the enterprise-scale pitfalls in Open Source Licensing Traps in Enterprise Software.

A worked example. Suppose "Cairn," our hiking app from Phase One, needs offline map rendering, and a contractor drops in a slick rendering library to hit the deadline. Nobody checks the license; it is AGPL-3.0. Cairn ships. Months later a competitor, or the library's maintainer, notices Cairn's map screen and asks a pointed question: where is your corresponding source? Because the AGPL's network-use trigger and copyleft reach can extend to the surrounding code, Cairn faces a genuinely bad menu, rip the library out and rebuild the feature, negotiate a commercial relicense if one is even offered, or open-source code it never intended to publish, all under the shadow of a copyright-infringement claim rather than a mere breach. A five-minute license check during the code review would have flagged the component before it ever touched the binary. Scan before you ship.

Commercial SDKs and the data they quietly eat

The same "someone else wrote it" risk applies to commercial third-party code, with a privacy twist. Analytics SDKs, ad networks, attribution tools, and even some map and font providers collect data, sometimes a great deal of it, and route it off the device. Two obligations follow. First, honor the SDK's own license terms. Second, and more dangerous, account for what the SDK does with user data, because your privacy policy and store labels have to reflect the SDK's behavior, not just your own first-party collection. Regulators have repeatedly pursued app makers, and the data brokers behind their SDKs, over undisclosed location and behavioral tracking; the FTC's recent enforcement wave against location-data brokers is a direct warning to the apps that embed them. When you drop in an SDK, you are adopting its data appetite as your own. Diligence the ones that touch user data as seriously as you diligence the copyleft ones.

Export controls and encryption

Putting an app on a global store is, as a matter of law, exporting software, and software that contains encryption is subject to the U.S. Export Administration Regulations (EAR), 15 C.F.R. §§ 730-774, administered by the Commerce Department's Bureau of Industry and Security. For most consumer apps this is a manageable, box-checking exercise rather than a crisis: encryption that is standard, publicly available, and used for ordinary purposes, HTTPS, TLS, and the like, generally qualifies for a license exception (the encryption controls live in Category 5, Part 2 of the Commerce Control List, with License Exception ENC and the mass-market provisions at 15 C.F.R. § 740.17 doing the heavy lifting), often requiring at most a self-classification report. The genuinely regulated cases are apps whose encryption is the product: a novel privacy messenger, a security tool, a cryptocurrency wallet doing something unusual with cryptography. Those deserve specific export advice before launch.

Two rules apply to every app regardless of encryption. First, you may not distribute to embargoed or sanctioned destinations, or to prohibited persons, the OFAC-administered sanctions programs at 31 C.F.R. Parts 500-599 and the BIS entity and denied-persons lists, so your distribution settings and any direct downloads should exclude them. Second, keep a short written record of your export classification and the exception you rely on. It takes a page, and it is the document that turns a frightening regulatory inquiry into a routine one. The general framework, EAR, ITAR, OFAC, and the deemed-export concept for foreign nationals on your team, is broader than any one app needs, but the classification discipline is universal.

The Pre-Launch Sequence, Reassembled

Read as one arc, the six phases form a priority order that maps neatly onto how the risks arrive.

First, the foundations that are painful to fix retroactively. An operating entity owns everything. Signed, present-tense IP assignments come in from every developer and contractor. You hold clean title to every third-party and open-source component. Get this wrong and you discover it during a financing or an acquisition, at the worst possible leverage.

Second, the gate and the contracts. Comply with the Apple and Google developer agreements, adopting their required pass-through terms. Stand up a real EULA and terms of service delivered through a conspicuous, logged clickwrap. Publish a privacy policy that matches your store labels and your actual code.

Third, the consumer-law layer that draws regulators. Build the ROSCA and state auto-renewal flow to the strictest standard. Use compliant payments. Make every advertising claim true and substantiated.

Fourth, the duties triggered by what the app actually does. COPPA and the kids' programs if children are near your audience. ADA and WCAG accessibility. CAN-SPAM and TCPA hygiene for your messaging. Export and encryption classification for global distribution.

Throughout, document the decisions. Consent logs, a terms version history, an SBOM, an accessibility audit, an export-classification memo. In this field the law is rarely the hard part; proving what you did is. For a consolidated view of the same journey told as narrative, see From Feature-Complete to Live: A Legal Launch Guide for Mobile Apps.

Common Mistakes

  • Shipping as a person instead of behind an entity and insurance, so a breach or a payment dispute reaches the founder's house and savings.
  • Assuming that paying for development means owning the code. For a contractor, absent a signed present-tense assignment, it usually does not, and the gap surfaces at the worst moment.
  • Clicking "I agree" to the developer agreements without reading them, then being surprised by the commission, the content rules, or a removal.
  • Delivering terms by browsewrap or a buried settings link, producing a document a court will treat as a wish rather than a contract.
  • Letting the privacy policy and the store privacy labels disagree, which regulators read as FTC-grade deception rather than a formatting slip.
  • Relaxing on auto-renewal because "Click to Cancel" was vacated. ROSCA and the state laws still require conspicuous up-front terms and easy cancellation, several with private rights of action.
  • Treating accessibility, COPPA, or an SDK's data appetite as post-launch cleanup, until a demand letter, a class action, or a consent decree makes it Priority One.
  • Dropping in an open-source or commercial component without checking its license or its data behavior, and inheriting a copyleft obligation or a privacy violation you never chose.

Primary Authority

Confirm current commission terms, penalty amounts, rule status, and state-law thresholds against official sources before relying on them; several of these regimes are in active flux.

Related UpLaw Resources

Related Guides

Related Articles

Related Checklists

Related Toolkits

This checklist provides general information, not legal advice. The law governing mobile apps, privacy, platform rules, consumer protection, accessibility, and children's data, is complex, varies by state and country, and changes quickly; consult qualified counsel about your specific facts before you launch.