App Store Age Verification in 2026: 3 State Laws and 4 Age Brackets

Key Takeaways:

Three states passed App Store Accountability Acts and all three put obligations on the developer, not only on the app store. Texas SB 2420 took effect January 1, 2026, Utah's developer section 13-75-202 took effect May 6, 2026, and Louisiana's has been pushed to July 1, 2027
There are four brackets and everybody uses the same ones. Texas Sec. 121.021(b) defines child, younger teenager, older teenager and adult, and Google's Play Age Signals returns "0-12, 13-15, 16-17, and 18+"
There is no revenue floor and no download floor. Texas Subchapter C applies to "the developer of a software application that the developer makes available to users in this state through an app store," with no exemption for size or category
Adding a paywall counts. Texas Sec. 121.053(b)(3) makes "new opportunities to make a purchase in or using the software application" a significant change, which triggers a fresh parental consent for minor accounts
The clause with teeth is about contracts. Utah 13-75-202(4)(a) says a developer may not "enforce a contract or terms of service against a minor unless the developer has verified through the app store provider that verifiable parental consent has been obtained"
Both statutes hand you a safe harbor for relying in good faith on the store's data, which means the compliant path is also the cheap one: call the API, keep the record, delete the data
Read past the burden. For the first time, the App Store and Google Play will tell you a verified fact about the person using your product. No follower count, email list or brand deal has ever done that

Every creator platform argument for the last decade has been about what you do not own: the feed, the list, the algorithm, the relationship. Three state legislatures have just quietly handed app developers something no platform has ever given a creator, which is a verified attribute about a real customer. They attached homework to it. Here is exactly what the homework is.

What Is App Store Age Verification?

App store age verification is a set of state laws requiring an app marketplace to establish a user's age category, obtain parental consent for minors, and pass that information to the developer, who must then use it. The marketplace does the verifying. The developer does the enforcing. Both are named in the statute. That split is the part most coverage gets wrong. Texas SB 2420 has an entire subchapter aimed at developers. Sec. 121.051 states that it "applies only to the developer of a software application that the developer makes available to users in this state through an app store," and the sections beneath it require a developer to assign age ratings, notify the store before significant changes, verify each user's category, and restrict what it does with the data. Utah's Section 13-75-202 is titled, without ambiguity, "Developer requirements." This is not the same thing as the platform-side age checks already reshaping reach on social feeds. Those change who sees your content. These change what your product is legally allowed to do with a customer. If you are following the reach story, the companion piece is social media age checks and the five moves creators should make. This one is about the product.

Which States Have App Store Age Verification Laws in 2026?

Three: Texas, Utah and Louisiana. Two are live for developers today and one has been delayed to 2027. The dates have moved twice already, which is the single most important operational fact in this article.

State	Law	Developer duties effective	Enforcement	Status as of September 8, 2026
Texas	SB 2420	January 1, 2026	Deceptive trade practice under Bus. & Com. Code Ch. 17, Subch. E	Live. Enjoined in December 2025, injunction lifted, Apple applied it from June 4, 2026
Utah	SB 142, Utah Code 13-75-202	May 6, 2026	Private right of action, effective December 31, 2026	Live for duties, enforcement not yet switched on
Louisiana	HB 570 of 2025, replaced by HB 977 (Act 185)	July 1, 2027	Per the 2026 act	Not in force. Act 481 of 2025 "shall not become effective"

The Louisiana row is the one worth pausing on. Apple's developer news of February 24, 2026 told developers that Louisiana age categories would be shared "as of July 1, 2026." On May 15, 2026 the governor signed HB 977, which states that "Act No. 481 of the 2025 Regular Session shall not become effective" and sets the replacement sections to "become effective on July 1, 2027." The platform bulletin was accurate when written and is now a year out of date. A platform developer bulletin is a product announcement, not a compliance calendar. The statute is the calendar. Texas moved the other way. Apple published a notice on December 23, 2025 saying "a recent injunction issued by a district court suspended enforcement of Texas state law SB2420" and that it would pause its plans. On June 3, 2026 it published another saying that "due to a recent court ruling lifting an injunction on Texas law SB 2420, new Apple Accounts in Texas are now subject to the law," with changes going into effect starting June 4, 2026. Google's own documentation records the parallel date: the Play Age Signals API "has started returning age signals for eligible users in Texas who created their accounts after May 28, 2026."

Your compliance calendar lives in a statute, not in a developer newsletter.

We run the store operations, the release calendar and the compliance surface for every product we build, so the creator never has to read a bill.

See What We’d Build You →

What Are the 4 Age Brackets?

Child, younger teenager, older teenager and adult, split at 13, 16 and 18. Texas Sec. 121.021(b) sets them out in plain terms: "an individual who is younger than 13 years of age is considered a 'child'," 13 to 15 is a "younger teenager," 16 to 17 is an "older teenager," and 18 or over is an "adult." Google implements exactly that shape. Its documentation states that "the default age ranges that the API returns are 0-12, 13-15, 16-17, and 18+," delivered as an ageLower and ageUpper integer pair, with ageUpper returning null for the top band. You can narrow those in Play Console by setting up to three minimum ages, which "must be at least 2 years apart and can be changed once annually."

The field worth reading twice is ageRangeSource, because it grades the evidence rather than the answer. TIER_A means the user "has self declared their age." TIER_B means the age "is managed by a parent or a guardian." TIER_C covers a credit card, email address, selfie assessment, Government ID or Tax ID. TIER_D is "a combination of Government ID and selfie assessment, or Digital ID." You are told not only how old the person is but how hard anyone worked to find out. Apple returns the same class of information through its Declared Age Range API. Its age assurance developer Q&A states that the API "will return the age band or age category, depending on legal requirements in the region," and will "also provide information about the method used to confirm the age band or category, whether parental controls are enabled, and whether the user is eligible for age-gated features." That API is available worldwide to users on iOS 26, iPadOS 26 and macOS 26 or later, not just in regulated states.

The 5 Things a Developer Actually Has to Do

Texas Sec. 121.052 through 121.055 and Utah 13-75-202 describe the same five duties in slightly different words. Together they are the whole job.

Duty	Texas	Utah	What it means in your build
Rate the app and each purchase	Sec. 121.052(a)	13-75-202(1)(c)	Assign an age rating to the app and to every in-app purchase, and give the store the content reasons behind it
Read the age category	Sec. 121.054(a)(1)	13-75-202(1)(a)(i)	Call the store's API on session start and branch your experience on the answer
Read the consent status	Sec. 121.054(a)(2)	13-75-202(1)(a)(ii)	For a minor account, confirm parental consent was obtained before you treat the account as active
Notify before a significant change	Sec. 121.053(a)	13-75-202(1)(b)	Tell the store before you change terms, privacy, ratings, monetization or core functionality
Use and then delete the data	Sec. 121.055	13-75-202(1)(c) and (4)(c)	Age enforcement, legal compliance and safety defaults only. Texas requires deletion once verification completes

Two of those are one afternoon of engineering. Two are policy decisions somebody has to actually make. The fifth, the significant change notice, is the one that never finishes, because it fires again every time you improve the product. Utah adds a rule that will save you an argument: 13-75-202(3) says that when you set safety defaults you must "use the lowest age category indicated by" either the store's data or your own. When the two disagree, the younger number wins.

No Revenue Floor, No Download Floor, No Exemption

Read Sec. 121.051 again and notice what is missing. There is no minimum revenue, no minimum user count, no carve-out for utilities or games or reference apps, and no small-developer exemption anywhere in the chapter. If your app is available to users in Texas through an app store, the subchapter applies. Utah's chapter is drafted the same way. That is unusual, and it lands hardest on exactly the people this blog writes for. A creator with 80,000 followers and a $4.99 subscription app carries the same duty list as a company with a compliance department. The App Store does not have a beginner tier for statutes. Apple said so itself, and said it more bluntly than any critic. In its developer note of November 4, 2025 it wrote that it "remains concerned about the potential implications of laws like SB2420 in Texas," specifically that "they could undermine the privacy of all users by requiring the collection of sensitive personal information just to download an app, even those that simply provide weather forecasts or sports scores." Apple built the APIs anyway. So the practical position for a creator is that the largest company on earth objected, lost, shipped the tooling, and handed you the responsibility. This is the part that separates owning a product from having one built. Compliance of this shape is not a launch task. It is an operating task with a docket attached to it, which is the same reason what it costs to run a subscription app is a better question than what it costs to build one.

The Clause That Voids Your Subscription Terms

Here is the sentence to take to your lawyer, and it is short. Utah 13-75-202(4) states that a developer may not "enforce a contract or terms of service against a minor unless the developer has verified through the app store provider that verifiable parental consent has been obtained." Texas Sec. 121.056(a)(1) makes the identical act a violation. Translated: if a 15-year-old subscribes to your app and you never checked consent, your terms of service are not enforceable against them. Not the arbitration clause, not the refund policy, not the content license, not the auto-renewal terms. The document you paid someone to write does not apply to that customer. Utah attaches a price. Section 13-75-401, effective December 31, 2026, gives a minor or that minor's parent a civil action against a developer, and "the court shall award a prevailing parent" the greater of actual damages or "$1,000 for each violation," plus reasonable attorney fees and litigation costs. Texas routes violations through its deceptive trade practices statute instead. Set that against the disclosure regime creators already navigate. The FTC rules on sponsorship disclosure stop applying when the product is your own, because the whole point of those rules is a hidden third party. This one runs the other way. It applies precisely because the product is yours, and owning the product is what makes you the developer in the statute.

What Counts as a "Significant Change"?

Four things, and one of them is your paywall. Texas Sec. 121.053(b) says a change is significant if it changes "the type or category of personal data collected, stored, or shared," affects the assigned age rating or the content behind it, adds "new monetization features," or "materially changes the functionality or user experience" of the app. Read the monetization clause literally, because it is written literally. It covers "new opportunities to make a purchase in or using the software application" and "new advertisements in the software application." Introducing an annual tier, adding a consumable, launching a second subscription, or turning on ads is a significant change under this chapter. For supervised accounts, Google's API returns a significantChangeStatus of APPROVED, PENDING or DECLINED, and Apple exposes the same loop through the Significant Change API under PermissionKit. Apple's Q&A is explicit about who holds the risk: "Until the parent provides consent, the child must be prevented from accessing the significant update, which may include all app and account data or specific features." So the pricing experiment you were going to run next month has a new dependency, and it is a parent in another state tapping approve. That is a genuine cost, and it is also a genuine reason the economics of an owned app beat a rented storefront: the store is doing the consent collection, the identity work and the parental notification for you, at no additional commission.

The 2 Safe Harbors Worth Knowing

Both statutes protect a developer who does the obvious thing. Texas Sec. 121.056(c) says a developer is not liable for a verification failure if it "relied in good faith on age category and consent information received from the owner of an app store" and otherwise complied. Utah 13-75-402 says the same, and adds a second harbor for ratings: use "widely adopted industry standards" to set your age category and content descriptions, and apply them "consistently and in good faith." The design implication is clean. Do not build your own age gate. A birthday field you collect yourself gives you no safe harbor, adds a data-protection liability you did not have, and produces a worse answer than a TIER_D government ID check somebody else already paid for. Call the store's API, act on what it returns, keep the record, and delete the payload when you are done with it. Texas Sec. 121.055(b) requires that deletion. Google's API terms require the same discipline from the other direction, stating that you "may not use the Play Age Signals API for any other purpose including, but not limited to, advertising, marketing, user profiling, or analytics."

What Should You Do This Week?

If you already have an app in the store, four things:

Find out whether your app calls either API. Ask whoever ships your builds. On iOS the names are Declared Age Range, Significant Change under PermissionKit, the StoreKit age rating property and App Store server notifications. On Android it is Play Age Signals, which requires Android 6.0 or higher.
Write down what your app does for each of the four brackets. Not what it should do. What it does today, for a 12-year-old, a 14-year-old, a 17-year-old and an adult. Most creator apps have never answered this question because nobody ever asked it.
Add "notify the store" to your release checklist. Every pricing change, every new purchase type, every terms update. It is a two-minute step that only fails when it is not on a list.
Stop collecting birthdays yourself. You get no safe harbor for your own data and you inherit every obligation that comes with holding it.

If you do not have an app yet, the honest read is that this is easier to start with than to retrofit. The four brackets are a feature you would have wanted anyway. Knowing that a paying customer is 16 rather than 46 changes your onboarding, your content, your pricing and your notification schedule, and you have never once been able to know it from an audience dashboard. BUILT BY FOUNDRY builds the product your audience is already asking you for in about three weeks, at $0 upfront, on a revenue share. You own the business and you own the revenue. We keep operating it after launch, including the store listing, the release calendar and the compliance surface that a bill like this one keeps rewriting. Every creator complains that platforms know their audience better than they do. Three statutes just reversed that, for the people who own a product. If you do not own one, the law handed the advantage to somebody who does.

The store now verifies your customer's age. You just have to own a product it can tell.

Send us your handle. We will come back with the product your audience is already telling you to build.

See What We’d Build You →

Frequently Asked Questions

Does app store age verification apply to my app if I only have a few hundred downloads?

Yes, in Texas and Utah. Texas SB 2420 Sec. 121.051 states that the developer subchapter "applies only to the developer of a software application that the developer makes available to users in this state through an app store," and the chapter contains no revenue threshold, no user threshold and no exemption by app category or content type. Utah's chapter is drafted the same way. Size is not a defense, though the good-faith safe harbors in Texas Sec. 121.056 and Utah 13-75-402 are available to every developer regardless of size.

What are the four age categories under the Texas App Store Accountability Act?

Texas Sec. 121.021(b) defines four: a "child" is younger than 13, a "younger teenager" is at least 13 and younger than 16, an "older teenager" is at least 16 and younger than 18, and an "adult" is at least 18. Google Play returns the same shape as "0-12, 13-15, 16-17, and 18+" through its Play Age Signals API, and Apple returns an age band or age category through the Declared Age Range API.

Is the Louisiana App Store Accountability Act in effect?

No. Louisiana House Bill 977 of the 2026 Regular Session, signed as Act No. 185 on May 15, 2026, states that "Act No. 481 of the 2025 Regular Session shall not become effective" and sets its replacement sections to "become effective on July 1, 2027." Apple's developer news of February 24, 2026 still refers to a July 1, 2026 Louisiana date, because it was published before the amendment. Verify against the statute rather than the bulletin.

Do I need to build my own age verification screen?

No, and you should not. Both statutes give a developer a safe harbor for relying in good faith on the age category and consent information the app store provides. Texas Sec. 121.055(b) additionally requires you to delete the personal data the store gave you once verification is complete, and Google's API terms prohibit using age signals for advertising, marketing, user profiling or analytics. Collecting your own birthday field gives you a weaker answer, no safe harbor and a new data-protection obligation.

Does changing my subscription price count as a significant change?

Adding a new way to pay does. Texas Sec. 121.053(b)(3) lists "new opportunities to make a purchase in or using the software application" and "new advertisements in the software application" as significant changes requiring notice to the app store, and Sec. 121.053(b)(4) covers anything that "materially changes the functionality or user experience." For a supervised minor account, a significant change requires fresh parental approval, which Google surfaces as a significantChangeStatus of APPROVED, PENDING or DECLINED.

What happens if I never check the age category at all?

In Utah, Section 13-75-202(4)(a) means you cannot enforce your terms of service against a minor customer, and Section 13-75-401 gives that minor or their parent a civil action awarding the greater of actual damages or $1,000 per violation plus attorney fees and costs, effective December 31, 2026. In Texas, Sec. 121.101 makes a violation of the chapter a deceptive trade practice actionable under Subchapter E of Chapter 17 of the Business & Commerce Code. The commercial consequence arrives sooner than either: an unenforceable subscription agreement is an unenforceable subscription.