A mobile app is a form of software
Article 4 of Directive (EU) 2024/2853 expressly includes software within the meaning of product. The Directive's recitals refer to applications as part of that software coverage. An app therefore need not arrive in a box or on physical media to enter the product-classification analysis. Its function on a phone or tablet does not make it a legally invisible digital addition.
The general product framework should be applied to the specific application rather than its store category. A navigation app, remote-control app and health-monitoring app may all be software products while presenting different safety questions. Classifying an app does not establish that every incorrect result is a safety defect or that every user complaint involves a type of damage addressed by the Directive.
Identify the app actually installed
Record the app name, developer identity, package identifier, version and build where available. App names can change, and similar-looking products can have different developers. A store listing viewed after an incident may describe a later release. Preserve incident-relevant screenshots and supply records while recognising that a display name alone does not establish the executable code installed on the device.
Record installation source and distribution context. A public store download, enterprise-managed installation and developer test package can involve different software images and participants. Capture permissions and configuration relevant to the alleged event. Settings can affect what the app is able to access or control, but their existence does not establish that a user understood or authorised every safety-relevant consequence.
Separate the application from the phone platform
An app depends on a device and usually on operating-system functions. Its appearance on screen can obscure those separate layers. The explanation of operating systems as products shows why the phone's system software may require its own identification. Drivers, sensors, power conditions and device hardware can also be relevant to a particular alleged failure.
An app may display a value supplied by a sensor or remote server rather than calculating that value locally. Record the origin of the information and the path by which it reached the interface. An incorrect display could reflect an app error, an upstream value, stale data or a misunderstanding of units. Product classification should preserve these factual possibilities until evidence supports a narrower explanation.
Remote services require their own classification
A mobile app may run locally while relying on a backend for authentication, processing or control. Software supplied through a network and a digital service connected to another product require careful differentiation. The existing guide on connected products and related services owns the detailed related-service definition. A generic description such as app platform does not establish that the entire arrangement is a single statutory product.
Identify which functions remain available when the remote connection is absent, without assuming that a temporary disconnection proves every element of the legal test. Preserve architecture descriptions and documented dependencies. Where the app controls a physical product, distinguish optional convenience features from functions on which that product depends. Those facts help define the component relationships before responsibility for an alleged defect is assessed.
Payment is not the only commercial indicator
The Directive's market-supply definitions include commercial supply for payment or free of charge. An app's zero download price therefore does not automatically exclude it. Establish the supplier and the commercial context, including any relevant paid services or business distribution. Do not assume that advertising or a subscription label, considered in isolation, conclusively answers every scope question for every participant.
Article 2 separately excludes free and open-source software developed or supplied outside commercial activity. That exclusion requires attention to the actual software and activity. An app can contain open-source libraries without the entire commercial app becoming excluded. Preserve the distribution terms and relevant component information, while distinguishing the conduct of an upstream contributor from the developer supplying the assembled application.
Product status does not establish a claim
Article 7 concerns expected or legally required safety, assessed in all circumstances. A missed notification or incorrect recommendation can be relevant without automatically establishing a defect that caused covered harm. Article 10 requires proof of defectiveness, damage and causation, subject to specific presumptions. A negative review or bug report should not be described as a finding of product liability.
The software product liability framework addresses those further questions. For classification purposes, the essential result is an accurate map of the application, system software, hardware and remote dependencies. Preserve the version state and incident chronology before automatic updates alter them. Avoid repeating a potentially hazardous command simply to obtain a screen recording of the suspected issue.
Check the applicable supply chronology
The corrected Directive covers products placed on the market or put into service after 8 December 2026. The relevant supply history and national implementing law need examination, particularly where an installed app has existed across several releases. A store's latest update date and the accident date do not independently establish which legal framework governs the product involved in an incident.
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.
- App package, version and installation source
- Device model, operating-system build and permissions
- Remote endpoints and relevant integration documentation
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.
- Directive (EU) 2024/2853, consolidated text: Articles 2, 4, 6, 7, 8, 10, 11 ↗
- Official Journal corrigendum, 7 May 2026: Article 2(1) ↗
Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.