a0.dev turns a written prompt into a working React Native app and publishes it to the App Store, Google Play, and the web. The model handles the scaffolding, the interface, and much of the backend wiring, which is why a founder with little mobile experience can ship something installable in an afternoon. What the generator does not do is work out which of the trackers baked into that app need consent before they run.
That gap is where compliance problems start. An app built on a0.dev is subject to the GDPR and the ePrivacy Directive the moment it reaches a user in the EU or UK, and the person who published it carries the legal responsibility, not the platform that wrote the code.
What a0.dev Actually Builds
a0.dev (a Y Combinator W25 company) generates a full React Native project from a text description and previews it live on your phone through its companion app. Backends are typically wired to Convex or Supabase, and the platform ships built-in APIs for AI inference and image generation, plus payments and subscription handling.
The output is a real native app, not a wrapped website. A React Native app stores data using AsyncStorage, a secure key store, and SQLite rather than browser cookies, and it talks to analytics, advertising, and crash-reporting services through software development kits (SDKs) compiled into the binary. When you also publish the web version, that build behaves like any ordinary website and sets cookies in the browser.
Two surfaces, two sets of mechanics. The native iOS and Android builds need an in-app approach to consent; the web build needs a cookie banner. Both are covered by the same underlying law.
Why "the AI Generated It" Is Not a Legal Defence
Regulators do not care that a model wrote your code. In its mobile application recommendation, published in final form on 24 September 2024, France's CNIL set out a responsibility matrix for the whole ecosystem: publishers, developers, SDK providers, app stores, and operating system vendors each carry defined obligations. The publisher, meaning the person or company that lists the app under its own name, is generally the data controller and answers for whatever the app collects.
a0.dev sits in the developer and platform role. The SDKs you add sit in the third-party role. You sit in the publisher role, which is the one with the consent obligations. The CNIL also confirmed that asking users to accept general terms and conditions does not count: consent has to be requested for each distinct purpose. That same authority ran an inspection campaign through 2025 aimed specifically at apps that track users for advertising or statistics without consent.
Why a0.dev Apps Still Need Consent Without Cookies
The objection sounds reasonable. No cookies, no banner, surely? It does not hold.
Article 5(3) of the ePrivacy Directive has always been written around the act of storing or reading information on a user's device, not around the word "cookie". The EDPB confirmed this in its Guidelines 2/2023 on the technical scope of Article 5(3), adopted on 16 October 2024, which state plainly that the rule is technology-agnostic and that "terminal equipment" includes smartphones. Writing an advertising identifier, an install ID, or an analytics token into local storage on a device triggers the same consent requirement a cookie would.
The GDPR then governs the processing itself. If an SDK reads the device advertising ID and sends behavioural data to an ad network, that is processing of personal data and needs a lawful basis regardless of how it was stored.
Here is what a typical a0.dev app touches, and where consent bites:
| App layer | What it stores or accesses | Consent before launch? |
|---|---|---|
| Backend auth (Convex / Supabase) | Session token in a secure store | No, strictly necessary for a login the user asked for |
| Crash and diagnostics SDK | Device data, sometimes an install identifier | Usually yes, unless genuinely anonymous |
| Product analytics SDK | Usage events tied to a device or install ID | Yes |
| Advertising / attribution SDK | IDFA on iOS, GAID on Android, attribution data | Yes, plus the ATT prompt on iOS |
| AI inference and image APIs | User prompts and inputs sent to a model endpoint | Disclose it, and handle any transfer outside the EEA |
| Web build (browser) | First and third-party cookies, local storage | Yes for anything non-essential |
The auth token your backend sets to keep a user signed in is fine without consent. The analytics and advertising identifiers are not.
ATT and App Store Labels Do Not Replace GDPR Consent
If your app runs on iOS and accesses the advertising identifier, Apple makes you show the App Tracking Transparency (ATT) prompt. Useful as that is, it is an Apple platform rule, not a GDPR consent mechanism. ATT covers only cross-app tracking via the IDFA; the GDPR covers every kind of personal data processing your app performs.
The two are not interchangeable, and the order matters. Under Article 7 of the GDPR, valid consent must be freely given, specific, informed, and unambiguous, with the controller and purposes named. The ATT prompt names none of that. The recommended order is to collect GDPR consent first, then show the ATT prompt only if the user agreed to advertising tracking. The CNIL made the same point years ago, noting that ATT on its own would force publishers to display a second consent screen anyway.
France's competition authority underlined the gap in March 2025, fining Apple 150 million euros over how ATT was implemented and confirming that the prompt does not, by itself, deliver GDPR-valid consent. The App Store and Google Play privacy labels are a disclosure exercise, not consent. Filling them in accurately is required, but it does nothing to satisfy Article 5(3) or Article 7.
Where a0.dev Apps Tend to Fail Compliance
The same patterns show up across generated apps:
SDKs that fire on launch. Analytics and attribution kits initialise in the app entry point and start collecting before the user has chosen anything.
Treating ATT or a privacy label as consent. Both get filled in; neither asks for consent in the GDPR sense.
AI features that quietly export data. Prompts and uploaded content are sent to an inference endpoint, sometimes outside the EEA, with no disclosure and no transfer safeguard.
A boilerplate privacy policy. A generated or copied policy that does not name the actual SDKs, identifiers, and third parties in your build is inaccurate, and an inaccurate policy is its own breach.
A web build with no banner. The web version ships with the same analytics and marketing scripts as a normal site, and no consent layer in front of them.
Adding Valid Consent to an a0.dev App
The fix has the same shape as for any app: find out what runs, stop the non-essential parts until the user agrees, and document it honestly. The work splits cleanly between the native build and the web build.
1. Audit what the build actually collects
List every SDK and outbound call in the generated project. On iOS, the App Privacy Report shows which domains an installed app contacts; on Android, the data safety section and a proxy capture do the same. For the web build, run a cookie scan against the deployed URL to see every cookie and script. You cannot ask for consent to things you have not catalogued.
2. Gate SDK initialisation on consent
Move analytics, advertising, and other non-essential SDKs out of the app entry point and behind a consent check. Show a clear, granular consent screen on first launch, store the choice, and initialise each SDK only once its category has been accepted. Leave strictly necessary components, such as your Convex or Supabase auth, running as normal.
3. Handle the web deployment with a banner
The web version of an a0.dev app is an ordinary website for compliance purposes, so it needs a consent layer that blocks non-essential scripts until the visitor agrees. A consent management platform such as Kukie.io scans the deployed site, categorises its cookies, and blocks tagging until consent is given. The same applies to any in-app screen that loads web content through a WebView.
a0.dev-Specific Pitfalls Worth Naming
A few traps come from how the platform itself works.
Regenerating a screen can quietly reintroduce an SDK you removed, or move an initialisation call back into the entry point, so re-audit after any significant prompt-driven change. One-click publishing also means an app can reach the store before anyone has reviewed its data flows, which makes the consent and policy review a release gate rather than a later chore.
The AI inference and image features deserve their own attention. They are the part most likely to send user content to a third party, and the generated code rarely surfaces where that data goes or who processes it. The compliance pattern matches web-first AI builders such as Bolt.new, with the extra mobile layer of advertising identifiers and the ATT prompt on top.
Frequently Asked Questions
Do apps built with a0.dev need a cookie banner?
The native iOS and Android builds do not use browser cookies, so they need an in-app consent screen rather than a banner. The web version of the same app does set cookies and needs a standard cookie banner.
Is the App Store privacy label enough for GDPR?
No. The privacy label is a disclosure to the store and to users, not a consent mechanism. The GDPR and the ePrivacy Directive still require informed consent before non-essential tracking runs.
Who is responsible if an a0.dev app breaks GDPR, me or a0.dev?
The publisher listed on the store is generally the data controller and carries the main responsibility. a0.dev and the SDK providers have their own narrower obligations as platform and third parties.
Does App Tracking Transparency cover my GDPR obligations?
No. ATT only governs access to the iOS advertising identifier for cross-app tracking. GDPR consent is broader and should be collected before the ATT prompt is shown.
Do I need consent for the AI features in my a0.dev app?
If user prompts or uploads are sent to a model endpoint, you must disclose this and, where the data leaves the EEA, put a transfer mechanism in place. Whether separate consent is needed depends on the purpose and your lawful basis.
What about users in the United States rather than the EU?
US state laws such as the CCPA mostly use an opt-out model rather than prior consent, but they still require disclosure and a way to opt out of sale or sharing. Many publishers run one consent flow that adapts to the user's region.
Ship a0.dev Apps With Consent Built In
If you have published an a0.dev app, or are about to, map its data flows before launch: audit the SDKs, gate the non-essential ones behind a real consent choice, and make the privacy policy match what the build actually does. Kukie.io scans the web version of your app, categorises its cookies, and blocks non-essential scripts until your visitors agree, and it can generate a matching cookie and privacy policy. The native build still needs its own in-app consent screen, but the web side is handled.
