Mobile App Product Liability: Unsafe Functions and Proof

EU Directive-level explanationUpdated 16 October 2026By ProductLiability.help editorial desk

An app's function determines the useful investigation

A mobile app can raise a product liability question when its operation contributes to an unsafe result and covered damage. Directive (EU) 2024/2853 includes software as a product, and Recital 13 expressly recognises applications. An app-store listing or a small purchase price does not decide the claim. The investigation must connect the particular app, its relevant function and the alleged harm under the applicable legal framework.

The software product liability overview explains the shared safety, damage and causation requirements. A mobile app might display a reminder, calculate a value, issue a warning or control equipment. Those functions create different possible failure paths. Begin with what the app was supposed to do in the actual situation, rather than assuming all apps present the same safety expectations.

Preserve app and device state together

Record the app identifier, installed release, publisher, installation route, device model and operating system build. Include relevant account settings and connected devices. An app-store page may describe a release published after the event; an account receipt may prove acquisition without identifying the build used. Preserve the information available on the affected device and state any uncertainty about historical installation.

Mobile applications can change through both local updates and remote configuration. A feature flag or server response may alter behaviour while the installed version remains unchanged. If the incident involves a connected appliance, preserve its software and pairing state too. A later successful test on the same phone may not reproduce the earlier combination of app, account, remote setting and device firmware.

Permissions and background operation can affect the event

Notification permissions, battery restrictions, network access and background execution policies can influence app behaviour. Determine what permissions were requested, granted and active at the relevant time. A missing alert could result from application logic, device policy, a failed delivery service or a configuration change. These are competing explanations to investigate, rather than reasons to assign blame immediately to a user or publisher.

Consider the product's presentation and reasonably foreseeable use under Article 7. If an app is promoted for a protective purpose, investigate how it handles ordinary mobile states such as sleep, temporary disconnection or permission changes. Its instructions and warnings are relevant circumstances. They should be assessed with the design and actual function, rather than treated as a universal answer to every safety concern.

Follow the command or calculation to its consequence

For an app controlling a physical product, reconstruct the command path. Identify the value displayed, value transmitted, receiving device and resulting action. Units, rounding and stale data can matter. A screenshot of a command screen does not prove that the same command was transmitted or acted on. Link interface observations to communication and device records where available.

For an app producing a calculated result, retain the inputs, calculation version and circumstances of use. Distinguish an executable calculation from information content supplied through the app. The Directive's software scope does not automatically bring every displayed statement or digital document within product liability. The allegation should explain which software behaviour was unsafe and how it contributed to the reported damage.

Identify suppliers without assuming the store is the manufacturer

The app publisher, software developer, connected-device manufacturer and distribution platform may occupy different roles. Article 8 provides conditions for economic-operator liability; it does not make every participant responsible merely because its brand appears on a screen. Keep publisher identity, branding, development and integration records, and the commercial supply route.

A component supplied to the app developer can also matter where its defectiveness caused the app or finished product to be defective within the Article 8 conditions. The guide to third-party library liability addresses that allocation. Do not assume that an app-store approval or a software dependency automatically transfers the publisher's entire responsibility to another business.

Keep covered harm distinct from app dissatisfaction

Article 6 addresses personal injury, specified property damage and destruction or corruption of data not used for professional purposes. Failed subscriptions, disappointing recommendations and reduced productivity are not automatically covered categories. A non-functioning app may support other remedies without establishing a claim for covered damage under this Directive. Record each alleged harm independently of the technical complaint.

Data incidents require particular precision. Loss of access to an account does not necessarily establish destruction or corruption of underlying data. Professional data are excluded from the stated data category. Preserve what happened to the data, how they were used and what restoration was possible. A screenshot of an empty screen cannot alone distinguish corrupted records from a temporary synchronisation or login problem.

Examine dates and later releases carefully

The corrected new-framework scope concerns products placed on the market or put into service after 8 December 2026. The national transposition deadline is 9 December 2026. An app being used after those dates does not itself establish its product date or the national rules governing the claim. Keep the supply and first-use chronology and examine later changes separately.

Article 7(3) also prevents a better subsequent release from proving an earlier version defective by itself. A patch can be useful evidence of a mechanism, but match its affected builds and trigger conditions to the incident. Preserve installation outcomes, not merely notification of availability. A phone offered an update may never have downloaded or activated it.

Request evidence tied to the alleged failure

Article 9 allows relevant court-controlled disclosure with conditions including proportionality and confidentiality protection. Article 10 retains proof requirements subject to its specified rebuttable presumptions. An injured person need not start with an unexplained demand for every source-code file. A focused account can identify the affected function, device state, event window and records that could test the allegation.

Avoid resetting or repeatedly operating a potentially unsafe connected product simply to recreate the event. Preserve existing records, document interventions and distinguish direct observations from later inference. A credible app investigation explains the limits of screenshots, telemetry and recollections while connecting them to one coherent causal account.

Records that help the review

Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.

Incident-time software identity and configuration
Relevant safety assumptions and test evidence
Supply, integration and control chronology

Independent educational information at EU Directive level. National implementing law and procedure require separate review.

Primary sources and legal scope

This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.