GDPR for Mobile Apps: 6 Practical Obligations 2026

Main article: Cookie banners under § 25 TDDDG — the full pillar article on the topic.

The 6 obligations at a glance

The six obligations covered in this article concern access to the terminal equipment, the ATT dialog, push notifications, in-app advertising, apps for children and third-party SDKs. For each obligation, the overview names the core of the implementation and the source. Row 2 (ATT) rests on a platform requirement set by Apple; for all other rows the source column names the governing legal provision, while the column 'Core of the implementation' next to it also gives implementation examples.

1. § 25 TDDDG and apps

Apps, too, fall under § 25 TDDDG. Before information is stored on, or read from, the terminal equipment: consent under § 25(1) TDDDG — on the basis of clear and comprehensive information; the information and the consent must be provided in accordance with the GDPR. Exemptions under § 25(2) TDDDG: no consent is required where the sole purpose is carrying out the transmission of a message over a public telecommunications network (no. 1), or where the storage or access is strictly necessary to enable the provider of a digital service to provide a digital service expressly requested by the user (no. 2) — relevant in practice, for example, for an app's session or login token. Analytics, attribution and advertising IDs are not covered and continue to require consent.

Alongside § 25 TDDDG, the information duties of the GDPR apply: they follow directly from Art. 13 and Art. 14 GDPR and are discharged in the app through the privacy notice. Two hard requirements apply to the consent itself: the controller must be able to demonstrate that consent was given (Art. 7(1) GDPR), and withdrawal must be as easy as giving consent (Art. 7(3) GDPR); the lawfulness of processing carried out up to the withdrawal remains unaffected. Practice recommendation: keep the privacy notice reachable before the first consent dialog, log the consent layer with the time, the wording used and the version number, and offer a permanently reachable settings dialog in the app through which consent can be withdrawn in the same number of steps.

Germany / Austria: § 25 TDDDG is German law. The permissive provision for storing information on terminal equipment and accessing it is governed nationally — in Germany by § 25 TDDDG (supervision: the state data protection authority competent under state law, § 40(1) BDSG), in Austria by § 165 TKG 2021 (supervision: the Austrian Data Protection Authority (Datenschutzbehörde) as the national supervisory authority under Art. 51 GDPR, § 18(1) DSG). Both implement Art. 5(3) of Directive 2002/58/EC; in both countries the substantive standard for consent follows directly from the GDPR (Art. 6(1)(a), Art. 7 GDPR) and is therefore identical.

2. Apple App Tracking Transparency (ATT)

ATT is a platform requirement set by Apple, and the GDPR applies in parallel. On iOS, the ATT dialog is mandatory for access to the IDFA advertising identifier. Without approval in that dialog the IDFA remains blocked — that is the default state, not the exception. Every IDFA-based measurement is therefore affected, in particular re-targeting and attribution. Practice recommendation: decide before release which measurement remains viable without the IDFA, and document the legal basis for that substitute measurement separately under Art. 6(1) GDPR.

In legal terms, a second layer runs alongside: access to an advertising identifier stored on the device is tied in Germany to § 25(1) TDDDG and in Austria to § 165 TKG 2021. The consent itself is measured against Art. 6(1)(a) GDPR; demonstration and withdrawal are governed by Art. 7(1) and (3) GDPR, see point 1. Practice recommendation: keep your own consent logging separate from the platform status, so that the record survives a change of operating system or of SDK provider.

For permission dialogs beyond ATT — location, camera, contacts, microphone — the practice recommendation is: just-in-time requests plus a plain-language explanation, that is, the request at the moment of use, with one sentence explaining the purpose in plain language. In legal terms, what remains decisive is which legal basis under Art. 6(1) GDPR supports the underlying processing and whether, for access to information in the terminal equipment, an exemption under § 25(2) TDDDG applies.

3. Push notifications

Consent is required for marketing push. Transactional messages (order confirmation) are fine without consent. The difference is a question of the legal basis: every processing operation needs at least one of the six grounds for lawfulness in Art. 6(1) GDPR. For advertising messages that ground is consent (point (a)); for contract-related messages, performance of a contract (point (b)) may be considered.

In practice this means: separate marketing push and transactional messages technically, so that withdrawal of the marketing consent does not switch off the order confirmation as well (practice recommendation). Demonstration and withdrawal are governed by Art. 7(1) and (3) GDPR, see point 1 — as a practice recommendation: an opt-out in the app menu in addition to the operating system settings. If a push token is stored on, or read from, the terminal equipment for sending, it must additionally be examined whether consent under § 25(1) TDDDG is required for this or whether an exemption under § 25(2) TDDDG applies; in Austria this assessment is governed by § 165 TKG 2021.

Austria: for sending newsletters, Austrian practice expressly names, alongside Art. 6 GDPR, § 174 TKG 2021 (unsolicited messages) with consent or double opt-in. The GDPR standard for consent (Art. 6(1)(a), Art. 7 GDPR) is identical in both countries.

4. In-app advertising

Personalised advertising: consent. Generic advertising: legitimate interests are possible. The two legal bases are set out in Art. 6(1)(a) (consent) and (f) (protection of the legitimate interests of the controller or a third party) GDPR. If an advertising identifier stored on the device is read for the personalisation, consent under § 25(1) TDDDG is added (see point 1).

Two tightenings are easy to overlook in app practice. First: if the selection of advertising targets data revealing health, religious or philosophical beliefs, political opinions, or data concerning sex life or sexual orientation, the general prohibition on processing in Art. 9(1) GDPR applies, with the narrow exceptions of paragraph 2 — explicit consent, for example. Second: Art. 35(3) GDPR expressly names systematic and extensive evaluation of personal aspects (profiling) with legal effect as a case in which a data protection impact assessment is required. Practice recommendation: before launching a new targeting feature, record in writing which legal basis supports it, whether Art. 9 is engaged and whether a data protection impact assessment is needed — that note later becomes the basis of accountability towards the supervisory authority.

5. Apps for children (<16 years)

Consent under Art. 8 GDPR is valid only from the age of 16; below that, parental consent is required. Member States may lower the age limit to 13 — Germany stays at 16. Austria has lowered the age limit to 14. Stricter obligations under Art. 8 GDPR therefore apply to apps for children. Examples of implementation: parental consent, doing without tracking, plain language. The same basic conditions apply to consent as for adults: demonstration and withdrawal are governed by Art. 7(1) and (3) GDPR, see point 1.

Infringements of Art. 8 GDPR fall, under Art. 83(4) GDPR, within the lower fine range (see the table 'Deadlines, competences and penalties'). If the app also processes health data (for example in a fitness or therapy companion app), the prohibition on processing in Art. 9(1) GDPR applies, with the exceptions of paragraph 2. Practice recommendation: in apps for children, do without advertising identifiers and profiling altogether — otherwise reading an advertising identifier stored on the terminal equipment would require consent under § 25(1) TDDDG (in Austria § 165 TKG 2021), and profiling can trigger a data protection impact assessment under Art. 35(3) GDPR. Also a practice recommendation: bring the age rating, the route for obtaining consent from those with parental responsibility, and the child-friendly version of the information texts together in one document, and review it again with every release change; that is a practice rhythm, not a statutory deadline.

6. App SDK audit

Third-party SDKs (Facebook, Firebase, Mixpanel) are relevant to data protection. For each SDK you must examine which data it collects and where that data flows. The assessment runs in three steps. First, clarify the role: are you a controller (Art. 4 no. 7 GDPR), a data processor (Art. 4 no. 8 GDPR) or a joint controller (Art. 26 GDPR)? Second, the contract: if the processing is carried out on your behalf, you may only work with data processors who provide sufficient guarantees for appropriate technical and organisational measures; the cooperation needs a contract that sets out the subject matter and duration, the nature and purpose of the processing, the type of personal data, the categories of data subjects and the obligations and rights of the controller (Art. 28(1) and (3) GDPR).

Third, the record of processing activities: every SDK that collects or receives personal data must be findable in the record of processing activities — as a category of recipient of the processing activity concerned, with the third country transfer including its safeguard (standard contractual clauses SCC, EU-US Data Privacy Framework DPF, or binding corporate rules BCR), the envisaged erasure period and a reference to the central concept of technical and organisational measures (TOM, Art. 32 GDPR) — not a separate set of measures per processing activity. The 250-employee exemption in Art. 30(5) GDPR applies only cumulatively and, in practice, regularly fails already on the element of 'processing carried out on a regular basis'. Crash reporting goes through the same three steps as any other SDK. A data protection impact assessment under Art. 35(1) GDPR is not due per SDK, but only where the underlying processing is likely to result in a high risk to the rights and freedoms of natural persons; the profiling criterion in Art. 35(3) GDPR is the main candidate here (see point 4).

Practical order of the assessment (not an official requirement): assessments regularly start with the record of processing activities (VVT) and work their way through the data processing agreements (AVV) and the technical and organisational measures (TOM) to the data protection impact assessment (DPIA). Anyone who cannot deliver on the record of processing activities will struggle to convince on the rest. Practice rhythm (not a statutory deadline): review the SDK list annually and on every change, and quarterly for fast-growing products; typical sources of error are outdated recipient lists, missing erasure periods and a missing third country note for US tools.

Deadlines, competences and penalties in DE and AT

For app operators, four statutory time requirements, two supervisory competences and three penalty ranges are relevant; added to these are two national special rules in Germany and Austria, which follow the table. The overview below contains only statutory time requirements, competences and penalty ranges; practice recommendations are not included in it.

Germany / Austria: In Austria, § 11 DSG provides for the proportionate application of Art. 83 GDPR, in particular a reprimand instead of a fine for first-time infringements. In Germany, § 43(2) and (3) BDSG penalises, in addition to Art. 83 GDPR, certain infringements — the incorrect handling of a request for access and the consumer information under § 30 BDSG — as an administrative offence with a fine of up to EUR 50,000; no fines are imposed on authorities and other public bodies.