Optionals, and the Early Return That Loses Data

"Absence of capability is not absence of work."

What an Optional Promises

An Optional is Swift saying out loud that a value may not be there. if let, guard let, ?? and optional chaining are the tools for handling that absence, and the compiler will not let you forget it exists. That is the good part.

The bad part is that Swift makes it very easy to handle absence by doing nothing. guard let x else { return } compiles, reads tidy, and turns "this could not happen" into "nothing happened" — with no log, no error, and no sign to the user.

The Share Extension That Looked Successful

A family capture app on iOS had a share extension: share a note from any app, tap Post, and it lands in a shared App Group folder for the main app to import. The first version read the container like this: guard let root = SharedInbox.containerURL() else { return } — inside a method whose defer dismissed the sheet.

On an unsigned Simulator build the App Group entitlement did not exist, so the container URL was nil. The sheet appeared, Post dismissed it, and nothing was written. It looked exactly like success. On a capture surface that is the worst available failure: the user finds out days later, looking for something they never actually saved.

The shape generalizes. Any guard let … else { return } over an OS resource that can be absent for a configuration reason — an App Group container, a Keychain item, a photo library, a background mode — is a silent-loss bug waiting for the day the configuration is wrong. The fixed extension shows an alert that names the missing container, keeps the typed note with a "Keep editing" button, and only discards on an explicit choice.

Optional Chaining Can Also Do Nothing

A Mac client drove a web preview pane through its model: model.webView?.load(request). The web view was created only when its SwiftUI pane rendered, and the pane sat behind a condition that was false in a headless smoke test. webView stayed nil, the optional-chained call succeeded at doing nothing, no navigation callback ever fired, and the test waited forever. Optional chaining is the right tool when "not there" genuinely means "nothing to do". When it means "something upstream is broken", say so.

Three Honest Options

Throw when the caller can do something about it.
Surface when a person needs to know — an alert or a status line that names the missing thing.
Return quietly only when absence really means there is no work, and write a comment that says why.

Code

The silent version, and the honest one·swift

import Foundation

let group = "group.com.example.spark"

// Silent: a missing entitlement becomes "nothing happened".
func saveSharedNoteSilently(_ text: String) {
    guard let root = FileManager.default
        .containerURL(forSecurityApplicationGroupIdentifier: group) else { return }
    try? Data(text.utf8).write(to: root.appendingPathComponent("note.txt"))
}

// Honest: absence of the container is an error that names itself.
enum ShareSaveError: Error, CustomStringConvertible {
    case containerMissing(String)
    var description: String {
        switch self {
        case .containerMissing(let g):
            return "The shared folder \(g) is not reachable. Check the App Group entitlement on both targets."
        }
    }
}

func saveSharedNote(_ text: String) throws {
    guard let root = FileManager.default
        .containerURL(forSecurityApplicationGroupIdentifier: group) else {
        throw ShareSaveError.containerMissing(group)
    }
    try Data(text.utf8).write(to: root.appendingPathComponent("note.txt"), options: .atomic)
}

Exercise

Search a Swift codebase you have (or the Spark package once it grows) for else { return } and try?. For each hit, classify the absence it handles as: nothing to do, caller can act, or a person needs to know. Rewrite the worst one to throw or surface a named error, and write the one-line comment the remaining quiet returns deserve.

Hint

The dangerous ones sit next to OS resources: container URLs, Keychain lookups, file reads, authorization status. If the value can be missing because of how the app was built or configured, a quiet return hides a setup bug.