Infinite scroll and streaks are about to be regulatedInfinite scroll and streaks are about to be regulated

The European Commission is presenting a draft Kids Act on 17 September. As reported, it would keep under-13s off social media, video platforms, games and AI chatbots except under guardian supervision, restrict 13 to 15 year olds to supervised accounts, require age verification through an EU-wide app, and ban design patterns it considers addictive - infinite scroll and streaks are both named. Educational tools are excluded. Penalties reach six percent of global annual revenue.

It is a proposal, not a law. The thresholds will move, the timeline is not set, and nobody should be rewriting an app this week. It is still worth reading now, because of which part is unusual.

Most compliance work is about data. This one is about interface.

GDPR, the DSA and the age-rating rules all concern what you collect, who you share it with and what you disclose. They are answered with policy documents, consent flows and a privacy review. The interface barely changes.

A rule against infinite scroll and streaks is a different kind of requirement. Those are not data practices, they are the things a client asks for by name. We have been briefed on both, more than once, and neither has ever been controversial.

What that means for a build

If a proposal of this shape becomes law, an app with social features acquires a second layout: one for adults and one for younger accounts where certain patterns are unavailable.

• Feeds need a defined end. Paginated or capped is a modest change if the data layer already supports it, and an awkward one if the API was written on the assumption that scrolling never stops.
• Streaks, daily rewards and notification loops need to be switchable per account rather than compiled in.
• Onboarding needs an age gate that is verification rather than a date-of-birth field nobody checks.
• Anything with an AI companion needs care around emotional attachment, which is a design brief nobody has written before.

The requirement is not what you store. It is what the screen does.

The cheap preparation and the expensive one

The expensive version is rebuilding a feed under deadline because the pagination assumption reaches into the API, the cache and three screens.

The cheap version is a question during design: could this behave differently for a younger account without a rewrite? Usually the answer is a flag and a branch. Deciding that when the feature is built costs almost nothing; deciding it afterwards is the rewrite.

What we tell clients

That we are not changing the roadmap for a draft. Proposals change substantially between announcement and law, and building against the first version is how teams end up implementing something that never arrives.

What we would change is the shape of new work. If an app being built now will have a younger audience in Europe, making the engagement mechanics configurable is worth doing regardless - it is a day of work that pays for itself the moment any regulator, any app store, or any client with a safeguarding policy asks the question.