DailyCue — iOS Security Review

Status: FULLY REMEDIATED. DatabaseEncryption.swift provides a Keychain-backed 32-byte passphrase, and DailyCueDatabase.swift now applies it during database open via Configuration.prepareDatabase:

The build configuration (project.yml) points to the local SQLCipher-backed GRDBCipher package. On fresh installs, the database is created encrypted from the start. On upgrades from the plaintext era, migratePlaintextDatabase() handles the migration:

• Detects plaintext SQLite via magic header bytes ("SQLite format 3\0")
• Backs up the plaintext file, creates a new encrypted database, restores all records, then deletes the plaintext backup on success
• On failure, the backup is restored atomically (rollback)

Remaining (minor) concern: The migration involves an async suspension point (try await restoreSnapshot at line 83) between moving the plaintext file (line 77) and deleting the backup (line 82). If the process is killed during this window, a plaintext backup file (dailycue.db.plaintext-backup) could remain on disk. This is mitigated by NSFileProtectionCompleteUnlessOpen on the directory and the backup being left in the application support directory. Consider wrapping the migration in an NSFileCoordinator scope or adding a cleanup check on next launch.

Status: FULLY REMEDIATED. All 6 print() locations across the codebase have been replaced with structured Logger calls from OSLog:

• BackupManager.swift:114–115 — HMAC verification failure: logger.warning("Backup HMAC mismatch...")
• HomeViewModel.swift:154 — Batch checklist fetch failure: logger.error("[loadChecklistItems] Batch fetch failed...")
• SettingsViewModel.swift:337 — Settings persistence failure: Logger(...).error("Settings persistence failed...")
• QuickAddViewModel.swift:149 — Weekly event save failure: Logger(...).error("[QuickAdd] Failed to save...")
• QuickAddViewModel.swift:155 — Informational log: Logger(...).info("[QuickAdd] Saved...")

Each file now imports OSLog and uses the appropriate log level:

• .warning for security events (HMAC mismatch, file not found)
• .error for unexpected operational failures
• .info for informational events

The messages are now captured in the unified log system, persist across sessions, and can be inspected via log show or the Console app. Each logger is categorized by subsystem (com.dailycueplanner) and component (backup, home, settings, quickadd, soundpreview).

Status: FULLY REMEDIATED. The UIBackgroundModes: audio declaration has been removed from Info.plist. This capability was previously declared without functional justification — the app has no feature requiring background audio playback.

SoundPreviewPlayer (SettingsView.swift) uses AVAudioPlayer to preview notification sounds interactively in the settings UI — this works correctly without the background audio entitlement. Notification sounds delivered via UNNotificationSound are handled by the system notification service and do not require it either.

The removal eliminates:

• App Store rejection risk — Apple reviews background mode usage and may reject apps that declare capabilities without using them
• Unnecessary battery impact — the system may grant extra background execution time when audio mode is declared
• Attack surface reduction — removing an unnecessary entitlement reduces the potential impact of audio stack vulnerabilities

The original review identified 5 locations. The re-assessment found ~55 locations across 17 files using try? or empty catch blocks that silently discard errors. Key categories:

Category 1: AsyncStream catch with silent finish (9 locations)

• ScheduleRepository.swift:44–46, 67–69 — catch { continuation.finish() }
• RoutineRepository.swift:28–30 — catch { continuation.finish() }
• SettingsRepository.swift:27–29 — same pattern
• ChecklistRepository.swift:30–32 — same pattern
• NotificationRepository.swift:28–30 — same pattern
• StatsRepository.swift:42–44 — same pattern
• ObserveRoutinesUseCase.swift:27–29 — same pattern

Category 2: try? discarding errors at call sites (20+ locations)

• DailyCueApp.swift:115–120 — let settings = try? await deps.settingsRepository.fetchSettings() — settings fetch failure silently defaults
• DailyCueApp.swift:135 — _ = try? await deps.notificationManager.requestAuthorization() — authorization failure silently ignored
• HomeViewModel.swift:225–234 — checklist + event update failures silently ignored
• HomeViewModel.swift:241–246 — event deletion failure silently ignored
• HomeViewModel.swift:252–257, 264–273 — appointment/routine deletion failures silently ignored
• RoutineLibraryViewModel.swift:98, 104 — update/delete failures silently ignored
• SettingsViewModel.swift:80–86, 205–210 — fetch/cleanup failures silently ignored
• EditEventViewModel.swift:115–118, 195–200 — various operation failures silently ignored
• QuickAddViewModel.swift:85–93, 148–153 — notification scheduling failures silently ignored
• RoutineRecord.swift:74, 113 — contacts JSON encoding/decoding failures silently ignored
• DailyCueDatabase.swift:86–95 — cleanup during migration failure silently ignored

While many of these are non-security operations (UI updates, cleanup), the pervasive pattern makes debugging difficult and can mask subtle data integrity issues. The try? pattern for settings fetch (F111) and notification authorization (F125) are particularly concerning because they affect core app functionality.

☑ Status: FULLY REMEDIATED. All ~55 try?/empty catch locations across 17 files have been converted to do/try/catch with structured Logger error/warning logging. The remediation covers:

• 6 Repository AsyncStream observers — catch blocks now log via logger.error("Stream failed: ...") before continuation.finish()
• ObserveRoutinesUseCase — same pattern added
• DailyCueApp.swift (init) — settings fetch + notification auth converted to do/catch with logger.error
• HomeViewModel.swift — 8 DB write sites converted to do/catch with logger.error; 3 Task.sleep sites left as try? (cancellation expected)
• SettingsViewModel.swift — 3 try? sites converted to do/catch with logger.warning/logger.error
• EditEventViewModel.swift — 7 try? sites converted with logger.error for notification scheduling failures
• QuickAddViewModel.swift — 4 try? sites converted with Logger for settings fetch + notification scheduling
• RoutineLibraryViewModel.swift — 2 try? sites converted with logger.error for checklist/event cleanup
• ScheduleRoutineViewModel.swift — 2 try? sites converted with logger.warning for settings fetch
• DailyCueDatabase.swift — migration cleanup catch converted to do/catch with logger.error; isPlaintextSQLiteDatabase now logs on read failure
• RoutineRecord.swift — contacts JSON encoding/decoding converted to do/catch with Logger warning/error

Correction from previous review: The previous review incorrectly stated that JSONDecoder() defaults to .allowJSON5. In iOS 15.0+ (the app's minimum target), allowsJSON5 defaults to false, so the decoder is already strict about JSON syntax. This finding has been corrected.

BackupManager.importFrom() uses JSONDecoder() to decode user-provided backup files. While the checksum and HMAC provide integrity verification after JSON parsing, the decoder itself has two remaining concerns:

• Deeply nested JSON DoS: The 10 MB file size limit (BackupManager.swift:86) provides a baseline, but an attacker could craft a deeply nested JSON structure within that limit that causes excessive memory or CPU consumption during parsing (e.g., millions of nested arrays). JSONDecoder has no built-in max depth limit.
• Extra fields silently ignored: The BackupEnvelopeCodable and BackupPayloadCodable types use synthesized Codable initializers, which ignore extra fields in the JSON. While not a vulnerability, this means a malformed but valid-JSON backup could be partially decoded without error.

DatabaseEncryption.swift:21–25 defines resetPassphrase() which deletes the existing Keychain-stored passphrase and generates a new one:

If this method were called after the database has already been opened with the old passphrase, the database file would become permanently inaccessible:

• The old passphrase is deleted from the Keychain
• A new, unrelated passphrase is generated and stored
• The SQLCipher-encrypted database file is still encrypted with the old passphrase — there is no PRAGMA rekey call
• On next launch, the app tries the new passphrase and fails to open the database — all user data is lost

Mitigating factor: resetPassphrase() is not called anywhere in the current codebase. However, it is a public API on DatabaseEncryption and could be called inadvertently by future code.

DatabaseEncryption.swift and BackupKeyStore.swift correctly use the iOS Keychain for cryptographic material:

• Database passphrase: 32-byte (256-bit) random value generated via SecRandomCopyBytes, stored in the Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly — meaning the passphrase cannot be extracted from backups or when the device is locked
• Backup HMAC key: 256-bit SymmetricKey stored in the Keychain as a generic key with kSecAttrAccessibleWhenUnlockedThisDeviceOnly protection, preventing backup replay from other devices
• Passphrase generation uses proper cryptographic random bytes (not UUID or Date) and encodes as hex for usability
• Error handling distinguishes between "item not found" and actual Keychain errors, propagating OSStatus in the DatabaseError / BackupError types
• In-memory caching (cachedKey in BackupKeyStore) reduces Keychain lookups while still loading from the secure store on first access

This is a model implementation of iOS credential storage, now fully wired to the database encryption layer (see Finding 1 — remediated).

The iOS app contains zero HTTP, socket, or other network communication code. No INTERNET permission is declared in the Info.plist. No URLSession, WKWebView, or NWConnection usage exists anywhere in the codebase. There are no third-party analytics, crash reporting SDKs, or network-dependent dependencies (GRDB is a local SQLite wrapper). This eliminates the largest class of mobile app vulnerabilities entirely and mirrors the Android app's strong posture.

All database queries across the codebase use GRDB's query builder or parameterized SQL (positional ? placeholders). GRDB binds these as SQLite prepared statement parameters, making SQL injection impossible even if user-supplied data flows into queries. Examples:

All repository code uses parameterized queries exclusively. No dynamic SQL construction via string interpolation exists anywhere in the codebase — with one exception.

Design smell — SettingsRepository.updateField(): SettingsRepository.swift:107–119 uses string interpolation for the column name:

Why this is currently safe: The updateField method is private and all 18 callers pass hardcoded string literals for column names (e.g., "reminderDurationMinutes"). There is no path where user input reaches the field parameter. The value portion is properly parameterized via ? bindings.

Why it's a design smell: If a future developer adds a new caller that passes a dynamically-constructed column name (e.g., from user input or a config key), this would become a SQL injection vector. Column names cannot be parameterized in SQLite — they must be either interpolated or whitelisted. The GRDB query builder (Column("name")) would prevent this entirely.

BackupManager.swift implements a two-layer backup integrity scheme:

• SHA-256 checksum — computed from the serialized payload and stored in the envelope. On import, the checksum is recomputed and compared. A mismatch raises a hard error (BackupError.integrityError)
• HMAC-SHA256 signing — computed with a device-specific Keychain-stored key via CryptoKit.HMAC. On import, the HMAC is verified. A mismatch triggers a warning (not a hard error — to support cross-device migration)
• File size limit — rejects files larger than 10 MB before any parsing begins
• Version validation — rejects backup envelopes with version numbers outside the supported range (1 only)
• Security-scoped resource access — correctly uses startAccessingSecurityScopedResource / stopAccessingSecurityScopedResource with defer for file importer URLs
• Atomic writes on export — uses Data.WritingOptions.atomic to prevent partial file writes
• Notification rescheduling — after import, NotificationRescheduler cancels and re-creates all pending notifications to match the restored schedule

The BackupKeyStore implementation correctly stores the HMAC key in the Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly, making the key device-specific and unrecoverable from backups.

SmsComposerPresenter.swift uses Apple's MFMessageComposeViewController API for sending routine completion SMS messages. This is the correct and only supported approach on iOS:

• No SEND_SMS permission needed — unlike Android's SEND_SMS, iOS has no such permission. MFMessageComposeViewController presents the system Messages composer and the user must tap Send manually
• Device capability check — canSendText() is checked before presenting, gracefully handling devices without SMS capability (iPad, iPod touch, simulator)
• User always confirms — the system Messages sheet appears with the pre-filled message and the user must explicitly tap Send. No automatic/silent SMS sending is possible
• Contact picker — uses CNContactPickerViewController with a predicate for contacts with phone numbers. The NSContactsUsageDescription in Info.plist explains the purpose
• Phone numbers are stored in the database (contactsJson column in routines), which is now protected by both NSFileProtectionCompleteUnlessOpen at rest and SQLCipher database encryption

SMS messages are inherently unencrypted (SMS protocol limitation). The message content is non-sensitive ("DailyCue notification: [name] just completed the [routine] routine! ✅"), and the feature requires explicit user opt-in (SMS must be enabled in settings, contacts must be added to routines).

SettingsRepository.swift:107–119 defines a private helper updateField() that interpolates the column name directly into the SQL string:

Why this is currently safe (mitigating factors):

• The method is private — only accessible within SettingsRepository itself
• All 18 callers pass hardcoded string literals for column names (e.g. "reminderDurationMinutes", "themeName", "ownerName")
• The value portion is properly bound via positional ? parameterization — no user data reaches the column name
• No public API exposes this method or accepts arbitrary field names

Why it's a design smell:

• Column names cannot be parameterized in SQL — they must be interpolated or whitelisted. String interpolation for any SQL fragment bypasses GRDB's type-safe query builder
• If the method visibility is widened (e.g., to internal or public) or a future caller accepts a field name from user input, this becomes an exploitable SQL injection vector
• GRDB's query builder (Column("name")) handles column references safely and prevents typos — switching to it would eliminate this risk category entirely
• A comparable pattern led to real CVEs in other iOS apps where column names were derived from user-facing filters

WalkthroughRepository.swift and PredefinedRoutinesSeeder.swift use UserDefaults.standard for persisting walkthrough progress and first-launch seeding state:

• Walkthrough state — 5 keys per screen (version, completed, skipped, last step index) stored as boolean/integer values in UserDefaults XML plist
• Seeding flag — has_seeded_predefined_routines boolean in UserDefaults

This is an inconsistency in the app's data protection strategy. The database files receive NSFileProtectionCompleteUnlessOpen (DailyCueDatabase.swift:114–117) and SQLCipher encryption, while Keychain items use kSecAttrAccessibleWhenUnlockedThisDeviceOnly. In contrast, UserDefaults plist files are stored without an explicit file protection level and rely solely on the device's keybag encryption.

Risk assessment:

• No sensitive data — walkthrough completion status and boolean seed flags carry no personal or confidential information
• iOS default protection — UserDefaults files on iOS 15+ inherit NSFileProtectionCompleteUntilFirstUserAuthentication from the app's sandbox by default, providing moderate at-rest protection
• Physical access scenario — on a device without a passcode, or with an attacker who has filesystem-level access, the plist contents are readable
• No sensitive data exposure — even if read, the data reveals nothing about the user's schedule, contacts, or personal information

NotificationManager.swift accepts Int parameters for scheduleNotification(id:) (line 54) and scheduleSnoozedNotification(id:) (line 77) notification identifiers, but event IDs throughout the codebase are typed as Int64. The identifier string is built via string interpolation:

On 64-bit iOS, Int and Int64 are the same width, so the truncation risk is theoretical. However, the type mismatch means the API surface communicates the wrong contract — a caller passing an Int from a truncated source (e.g., a 32-bit value cast to Int) would silently produce a different identifier than expected, leading to duplicate notifications or failed cancellation.

BackupManager.exportTo() (line 77) embeds a hardcoded version string in the backup envelope:

This string was "1.2.6" during the original review, was updated to "1.2.13" during Re-check v3 work but has not been kept in sync with the actual app version (currently 1.2.16). The backup integrity is independently protected by SHA-256 checksum and HMAC signing, so this does not affect security. However, it could confuse cross-version restore debugging and is a maintenance hygiene concern.

ScheduleRepository.swift differentiates routine vs. appointment events by checking whether the tags column contains the substring "routine":

This heuristic appears in both deleteRoutinesByTitle() and deleteFutureAppointmentsByTitle(). While tags are set to "routine" during event creation for routine-generated events, the Event model makes tags a user-editable string field. A user who creates an appointment with the word "routine" in the tags (e.g., "daily routine checkup") would have that event incorrectly classified during bulk operations.

NotificationRescheduler.swift (lines 75-76, 137) uses privacy: .public for reconciliation context strings:

The context values themselves are simple identifiers ("launch", "settings", "delete-event") and do not contain sensitive data. However, the .public pattern could be copy-pasted into future logging statements where the interpolated value is sensitive (e.g., user names, event titles, phone numbers). Swift's OSLog by default redacts dynamic values — .public must be explicitly opted into.