There is a peculiar moment in the life of every app. The build is finished. The demo works. The team has stopped fixing bugs long enough to high-five each other, and someone says the fatal words: "Let's ship it tomorrow." That sentence has launched a thousand lawsuits.

Because here is the uncomfortable truth that nobody tells you at the hackathon: writing the code is the easy part. The code does what you tell it to. The law does not. The moment your app collects an email address, charges a credit card, shows an ad, talks to a child, or simply sits on the App Store, it walks into a thicket of federal statutes, state consumer-protection laws, platform contracts you never negotiated, open-source licenses you may not have read, and at least one regulator who would love to make an example of you. The good news—and this guide is built around it—is that almost all of this is manageable if you take it in order and start before the launch party.

This article is the post-build legal checklist. It assumes you (or a developer you hired) have already created something, and now you need to get it safely into the world and keep it there. We will move roughly in the order that the risks bite: first the foundational decisions (who owns this, and who gets sued), then the gatekeepers (Apple and Google), then the documents the law makes you write (EULA, terms of service, privacy policy), then the consumer-protection minefield around money and subscriptions, then the obligations you might not have known existed (accessibility, kids, advertising, export controls, open source). Along the way we will follow a running example: Acme Calm, a fictional meditation-and-sleep app built by Acme Wellness, Inc., that offers a free tier, a $9.99/month auto-renewing "Premium" subscription, some guided meditations for children, a few ads, and a community feature. Acme Calm is invented, but every problem it stumbles into is real.

If you want the upstream companion to this piece—how to protect what you built rather than how to deploy it—see Protecting Your Mobile App: A Comprehensive IP Strategy Guide and Intellectual Property Considerations and Protectable Content in Mobile Apps. This guide is the deployment side of that coin.

First Things First: Put a Liability Shield Between You and the World

Before we talk about Apple or privacy policies, talk to yourself about who is shipping this app. If the answer is "me, personally," stop. An app is a product that goes to potentially millions of strangers, processes their data, takes their money, and can crash, leak, mislead, or offend. Each of those is a potential claim, and a claim against a sole proprietor or a general partnership reaches the founder's house, savings, and car.

The standard, boring, correct answer is to form a limited-liability entity—usually a limited liability company (LLC) or a corporation—and have that entity own the app, sign the developer agreements, and contract with users. The entity is the legal "person" that goes to the store and signs the contracts; if it gets sued, the corporate veil generally limits creditors to the company's assets rather than the founders' personal ones, provided you respect the formalities (separate bank account, no commingling, adequate capitalization, real corporate records). For a venture you hope to raise money on, a Delaware C-corporation is the conventional choice because investors and standard financing documents expect it; for a lifestyle app you intend to bootstrap, an LLC is often simpler and cheaper. We won't relitigate the entity-choice debate here—Popular Legal Documents for Startups walks through formation documents, founders' agreements, and the rest of the paperwork—but the principle is non-negotiable: the app should be owned and operated by an entity, not a human, before it touches a single user.

Two related housekeeping items belong here. First, get an insurance conversation going early. A technology errors-and-omissions (E&O) policy, often bundled with cyber-liability coverage, is the backstop for the day a data breach or a buggy update causes real loss. Second, if you have co-founders, paper the relationship—equity splits, vesting, what happens if someone leaves—because the single most common way an app dies is not a competitor or a regulator but a founder fight over ownership. Which brings us to the most important question on this entire list.

Who Actually Owns the Code? The Assignment Problem

Here is a fact that surprises almost everyone the first time they hear it: if you hired an independent contractor to build your app, you probably do not own the code—the contractor does—unless you got a written assignment.

This is a quirk of U.S. copyright law, and it has sunk more startups than any bug. Under the Copyright Act, the author of a work owns the copyright the instant the work is fixed (17 U.S.C. § 201(a)). For employees, there is a friendly default: works an employee creates within the scope of employment are "works made for hire," and the employer is treated as the author and owner (17 U.S.C. § 101; § 201(b)). But for independent contractors—the freelance developer, the offshore dev shop, the "random guy" who built your MVP for equity—that default flips. Software is not one of the nine enumerated categories that can be a work made for hire by commission under the statute, so absent a signed agreement, the contractor owns the copyright in what they wrote, and you have at most an implied, non-exclusive license to use it. The Supreme Court drew this line decades ago in Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989), distinguishing employees from independent contractors using common-law agency factors, and the rule has tortured commissioning parties ever since.

The fix is simple to state and easy to forget: a written, signed agreement that assigns all intellectual property to your company. Not a work-for-hire recital alone (which may fail for the reasons above), but a present-tense assignment: "Contractor hereby irrevocably assigns to Company all right, title, and interest in and to the Work, including all copyrights, patents, trade secrets, and other intellectual property." Belt and suspenders: include both a work-made-for-hire clause and a backup assignment, plus a "further assurances" promise to sign anything else needed later (for example, to record a patent assignment at the USPTO). Employees should sign a proprietary-information-and-inventions-assignment agreement (a "PIIA") on day one; contractors should sign before they write a line. For the deeper treatment—including the enforceability wrinkles that vary by state, like California Labor Code § 2870's limits on assigning an employee's off-hours inventions—see Employee Invention Assignment Agreements: Drafting for Enforceability Across Jurisdictions.

Picture Acme Wellness three years from now, in the middle of an acquisition. The buyer's lawyers run IP diligence and discover that the freelancer who built the original meditation engine in 2024 never signed anything. Suddenly that freelancer—who may be unreachable, or who may now smell money—holds a copyright in a load-bearing chunk of the product. The deal stalls while Acme tries to buy back its own code at a price set by leverage it no longer has. This is not a horror story; it is a Tuesday in M&A diligence. Get the assignments now, while everyone is friendly and the code is worth nothing.

While we are on ownership: make sure you actually have the right to use every third-party component too. Modern apps are assembled, not authored from scratch—analytics SDKs, payment libraries, UI frameworks, fonts, stock images, sound effects, and open-source packages. Each carries license terms, and a few of them can reach into your proprietary code in ways we will cover below. Build a bill of materials now; it is far cheaper than reconstructing one under deadline.

The Gatekeepers: Apple's and Google's Developer Agreements

You may think of your app as your product. The two companies that control the doors to roughly the entire smartphone market think of it as content distributed under their contract. Before your app reaches a single user through the App Store or Google Play, you click "I agree" to a developer agreement and a set of program guidelines that are, functionally, non-negotiable adhesion contracts of real legal force. Read them. Most developers never do, and then are shocked to learn what they signed.

The core bargain has historically been this: the platform reviews your app, hosts it, handles payment and tax collection, and gives you reach, and in exchange it takes a commission—classically 30% of paid downloads and in-app purchases of digital goods (often reduced to 15% for small developers under Apple's Small Business Program and Google's equivalent, and for subscriptions after the first year). The agreements also dictate technical and content rules, reserve the platform's right to reject or remove your app, require you to indemnify the platform, designate the platform as a third-party beneficiary of your end-user license agreement, and impose specific terms you must carry through to your users (Apple, for instance, supplies a "Licensed Application End User License Agreement" you can adopt by default). The Practical Law treatment of mobile app development and distribution catalogs these developer-agreement provisions—IP, app review, advertising, in-app purchase, and EULA pass-through requirements—and the picture is consistent: the platform sets the terms, you adapt.

What makes 2026 an interesting moment is that the iron grip of the in-app-purchase rules has been pried open—partially—by litigation and regulation. The landmark is Epic Games, Inc. v. Apple Inc. Epic, maker of Fortnite, deliberately breached its developer agreement by sneaking a direct-payment option into the game, got booted from the App Store, and sued Apple under federal and California antitrust law. Epic mostly lost: the district court found Apple was not an unlawful monopolist under the Sherman Act, and the Ninth Circuit affirmed that core holding, 67 F.4th 946 (9th Cir. 2023). The Supreme Court denied certiorari in January 2024, leaving Apple's basic business model intact. But Epic won one consequential thing: an injunction under California's Unfair Competition Law barring Apple's anti-steering rules—the provisions that forbade developers from telling users, inside the app, that they could pay less on the web. That injunction survived appeal, and when Apple tried to comply in a grudging, fee-laden way, the district court in 2025 held Apple in civil contempt and ordered it to stop charging commissions on purchases made through external links and to stop discouraging users from following them. The practical upshot for an app like Acme Calm: you may now, in the U.S., steer users to a cheaper web checkout for your Premium subscription—a real strategic lever that did not exist a few years ago.

Outside the United States, the door is opening wider and faster. The European Union's Digital Markets Act (Regulation (EU) 2022/1925) designates dominant platforms as "gatekeepers" and forces them to permit alternative app stores, sideloading, and third-party payment systems on iOS in the EU, with very large fines for non-compliance. The result is a fragmented, jurisdiction-by-jurisdiction reality: your rights and obligations as a developer now genuinely differ between San Francisco, Brussels, and Seoul. If your app monetizes through subscriptions or digital goods and you operate globally, the commission structure and the steering rules are no longer a single fixed fact—they are a moving, multi-country strategy question worth real attention.

Three concrete takeaways for the post-build phase. First, read the program guidelines for the categories you touch—health and wellness apps (Acme Calm's home) face extra disclosure rules; apps with kids' content face the strictest review of all. Second, expect rejection and design for it: build your privacy disclosures, age ratings, and metadata to satisfy review the first time, because each rejection costs days. Third, don't try an Epic-style stunt. Epic could afford to weaponize a breach to make a legal point; your startup cannot survive being delisted while it litigates. Comply first, lobby and strategize second.

The Documents the Law Makes You Write: EULA, Terms of Service, and Privacy Policy

Every consumer-facing app needs a contract with its users and, in nearly every realistic case, a privacy policy. These are not interchangeable, and conflating them is a common rookie error.

An end-user license agreement (EULA) governs the software itself—it grants the user a limited, revocable, non-exclusive, non-transferable license to use the app, and it withholds everything else (the user does not buy the code, copy it, reverse-engineer it, or resell it). The EULA is where you place your warranty disclaimers, your limitation of liability, and the acknowledgment that the platform—not you—is off the hook for the app's behavior. The terms of service (TOS) govern the user's relationship with your service: acceptable-use rules, the community-conduct policy, user-generated-content licenses, payment terms, dispute-resolution clauses (often arbitration and a class-action waiver), governing law, and termination rights. Many apps merge the two into a single "Terms" document; that is fine, so long as both functions are covered. The Practical Law mobile-app EULA forms and clickwrap EULAs reflect the now-standard architecture: a tight license grant, robust disclaimers, the platform third-party-beneficiary clause Apple and Google require, and a clear assent mechanism. For a primer on the licensing concepts underneath, see Software Licensing Agreements: An Overview.

Here is the part that determines whether any of it is enforceable: how the user agrees. Courts treat online contracts on a spectrum. At one end is the clickwrap agreement, where the user must affirmatively click "I agree" next to (or after scrolling through) the terms—these are routinely enforced, as far back as ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996), and through a long line of clickwrap cases. At the other end is the browsewrap agreement, where the terms sit behind a link in a footer and the site claims you "agreed" merely by using it—these are frequently unenforceable because the user had no reasonable notice and gave no real assent. The Ninth Circuit's Nguyen v. Barnes & Noble Inc., 763 F.3d 1171 (9th Cir. 2014), refused to enforce a browsewrap that a reasonable user would never have seen; the Second Circuit's older Specht v. Netscape Communications Corp., 306 F.3d 17 (2d Cir. 2002), is the classic warning that terms below the download button do not bind. The modern best practice—now sometimes called "sign-in wrap"—is a conspicuous notice at account creation or first purchase: "By tapping Continue, you agree to our Terms and Privacy Policy," with both phrases as live links, and a record of the assent (timestamp, version, IP). Build that flow, log it, and you have a contract a court will likely honor. Bury your terms in a settings menu and you have a wish.

The privacy policy is a different animal—it is often legally mandatory, not optional, and it is increasingly the document regulators read first. We treat app privacy in depth in Legal Issues for Mobile Applications: Privacy, so here is the post-build essentials version. California's online privacy law (CalOPPA) effectively requires a conspicuous privacy policy for any commercial app that collects personally identifiable information from California residents—which, on the internet, means basically everyone. Both Apple and Google independently require a privacy policy as a condition of listing, and both now demand structured privacy "nutrition labels" (Apple's App Privacy details and App Tracking Transparency prompt; Google Play's Data Safety section) that must match what your app actually does. A mismatch is not a paperwork foot-fault; the Federal Trade Commission treats a privacy policy that lies about your practices as a deceptive act under Section 5 of the FTC Act (15 U.S.C. § 45), and it has brought many enforcement actions on exactly that theory. Beyond a baseline policy, your obligations scale with what you collect and who your users are: the California Consumer Privacy Act as amended by the CPRA, the wave of other state privacy statutes, the EU's GDPR if you have European users, and sector-specific rules. Two principles cut across all of them and belong in your build now: collect only what you need, and keep it only as long as you need it—the data minimization and storage-limitation discipline that also happens to be your best defense when (not if) something leaks. If you are standing up privacy from scratch, Developing a Privacy Compliance Program is the operational playbook.

Money, Subscriptions, and the Auto-Renewal Trap (ROSCA and Friends)

The fastest way for a perfectly legal app to attract a regulator is to charge people in a way that surprises them. Acme Calm offers a "7-day free trial, then $9.99/month"—the single most heavily regulated monetization pattern in consumer software. Welcome to the law of negative options.

A "negative option" is any offer where the seller treats the customer's silence or inaction as agreement to be charged—the auto-renewing subscription, the free-trial-that-converts, the "we'll keep billing you until you cancel" plan. As the Practical Law treatment of negative-option marketing explains, regulators police these on multiple tracks. At the federal level, the keystone is the Restore Online Shoppers' Confidence Act (ROSCA), 15 U.S.C. §§ 8401–8405. ROSCA makes it unlawful to charge consumers in an internet transaction through a negative-option feature unless the seller does three things: (1) clearly and conspicuously discloses all material terms before obtaining billing information—including that there will be recurring charges, the amount, the frequency, and the deadline to cancel before being charged; (2) obtains the consumer's express informed consent before charging; and (3) provides simple mechanisms to stop the recurring charges. The FTC enforces ROSCA through Section 5 of the FTC Act, and it backs this up with the Negative Option Rule (16 C.F.R. Part 425) and the Telemarketing Sales Rule.

This area is genuinely in motion, so flag the date. The FTC finalized a sweeping amendment to the Negative Option Rule in 2024—popularly the "Click to Cancel" Rule—designed to require, among other things, that canceling be at least as easy as signing up (no "call this number during business hours to escape your app subscription" mazes). But in July 2025, the U.S. Court of Appeals for the Eighth Circuit vacated the rule on procedural grounds, holding the FTC had skipped a required preliminary regulatory-analysis step. The headline consequence: as of this writing, the broad "Click to Cancel" Rule is not in effect. The trap for the unwary is to read that and relax. Do not. ROSCA itself—the statute—still requires "simple mechanisms" to cancel; the FTC can and does still bring negative-option cases under ROSCA and Section 5; and the substantive expectations the vacated rule embodied are exactly what enforcers, courts, and especially state legislatures already demand.

Because the real action is increasingly at the state level, and the states are stricter than Washington. California's Automatic Renewal Law (Cal. Bus. & Prof. Code § 17600 et seq.) is the toughest and the model many others follow: clear and conspicuous disclosure of the auto-renewal terms in "visual proximity" to the consent, affirmative consent to the automatic renewal specifically, an acknowledgment with cancellation instructions, and—critically—an online, click-to-cancel path for any subscription a consumer started online, often with a "one-click" or near-one-click standard and special rules for free-trial conversions and price increases. New York, Virginia, Colorado, and a growing roster have their own automatic-renewal statutes, several with private rights of action and statutory damages that plaintiffs' firms have turned into a cottage industry of class actions. For an app that bills nationwide, the safe design is to build to the strictest state and apply it everywhere.

So what does compliant Acme Calm look like? Before the user enters a card, a screen states in plain, prominent text: "7-day free trial, then $9.99/month. We'll remind you before your trial ends. Cancel anytime in Settings." The user must tap an affirmative "Start Free Trial" button—express consent, captured and logged. A confirmation email restates the terms and how to cancel. Cancellation lives in an obvious place, takes a couple of taps, and works without calling anyone. (Note one wrinkle: when you sell through the App Store or Google Play, the platform manages subscriptions and cancellation, which handles much of the mechanics for in-store purchases—but the disclosure and consent obligations are still yours, and if you also sell on the web, the web flow is entirely on you.) None of this is hard. It is just easy to skip, and skipping it is how a wellness app ends up in an FTC complaint captioned around the word "dark patterns."

A final money note: if your app processes payments directly (web checkout, not just in-app purchase), you inherit payment-card obligations. You will need a compliant payment processor and should keep cardholder data out of your own systems to the extent possible, both to satisfy the PCI Data Security Standard (a contractual, industry-imposed regime rather than a statute) and to shrink your breach exposure.

Accessibility: The ADA Now Reads Your App

Here is a risk that blindsides developers because it is invisible until a demand letter arrives: your app may be legally required to be usable by people with disabilities.

Title III of the Americans with Disabilities Act prohibits discrimination "on the basis of disability in the full and equal enjoyment of the goods [and] services... of any place of public accommodation" (42 U.S.C. § 12182(a)). The ADA was written in 1990, before the web, and its text lists physical places—stores, restaurants, theaters. The fighting question for thirty years has been whether a website or app is a "place of public accommodation" subject to Title III. As the Practical Law accessibility materials summarize, the U.S. Department of Justice (the ADA's chief enforcer) has long taken the position that public-facing websites of businesses that qualify as public accommodations must be accessible, and the courts have splintered. The Ninth Circuit, in Robles v. Domino's Pizza, LLC, 913 F.3d 898 (9th Cir. 2019), held that the ADA applied to Domino's website and mobile app because they connected customers to the goods of a physical place of business—and the Supreme Court declined to review it, letting the rule stand in that circuit. Other circuits disagree about whether a purely online business with no brick-and-mortar location can be a public accommodation at all. The result is a genuine circuit split and a thriving plaintiffs' bar that files thousands of website- and app-accessibility suits a year, many resolved by quick settlements precisely because the law is unsettled and litigation is expensive.

You do not have to resolve the circuit split to protect yourself, because there is a de facto technical standard the whole ecosystem has converged on: the Web Content Accessibility Guidelines (WCAG), published by the World Wide Web Consortium, currently at version 2.2, with Level AA the usual compliance target. Courts and the DOJ routinely point to WCAG as the yardstick. For mobile specifically, the W3C and the platform makers publish accessibility guidance (Apple's VoiceOver and accessibility APIs; Android's TalkBack and accessibility framework), and a meaningful share of WCAG compliance comes free if you simply use the native accessibility features correctly: label your buttons and images, support screen readers, ensure sufficient color contrast, don't trap focus, allow text resizing, and provide captions for audio and video. For Acme Calm, an app whose entire value is audio meditations, captions and transcripts are not a nice-to-have—they are the difference between serving deaf and hard-of-hearing users and excluding them, which is exactly the kind of exclusion Title III targets. The practical move in the post-build phase: run an accessibility audit against WCAG 2.2 AA, fix what you can, publish a short public accessibility statement (the W3C and Practical Law both offer templates), and put a clear path for users to report barriers. Doing so both reduces real-world exclusion and undercuts the "we never tried" narrative that drives demand-letter settlements.

Advertising and Marketing: You Are Now a Publisher Too

The moment Acme Calm shows an ad, makes a health claim, or sends a push notification with a discount, it becomes subject to the same truth-in-advertising regime as a television network—just with a smaller legal department.

The umbrella is Section 5 of the FTC Act, which bars "unfair or deceptive acts or practices" and is the FTC's authority to police misleading advertising, fake reviews, undisclosed endorsements, and "dark patterns" alike. A few concrete obligations land directly on apps. Endorsements and reviews: if Acme pays an influencer to promote the app, the influencer must clearly disclose the material connection under the FTC's Endorsement Guides, and Acme is responsible for that disclosure; the FTC's 2024 rule banning fake and AI-generated reviews and prohibiting buying reviews puts teeth in this. Health claims: "Acme Calm reduces anxiety by 40%" is a claim Acme must be able to substantiate with competent and reliable evidence, and a wellness app that drifts into "treats insomnia" or "lowers blood pressure" can wander into FDA territory for medical-device software—a real and serious line for health apps to watch. Mobile-specific disclosures: the FTC's long-standing guidance ".com Disclosures" (now updated for the mobile era) insists that material disclosures be clear and conspicuous on a small screen, not buried two taps deep. Messaging: push notifications and SMS marketing implicate the Telephone Consumer Protection Act, and any commercial email implicates the CAN-SPAM Act, which requires accurate headers, a clear opt-out, and honoring unsubscribes—covered in The CAN-SPAM Act: A Comprehensive Guide for Businesses and Marketers. And if your app runs a contest, sweepstakes, or rewards program, those are their own regulated category with state-by-state rules. The throughline: say true things, prove the things you say, disclose what you should, and make opting out easy.

When Your Users Are Kids: COPPA

If there is one area where "we'll deal with it later" can turn into a six- or seven-figure penalty, it is children's data. Acme Calm offers guided meditations for children, which means it has wandered into the Children's Online Privacy Protection Act (COPPA), 15 U.S.C. §§ 6501–6506, and the FTC's COPPA Rule, 16 C.F.R. Part 312.

COPPA governs the online collection, use, and disclosure of personal information from children under 13. As the Practical Law COPPA materials explain, it applies to two kinds of operators: those running a website or online service directed to children under 13, and those running a general-audience service who have actual knowledge that they are collecting personal information from a child under 13. Critically, "personal information" under the COPPA Rule is broad—it expressly includes geolocation, photos, audio recordings of a child's voice, and persistent identifiers like device IDs and cookies used to track a user over time. (Acme Calm should note that a child's voice recording and the device identifier are both regulated data.) Covered operators must, with narrow exceptions: post a clear privacy notice describing their practices; obtain verifiable parental consent before collecting a child's personal information (the harder a use, the stronger the consent method required); let parents review and delete their child's data and stop further collection; not condition a child's participation on collecting more data than is reasonably necessary; and keep the data secure and only as long as needed. COPPA violations are treated as unfair or deceptive practices, and the civil penalties are eye-watering—assessed per violation, they have produced settlements in the tens and hundreds of millions of dollars against major platforms. State attorneys general can sue too.

This is another fast-moving corner: in 2025 the FTC finalized significant amendments to the COPPA Rule, tightening the regime—adding requirements around separate parental consent for disclosing children's data to third parties (think advertising SDKs), data-retention limits, and updated definitions—with compliance dates phasing in. Layer on top of COPPA the new wave of state "age-appropriate design code" laws (California's AADC, with copycats elsewhere) and platform rules: both Apple and Google impose their own kids-category requirements and forbid certain ad and tracking practices in child-directed apps, and they enforce them through app review. The defensive posture for Acme: decide deliberately whether to be a "kids' app." If yes, build the COPPA machinery (notice, verifiable parental consent, minimal collection, no third-party ad tracking on the kids' content) and apply for the platforms' kids programs. If you want to avoid COPPA, design so that you neither direct content to under-13s nor knowingly collect their data—and resist the temptation to look the other way, because "actual knowledge" is exactly the kind of thing internal emails reveal in discovery.

Related: every app must also pick an age rating during store submission (the platforms use questionnaires that generate ratings via systems like the IARC). Rate honestly. A mismatch between your content and your rating is both a store-policy violation and, for kids' content, a COPPA-adjacent risk.

The Components You Didn't Write: Open-Source and Third-Party Licenses

Recall the bill of materials from earlier. Now we cash it in, because the libraries you bolted onto Acme Calm came with strings.

Open-source software is free as in freedom, not free as in no obligations. Permissive licenses (MIT, BSD, Apache 2.0) ask little—typically attribution and preservation of the license notice—and pose modest risk. The danger lives in copyleft licenses, above all the GNU General Public License (GPL) and its mobile-relevant cousins. Copyleft licenses are designed to be "viral": if you incorporate GPL-licensed code into your app in a way that creates a "derivative work" and you distribute the app, the GPL's terms can require you to license your entire combined work under the GPL—which means publishing your source code and letting users modify and redistribute it. For a proprietary app whose source is the crown jewel, that is a catastrophe, and "we didn't realize it was GPL" is not a defense. Open-source licenses are enforceable as licenses; the Federal Circuit confirmed in Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), that violating an open-source license's conditions can be copyright infringement, not just breach of contract—meaning the remedies include injunctions. The Affero GPL (AGPL) closes the "we only run it on a server" loophole and is a particular landmine for SaaS-backed apps.

The post-build move is to run a software-composition-analysis scan, generate a software bill of materials (SBOM), identify every license, and confirm that nothing copyleft has crept into your distributed binary, or that whatever did is properly isolated and complied with. Also confirm you have satisfied the easy obligations—attribution notices for MIT/BSD/Apache components, which most apps surface in an "Open Source Licenses" screen in settings. For the full treatment, see Open Source Software: Licenses, Compliance, and Risk and Open Source Licensing Landmines in Enterprise Software Development. Beyond open source, audit your commercial third-party agreements too: the analytics SDK, the maps provider, the push-notification service, the fonts. Each has terms of use, and many ad/analytics SDKs quietly impose data-sharing arrangements that can blow up your privacy representations—a single misbehaving advertising SDK has been the root cause of more than one FTC action against an app developer.

Export Controls and Encryption: The Rule Nobody Expects

Here is the obligation that makes founders laugh until they stop laughing: putting your app on a global store is exporting software, and the United States regulates exports.

Most consumer apps are low-risk, but the regime is real. Software distributed from the U.S. to users abroad falls under the Export Administration Regulations (EAR), administered by the Commerce Department's Bureau of Industry and Security. Two practical issues touch ordinary apps. First, sanctions and embargoes: you generally may not distribute your app to, or do business with, users in comprehensively embargoed jurisdictions or with parties on prohibited lists—which is one reason the app stores geofence certain countries, but the underlying compliance duty is still yours. Second, and more commonly relevant, encryption: nearly every modern app uses encryption (HTTPS, stored-data encryption, login security), and encryption software has long been subject to special export rules. The good news is that BIS substantially relaxed and streamlined the encryption rules over the years, and most mass-market apps using standard, publicly available encryption qualify for license exceptions with, at most, a simple self-classification or notification rather than a license. But "most" is not "all," and an app doing something genuinely novel with cryptography (a security tool, a privacy-focused messenger, a crypto-wallet) should get specific advice. The takeaway for the post-build checklist is modest but not zero: confirm your encryption is standard and qualifies for the relevant exception, don't ship to sanctioned destinations, and keep a one-page record of your export classification. It is a small box to check that, unchecked, can become a federal headache.

Putting It in Order: A Pre-Launch Sequence for Acme Calm

We have covered a lot of terrain. The value of a checklist is sequencing—knowing what to fix first. Here is the order in which a sensible team ships Acme Calm, roughly from "will sink the company" to "will generate a nasty letter."

First, the foundations that are hard to fix retroactively: confirm an operating entity owns everything; collect signed IP assignments from every developer and contractor; and build (or buy) clean title to all third-party and open-source components. These are the items that destroy acquisitions and bet-the-company lawsuits, and they only get more expensive with time.

Second, the gate and the contracts: accept and comply with the Apple and Google developer agreements and the guidelines for your categories; stand up a real EULA/terms of service with a conspicuous, logged clickwrap assent flow; and publish a privacy policy that actually matches your data practices and your store privacy labels.

Third, the consumer-law layer that draws regulators: get the subscription flow right under ROSCA and the strictest state automatic-renewal law (clear disclosure, affirmative consent, easy cancellation); handle payments through a compliant processor; and make your advertising claims true and substantiated.

Fourth, the specialized obligations triggered by what your app does: COPPA and kids-category compliance if you touch under-13 users; ADA/WCAG 2.2 AA accessibility, with captions for the audio content; CAN-SPAM and TCPA hygiene for marketing messages; and the export/encryption box.

Throughout, two habits pay for themselves: document your decisions (consent logs, version histories, an SBOM, an accessibility audit, an export classification), because the difference between a defensible app and an indefensible one is often just the paper trail; and keep counsel close for the moving parts, because privacy law, the platform-commission wars, ROSCA rulemaking, accessibility cases, and COPPA amendments are all genuinely in flux in 2026. For the founding-document side of all this, Popular Legal Documents for Startups is a useful companion; for the protective IP strategy that runs in parallel, return to Protecting Your Mobile App.

Key Takeaways

A finished app is the start of the legal work, not the end of it. An entity—not a person—should own and operate the app, behind insurance and a respected corporate veil. The single most consequential document is the IP assignment from every developer, because absent a signed assignment, your contractor, not you, may own your code. The platforms' developer agreements are binding adhesion contracts you must read and comply with; Epic v. Apple and the EU's Digital Markets Act have loosened the in-app-purchase and anti-steering rules, but the platforms still hold the keys. You need an enforceable EULA/terms of service delivered through a conspicuous clickwrap, plus a privacy policy that tells the truth and matches your store labels. The subscription model is the most regulated thing your app can do: comply with ROSCA and the strict state automatic-renewal laws even though the FTC's "Click to Cancel" Rule was vacated in 2025. Accessibility (ADA/WCAG), children's data (COPPA, tightened in 2025), advertising truthfulness, open-source license compliance, and export/encryption rules are each capable of generating a serious claim. Do these in order, document everything, and get specialized advice on the fast-moving parts.

Frequently Asked Questions

I hired a freelancer who built my whole app. Don't I own it because I paid for it? Almost certainly not—not the copyright, anyway—unless the freelancer signed a written assignment. For independent contractors, software is generally not a "work made for hire," so the contractor owns the copyright by default and you have at most an implied license to use it (Community for Creative Non-Violence v. Reid, 490 U.S. 730). Paying for work and owning the IP in it are two different things. Get a signed, present-tense assignment of all IP, ideally before development starts. See Employee Invention Assignment Agreements.

Do I really have to read Apple's and Google's developer agreements? Yes. They are binding contracts that dictate your commission (historically up to 30%, less for small developers and post-first-year subscriptions), content and technical rules, indemnities, EULA pass-through terms, and the platform's right to reject or remove your app. After Epic v. Apple and the EU Digital Markets Act, you now have more freedom to steer U.S. users to cheaper web checkout and, in the EU, to use alternative payment and distribution—but only if you understand the rules you're operating under.

What's the difference between a EULA, terms of service, and a privacy policy? The EULA licenses the software (what users can and can't do with the app) and houses your warranty and liability disclaimers. The terms of service govern the user's relationship with your service (acceptable use, user content, payments, arbitration, governing law). The privacy policy discloses what data you collect and how you use it—and it is frequently legally required by state law (CalOPPA) and by the app stores, and lying in it is a deceptive practice under the FTC Act. Many apps combine the EULA and TOS into one "Terms" document; keep the privacy policy separate.

My app has a free trial that becomes a paid subscription. What do I have to do? Treat it as a heavily regulated "negative option." Under ROSCA (15 U.S.C. §§ 8401–8405) you must clearly disclose all material terms (recurring charge, amount, frequency, cancellation deadline) before taking payment information, get the user's express informed consent, and provide a simple way to cancel. State laws—especially California's Automatic Renewal Law—add stricter disclosure, proximity, acknowledgment, and click-to-cancel requirements with real penalties. Build to the strictest state and apply it everywhere. Note that although the FTC's 2024 "Click to Cancel" Rule was vacated by the Eighth Circuit in 2025, ROSCA and the state laws still require easy cancellation.

Does the ADA apply to my mobile app? Possibly—the law is genuinely unsettled. Some courts hold that an app tied to a business that is a "place of public accommodation" must be accessible under Title III of the ADA (Robles v. Domino's Pizza, 913 F.3d 898 (9th Cir. 2019)); others disagree about purely online businesses, and there's a circuit split. Because thousands of accessibility suits are filed each year, the practical answer is to design to WCAG 2.2 Level AA, use the native iOS and Android accessibility features (screen-reader labels, contrast, captions), publish an accessibility statement, and offer a way to report barriers.

My app has content for kids. What's the big risk? COPPA. If your app is directed to children under 13, or you have actual knowledge you're collecting data from them, you must post a clear notice, get verifiable parental consent before collecting personal information (which includes voice recordings, geolocation, and persistent device identifiers), minimize collection, and let parents review and delete the data. Penalties run per violation and have produced very large settlements. The FTC tightened the COPPA Rule in 2025, and state age-appropriate-design laws and platform kids-category rules add more. If you don't want to be a kids' app, design carefully so you don't direct content to under-13s or knowingly collect their data. See Legal Issues for Mobile Applications: Privacy.

I used some open-source libraries. Is that a problem? Only if you ignore their licenses. Permissive licenses (MIT, BSD, Apache) just require attribution. Copyleft licenses (GPL, AGPL) can be "viral": incorporate them into a distributed app the wrong way and you may be obligated to release your own source code. Violating an open-source license can be copyright infringement, not just breach (Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008)). Run a software-composition scan, generate an SBOM, and confirm nothing copyleft is in your distributed binary. See Open Source Software.

Is putting my app on a global store really "exporting"? Yes, technically—software distributed abroad is subject to U.S. export rules (the EAR), including sanctions/embargo restrictions and special rules for encryption. The reassuring part is that most mass-market apps using standard, publicly available encryption qualify for license exceptions with little more than a self-classification. Don't distribute to embargoed destinations, confirm your encryption qualifies for the exception, and keep a short record of your classification.

Related Articles

This article provides general information only and is 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 is changing quickly; consult qualified counsel about your specific situation.