Privacy-First Design: Obsessive Attention to Detail in a Memo App
1. Why Privacy Matters for a Memo App
Work ideas, personal drafts, and daily notes often contain information that is not ready to share. Fast capture should come with a clear explanation of where that information is stored and sent.
This article separates on-device encryption, session storage, screen visibility, diagnostic logs, and usage analytics. Protection in one area does not guarantee protection in another.
2. Automatic Hiding in the App Switcher Is Not Enabled
iOS takes a snapshot after an app moves to the background. Apple advises removing sensitive information from the interface during that transition.
In the checked source for version 5.8.17, sceneWillResignActive and sceneDidEnterBackground save the draft without calling the privacy overlay. The old overlay functions remain in the source, but are not an active protection path.
Visible memo text may remain in the app-switcher snapshot. Encrypting the Outbox does not hide a screen image. This corrects the earlier article’s claim that the overlay always hides memo content.
3. Ephemeral URLSession: Avoid Persistent Session Storage
The standard URLSession stores cache, cookies, and credentials to disk. For typical apps this is convenient functionality, but for a memo app it's unnecessary and potentially risky.
Communication cache persisting on the device means traces of which URLs were accessed and when exist on disk. Cookies being stored means session information remains on the device.
This app uses URLSessionConfiguration.ephemeral.
private let session: URLSession = {
let config = URLSessionConfiguration.ephemeral
config.httpCookieAcceptPolicy = .never
config.httpShouldSetCookies = false
config.urlCache = nil
return URLSession(configuration: config)
}()
- No disk cache: This URLSession does not persist its cache to disk
- Cookie use disabled: This URLSession does not accept cookies or set them on requests
- URL cache disabled: The cache storage itself is set to
nil - No persistent session storage: URLSession session data is not stored on disk
This protects URLSession storage. It does not remove usage events separately stored or sent by the app, delivery records on the server, or links made through analytics identifiers.
4. The Scope of Performance Logging
Logging in PerformanceLogger is guarded by #if DEBUG. Builds without DEBUG defined do not include this logger’s logging operations.
Its logError records the error type, such as URLError, instead of the detailed localizedDescription, which may contain a file path or user input.
This does not automatically sanitize every event name or additional string passed to logEvent. Callers must avoid passing email addresses, memo text, and authentication information.
This is not a guarantee of zero logs across the entire app, external SDKs, and operating system. First-party usage events and AppsFlyer remain separate, enabled systems. The analytics FAQ below and our Privacy Policy explain that collection.
5. What the AES-GCM Encrypted Outbox Protects
Pending memos are managed in an on-device queue called the Outbox. The app uses Apple’s CryptoKit to encrypt saved data with AES-GCM. Newly generated encryption keys are 256 bits.
Keys are stored in Keychain with kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly. This allows access after the first unlock following a restart, until the next restart, and prevents migration through a backup restored to another device. The app reads the key for encryption and decryption.
This protects stored data. It does not hide the visible screen or guarantee safety against every form of device compromise. Before changing devices, confirm that important memos have reached their destination.
When email sending is used, memo bodies are processed by our Relay API and delivery infrastructure, and remain as email in the recipient’s mailbox. On-device encryption does not mean email delivery is end-to-end encrypted (E2EE). See our Privacy Policy and data route explanation.
For the pending-send queue, see the Outbox architecture article.
6. Memo Protection and External SDKs
Within the iOS app, CryptoKit encrypts memo bodies, Keychain stores the key, and URLSession transmits memos. Network.framework monitors connectivity, and BackgroundTasks schedules background sending.
The app also uses external SDKs. GoogleSignIn and Firebase Authentication support optional email auto-fill from a Google account. Firebase App Check initializes at launch to protect backend access. AppsFlyer supports acquisition and usage analytics, with the same installation identifier used for first-party analytics.
Keeping memo text out of event fields does not remove links through identifiers and delivery records. Analytics, including SDK behavior, needs to be considered separately from memo encryption. Our Privacy Policy describes the fields and purposes.
7. Explain the Scope of Each Protection
On-device encryption, session storage, and usage analytics serve different purposes. An encrypted Outbox and an ephemeral URLSession do not mean the app collects no usage events.
Fast capture should come with an understandable explanation of collected data. We describe analytics destinations, identifiers, and how records can be linked, and review these explanations as the app changes.
Frequently Asked Questions
References
- Apple Developer — CryptoKit Documentation — Used for implementing AES-GCM encryption to protect Outbox data at rest
- Apple Developer — URLSession Documentation — Ephemeral session configuration for privacy-preserving network communication
- Apple Developer — Preventing Insecure Network Connections (App Transport Security) — Enforcing TLS for secure data transmission
- Apple Developer — Generating Log Messages from Your Code — Log storage and handling sensitive information
- Apple Developer — Preparing Your UI to Run in the Background — App-switcher snapshots and visible information
- Apple Developer — Keychain Access After First Unlock, This Device Only — Key access conditions and migration restrictions