Home-screen and lock-screen widgets put a slice of your app's content where the user can see it at a glance, without opening the app. That convenience is also a privacy consideration: a widget is displayed on surfaces visible to anyone who can see the device, and on the lock screen, without authentication, so whatever the widget shows is on display. Widgets also run in a separate extension and share data with your app through a shared container, which is its own boundary to protect. Whether you build with WidgetKit on iOS or app widgets on Android, the same principle applies. Here is where widget data is exposed and how to handle it safely.
Short answer
Widgets, built with WidgetKit on iOS or as app widgets on Android, display app content on the home screen, and on iOS the lock screen and Today view. Per Apple's WidgetKit, that content appears on surfaces visible without opening the app, and on the lock screen without authentication, so a widget must not show sensitive information that should not be seen by anyone glancing at the device. Widgets also run in a separate extension process and typically share data with the app through a shared container, such as an App Group, which should be protected like any shared storage. The guidance is to display only non-sensitive, minimal content in widgets, assume it is visible to anyone who can see the device, and secure the data shared between your app and its widget.
What you should know
- Widgets show app content outside the app: home screen, and on iOS the lock screen.
- Lock-screen widgets are visible without authentication: anyone can see them.
- So widget content must be non-sensitive: assume it is on public display.
- Widgets run in a separate extension: sharing data via a shared container.
- Protect the shared container: like any shared storage.
Where is widget data exposed?
On the display surfaces and through the shared data path. The table lists them.
| Surface or path | Exposure |
|---|---|
| Home screen | Widget content visible without opening the app |
| Lock screen (iOS) | Content visible without authentication |
| Today view and Stand By | Additional glanceable surfaces |
| Cached snapshots | Rendered widget content may be cached |
| Shared container | Data the app and widget share, e.g., an App Group |
The primary exposure is that widget content is shown on surfaces a bystander can see: the home screen, where it appears without the app being opened, and, on iOS, the lock screen and Today view, where it is visible without the device being authenticated. So whatever a widget displays is effectively on public view for as long as it is placed. Rendered widget content can also be cached by the system as snapshots, so it persists beyond the moment. Separately, widgets run in their own extension process and usually get their data from the app through a shared container such as an App Group, which is a storage path that, like any shared storage, must be protected, since sensitive data placed there is accessible to the widget extension and persists on disk. Both the display and the data-sharing path are reasons to be deliberate about what a widget handles.
What is the app-and-widget data boundary?
A separate process reading shared storage, which you must secure. Because a widget runs in its own extension rather than in your main app, it does not share your app's in-memory state; instead it reads the data it needs from a shared location, commonly an App Group container on iOS or shared storage on Android. That means any data your widget displays has to be made available to it through that shared path, and whatever you put there is readable by the widget extension and stored on the device. The security implication is to treat the shared container as part of your data-at-rest surface: do not place secrets or more sensitive data than the widget needs into it, protect it appropriately, and remember it persists. The boundary is also a reason to minimize: rather than copying a rich, sensitive dataset into the shared container for the widget, share only the minimal, non-sensitive content the widget actually displays. So the app-and-widget boundary is both a data-sharing mechanism to use carefully and a storage surface to protect.
How do you handle widget data safely?
Show only non-sensitive content, and protect the shared data. Decide what a widget displays on the assumption that it is visible to anyone who can see the device, including on the lock screen without authentication, and keep sensitive information out of widgets entirely, status, counts, and other glanceable, non-sensitive details are appropriate, while account details, personal data, financial figures, or messages are not. Show the minimum the glanceable purpose needs. For the data your app shares with the widget, put only what the widget displays into the shared container, keep secrets and excess sensitive data out of it, and protect it as you would any shared storage, mindful that it persists and is readable by the extension. Update or clear widget data appropriately, for example on logout, so a previous user's content does not linger in a widget or its shared store. Treat cached widget snapshots as part of the same consideration. The principle is that a widget is a public-facing, glanceable surface backed by shared storage, so populate it only with information safe for anyone to see, and secure the minimal data you share to render it.
What to watch out for
The first trap is showing sensitive information in a widget, which then sits on the home or lock screen visible to anyone near the device, on the lock screen without authentication; keep widget content non-sensitive. The second is putting secrets or excess sensitive data into the shared container the widget reads, where it persists and is accessible to the extension; share only what the widget needs. The third is not clearing widget data on logout. Widget content and sharing are defined in your app and its widget extension, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled build against OWASP MASVS, assesses your data handling and shared-storage use, while deciding what is safe to display is yours to implement.
What to take away
- Widgets display app content on the home screen, and on iOS the lock screen and Today view, surfaces visible without opening the app and, on the lock screen, without authentication.
- Because widget content is effectively on public display, keep sensitive information out of widgets and show only minimal, glanceable, non-sensitive details.
- Widgets run in a separate extension and share data through a shared container, so put only what the widget needs there, protect it like any shared storage, and clear it on logout.
- Use a pre-submission scan such as PTKD.com to assess your data handling and shared-storage use, and decide widget content on the assumption it is publicly visible.
