How do you keep personal data out of logs, screenshots, the pasteboard and the app switcher?

14.3.3 · L2 · Interview

Predict first

Items are placed on the pasteboard with localOnly and an expiry, and the capture flag is read. What does it report? (The logger call uses privacy levels.)

import UIKit
import os

let log = Logger(subsystem: "demo", category: "net")
log.info("user \("alice", privacy: .private) id \(42, privacy: .public)")
UIPasteboard.general.setItems([["public.utf8-plain-text": "token"]], options: [.localOnly: true, .expirationDate: Date().addingTimeInterval(60)])
print(UIPasteboard.general.hasStrings, UIScreen.main.isCaptured)

true false
false false
true true

Mental model. Sensitive data is like private papers: it should not be left on the printer (logs), on the shared noticeboard (pasteboard), or visible in the window when you step away (the app switcher snapshot).

Most privacy leaks are not hacks but carelessness in ordinary places. Logs: logs end up in sysdiagnose files, crash reports and analytics tools, and developers often print tokens and personal data. Use the unified logging Logger with explicit privacy levels: an interpolation like \(name, privacy: .private) shows as <private> in logs collected from a device without the debugger, while .public is recorded as is (dynamic strings are private by default; numbers and constants are public). Never log tokens, passwords, full request bodies or whole user objects, even at debug level, and strip verbose logging in release builds. The pasteboard: UIPasteboard.general is shared and readable by other apps (iOS 16+ asks the user the first time another app pastes), so do not put secrets there; if you must, set .localOnly (not shared to other devices via Universal Clipboard) and an .expirationDate when you set items, and mark text fields for passwords as secure (isSecureTextEntry, which also disables the keyboard’s caching and suggestions). Screenshots and the app switcher: iOS snapshots your UI when the app goes to the background and shows it in the switcher, so cover sensitive screens when willResignActive or the scene phase becomes inactive (show a blank or branded view), and observe UIScreen.isCaptured and userDidTakeScreenshotNotification to react to screen recording or screenshots (you can blur or warn, but you cannot reliably block screenshots).

Other everyday leaks. Keyboards and autofill: use textContentType (.password, .oneTimeCode) and turn off autocorrect and suggestions for sensitive fields. Backups and caches: sensitive files in Documents are backed up; use file protection classes, and keep sensitive data out of URLCache, web view caches and analytics events. Analytics and crash reports: scrub personal data and identifiers before sending, and collect the minimum. Clipboard and sharing extensions: avoid auto-copying secrets. Notifications and widgets: do not show sensitive content on the lock screen. The guiding rules are data minimisation (do not collect what you do not need), purpose limitation (use it only for what you told the user), retention limits (delete when no longer needed, on sign-out and on account deletion, which App Review requires you to offer), and honest labels. Review them regularly, since the platform adds prompts and restrictions each release.

The items were set, so the pasteboard has strings, and nothing is recording the screen.

Common traps

Logging tokens or personal data “only in debug”. Logs travel in sysdiagnose files and crash reports; mark dynamic values private or do not log them.
Leaving a sensitive screen visible in the app switcher. The system snapshot shows it; cover it when the app resigns active.

They might follow up with

What does privacy: .private do? The value is redacted in logs collected without a debugger attached.
Can you block screenshots? Not reliably; you can detect them and screen capture, and hide content that matters.

How do you keep personal data out of logs, screenshots, the pasteboard and the app switcher?

Predict first

Common traps

They might follow up with

Related questions