Swift Keychain Basics

How it works

Keychain Services uses a query describing the item class, service and account. Choose accessibility according to the actual lifecycle requirement; this demo uses a device-only, unlocked-item policy. Sharing across targets or devices has separate entitlement and synchronisation rules. The example stores a fake value, not a real credential.

Apple-only setup and review status

Create a separate iOS SwiftUI App learning project in a suitable Xcode version, choose an appropriate simulator/device and replace the generated app/view Swift source with this complete file. Keep one @main entry point. Widget and App Clip lessons explicitly require their own extension/clip targets instead; capability, purpose-string, entitlement and account steps in the lesson must be completed separately. No Xcode project, signing certificate, account or service was provisioned here.

Bhylu has no Swift browser runner. The JavaScript/Python editors do not run these sources; Apache, PHP and MySQL are not required. Downloads are source text, never executable teaching endpoints.

Download the complete keychain.swift · Download all source files with hash checks

For the optional collection, save download-examples.mjs in a new folder and run node download-examples.mjs. A local preview uses node download-examples.mjs http://127.0.0.1:8000/examples/swift/. It refuses an existing bhylu-swift-examples folder and installs or executes no Swift automatically. Apple-only files remain separate Xcode learning examples, not a portable Swift package target.

Example

// Apple-only learning file: iOS 17+ target with a suitable Xcode SDK.
// Not compiled or run in this Windows/Linux review.
import SwiftUI
import Security


struct DemoView: View {
    @State private var notice = "No Keychain operation"
    private var key: [String: Any] {
        [kSecClass as String: kSecClassGenericPassword, kSecAttrService as String: "BhyluWorkshopTeaching", kSecAttrAccount as String: "demo-only"]
    }
    var body: some View {
        VStack(spacing: 20) {
            Button("Add fake demo value") {
                var item = key
                item[kSecValueData as String] = Data("not-a-real-secret".utf8)
                item[kSecAttrAccessible as String] = kSecAttrAccessibleWhenUnlockedThisDeviceOnly
                notice = "Add status: \(SecItemAdd(item as CFDictionary, nil))"
            }
            Button("Check demo item exists") {
                var query = key; query[kSecReturnAttributes as String] = true
                var result: CFTypeRef?
                notice = "Lookup status: \(SecItemCopyMatching(query as CFDictionary, &result))"
            }
            Button("Delete only this demo item", role: .destructive) { notice = "Delete status: \(SecItemDelete(key as CFDictionary))" }
            Text(notice)
        }.padding()
    }
}

@main
struct WorkshopDemoApp: App {
    var body: some Scene { WindowGroup { DemoView() } }
}

Expected behaviour and manual checks

Manual check on an Apple target: inspect success, duplicate-item and item-not-found statuses, then test device lock/accessibility according to the intended app policy. The buttons operate only on the fixed teaching service/account. Keychain behaviour was not executed here.

The query does not use a broad delete, and the lookup requests attributes rather than printing stored secret data. A production error policy should classify OSStatus values into meaningful outcomes without exposing credentials in logs.