Apple Introduces New Feature to Prevent App Usage by Minors: "18+ Cannot Be Downloaded" — The Reality of Apple's "Age Assurance" Initiative

Apple Introduces New Feature to Prevent App Usage by Minors: "18+ Cannot Be Downloaded" — The Reality of Apple's "Age Assurance" Initiative

1. "Age Verification" is Becoming a Standard Feature of the App Store

In recent years, online age verification has shifted from "self-reporting by specific services" to "age assurance by the platform." The reason is simple: controlling it at the entry point, such as the OS or app store, is easier for regulatory authorities to implement and supervise than having each app handle child protection individually.


In this trend, Apple has taken a strong step by blocking the download of "18+ apps" altogether. In the targeted regions, users who cannot verify their age as adults will not be able to obtain 18+ designated apps. This change in entry design affects not only user experience but also business and revenue structures.


2. What Has Changed: Age Verification Required for 18+ in Australia, Brazil, and Singapore

Apple has revealed two major changes.


(A) Download Restrictions for 18+ Apps (Australia, Brazil, Singapore)
From February 24, 2026, in Australia, Brazil, and Singapore, the App Store will block the download of apps rated 18+ unless users can be reasonably verified as adults. Age verification is said to be automatically performed by the App Store.


The important point here is that Apple does not claim to "shoulder everything." Apple explicitly states that "developers may have a separate obligation to independently verify adulthood." This means that even if the entry is blocked, additional age verification may still be required on the app side.


(B) Extension of the Declared Age Range API (Age Category/Regulation Signals/Parental Consent Requirement)
Apple has expanded the Declared Age Range API, which allows developers to receive users' "age range (category)," and now returns additional information (signals) usable for regulatory compliance. For example, it indicates whether age-related regulations apply to the user, whether age sharing is mandatory, or whether parental consent is required for significant updates to children's apps.


Additionally, for Brazil, if users or parents consent, the age category will be shared, and signals regarding the "method" of age assurance will also be returned.


3. In the US, State Laws Drive the Change: Timeline for Utah and Louisiana

In the US, state-level movements are leading rather than federal uniformity, and Apple's implementation is fragmented in terms of "when, where, and what information is shared."


According to Apple, in Utah from May 6, 2026, and in Louisiana from July 1, 2026, for new Apple Accounts created thereafter, the age category will be shared through the Declared Age Range API if requested by developers.


Here, the store holds the "entry information of age" and passes some of it to the app. In political discussions surrounding SNS and apps, companies like Meta have increasingly argued that "app stores should handle age verification."

 
Traditionally, Apple has resisted with the privacy argument that "designs collecting all users' birthdates or ID information are dangerous," but as state and national laws demand "age assurance at the entry," a compromise design of sharing only the "age range" is coming to the forefront.


4. What Does "Age Assurance" Ultimately Demand from Users: The Source of Convenience and Anxiety

From the user's perspective, the most concerning points are what "reasonable methods" entail and how much burden will increase.

This point is where discussions can become most contentious. In MacRumors threads, support, sarcasm, and anxiety coexist on the same screen.

  • "It's natural for child protection" and "If movies have age ratings, apps should too" are supportive opinions.

  • On the other hand, there is strong opposition with statements like "Age verification tends to mean submitting a driver's license or passport, and I can only see a future where it gets hacked."

  • Furthermore, there are suggestions of "If it's that troublesome, the right choice for developers is to stop offering apps in the targeted regions or states."


Apple itself has also taken a stance against heavy identity verification like ID submission (due to data collection risks and the issue of uniform sharing with developers). This philosophy is why the Declared Age Range API leans towards sharing the minimum, "age range" instead of birthdates.


However, in reality, the levels required by national and state laws vary. Even if the platform provides a lightweight mechanism, if it is legally insufficient, additional verification may be needed on the app side, risking a duplication of user experience. Apple's statement that "developers may have separate obligations" can be read as preemptively addressing this "real-world twist."


5. Impact on Developers: Operational Complexity Outweighs Implementation Burden

For developers, the pain point is more about the operational design involving countries, states, age categories, and parental consent than the addition of the API itself.


Apple has not only prepared the Declared Age Range API but also mechanisms like PermissionKit for significant updates to children's apps, age rating-related properties, and notifications.

 
Furthermore, in WWDC sessions, Apple has shown the concept of experience design according to age and guided the direction of implementation.


However, the atmosphere on the ground tends to lean towards anxiety that "the more specifications increase, the more likely we are to get stuck with store reviews and metadata requirements." On Apple Developer Forums, there are examples where the choice and declaration of age assurance mechanisms are linked to reviews and metadata.

 
Additionally, in the Reddit developer community, there are ongoing practical complaints about being swayed by notifications and procedures for updating age ratings (including sharing operational know-how like "no new binary required").


In other words, age assurance is more about "compliance operation" than a "function," and ultimately, the costs of declaration, review, regional differences, and inquiry handling are more significant than implementation.


6. Reactions on SNS: Why Support and Opposition Don't Align

This topic tends to break down into the following three points on SNS.

 


(1) Effectiveness of Child Protection: Blocking the Entry is Understandable
The very act of "closing the 18+ entry" is intuitive and tends to garner supportive opinions. On MacRumors, voices like "long-awaited" and "support as a parent" are emblematic.


(2) Privacy: Resistance to ID Submission and Centralized Management
The fear among opponents is that "age verification will ultimately lean towards 'submitting identification.'" Whether the submission is to Apple or an external vendor, the intuition that the damage in case of leakage is significant is strong. In threads, the sentiment is so high that there are statements like "I can only see a future where it gets stolen."


(3) Shifting Responsibility: Store or App
Across the industry, "who should be responsible for age verification" has become a political theme. Past reports have depicted a structure where there is an argument that responsibility should be placed on platforms (Apple/Google), while platforms resist citing privacy.

 
Apple's current implementation is somewhere in the middle. "It stops at the entry, but obligations remain for developers," leading to dissatisfaction from both sides: supporters saying it's "still weak" and opponents saying "the entry is becoming surveillance."


This lack of alignment is likely the main reason why opinions on SNS remain parallel.


7. What Happens Next: Expansion of Target Regions and Normalization of "Age Category Sharing"

This update is tied to Australia, Brazil, Singapore, and specific states in the US. However, discussions on age assurance are progressing in various countries, and the trend of treating app stores as the "gateway of regulation" is strengthening.


The focus going forward is likely on three points.

  1. Increase in Target Regions (whether "18+ download restrictions" will spread to other countries)

  2. Specification of Verification Methods (where "reasonable methods" will settle in practice)

  3. Avoiding Duplication of User Experience (how to reduce dual age verification by store and app)


Additionally, as an often-overlooked point, there is theaccuracy of age ratings. The more the entry is closed, the more directly distribution is influenced by rating errors (excessive or insufficient). In Brazil, cases where regulation and rating are linked, such as "loot box declaration → 18+," have been shown, and the importance of "metadata" will further increase.


Source URL

Related Articles