agentleFS
daveebbelaardaveebbelaar/bama/skills/code/swift-swiftui/SKILL.md

swift-swiftui

Skill1.7k starsChanged 10 days agoMITView on GitHub

Swift 6 and SwiftUI code rules for macOS apps, including concurrency, state, SwiftData, AppKit bridges, and fixes for common compiler errors. Use when writing, reviewing, or debugging Swift code in a Mac app, or on concurrency, Sendable, or "not in scope" errors.

3 other projects use a version of this, 1 of them edited.

Adopted by

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Most recently taken up by

Who's talking about daveebbelaar/bama

The biggest 5 of 42 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 42

Talked about on GitHub, YouTube and the web (42 times).

On GitHub · 20

15 more on GitHub

On YouTube · 13

8 more on YouTube

On the web · 9

4 more on the web

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every new property has a default value, so existing stores still open.

    line 56
  2. Very specific:

    Never name a type Task, View, Color, Image, Text, Section, Label, Menu, Group, or Settings.

    line 105
  3. Very specific:

    Use Todo, TaskItem, NoteSection.

    line 107

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Swift and SwiftUI

The code is right when it compiles with zero warnings in Swift 6 language mode and the app does what the story says. For how it should look, call the Skill tool with mac-design. For copyable view code, read ../../design/mac-design/patterns.md.

Concurrency

The template sets main-actor default isolation: every type and function runs on the main actor unless you say otherwise. UI code needs no annotations.

WorkPut it in
UI state, views, view modelsDefault (main actor)
CPU-heavy pure work (parsing, image work, diffing)A nonisolated function marked @concurrent
Shared mutable state used off the main threadAn actor
A C callback (event tap, Carbon hotkey, CoreAudio listener)A nonisolated static func that hops back with Task { @MainActor in ... }
  • Data that crosses actors is Sendable: structs and enums of Sendable values, or final class with only let properties.
  • MainActor.assumeIsolated { } inside a callback you know runs on the main thread (a main run loop Timer, a main queue notification).
  • Task { } inherits the actor. Task.detached only when it must not.
  • Fix a concurrency error at its type, not with @unchecked Sendable or nonisolated(unsafe). Those two are a last resort, with a comment why.
  • Runtime trap the compiler misses. A closure created inside a @MainActor type and passed to an API without a @Sendable closure parameter (DispatchSource.setEventHandler, DispatchWorkItem, addPeriodicTimeObserver, CoreAudio listener blocks) inherits the main actor. When it runs on a background queue, Swift 6 crashes the app. Write it as { @Sendable in ... }, and run every background path once after any concurrency change.

State

  • @Observable classes for models. @State in the view that owns one, @Bindable to bind to its properties, .environment(model) to share it.
  • @ObservationIgnored on caches, timers, and handles, so they never trigger a redraw.
  • @State for view-local values. @AppStorage for small preferences. Keychain for secrets.
  • ForEach(items) over values, never ForEach($items) for data the user can delete: a row can read an index that no longer exists and crash. Get a binding by looking the item up by id.

SwiftData

  • @Model classes, .modelContainer on the scene, @Query in views, @Environment(\.modelContext) to insert and delete.
  • Every new property has a default value, so existing stores still open.
  • Store at ~/Library/Application Support/<AppName>/. Allow an override (APP_STORE) so tests never touch the real data.
  • Give every model its own uid: UUID. persistentModelID changes on the first save, so it breaks selection and lookups.
  • Undo: register the reverse of each action on the window's undo manager. SwiftData's automatic undo is not reliable. Code in ../../design/mac-design/patterns.md (Undo with SwiftData).
  • Need SQL, a CLI, or several processes on one file? Use SQLite with WAL through a small library target instead.

Menu commands

SwiftUI Commands do not observe @Observable models, so a title or a .disabled(...) that reads the model goes stale. In testing, neither @FocusedValue (from .focusedSceneValue) nor an @ObservedObject inside the commands updated reliably: the menu stayed disabled with a row selected. What works: mirror the selection into a small ObservableObject, observe it in the App, and pass the values into the commands. The App's body then rebuilds the menus when they change.

@MainActor final class MenuState: ObservableObject {
    static let shared = MenuState()
    @Published private(set) var selection: Set<UUID> = []
    func update(_ s: Set<UUID>) { if selection != s { selection = s } }
}
// AppModel: var selection: Set<UUID> = [] { didSet { MenuState.shared.update(selection) } }

struct MyApp: App {
    @ObservedObject private var menu = MenuState.shared
    var body: some Scene {
        Window("App", id: "main") { ContentView() }
            .commands { AppCommands(model: model, selectedIDs: menu.selection) }
    }
}

Disable items with .disabled(selectedIDs.isEmpty) and resolve the target again when the item fires. Never ship items that stay enabled and do nothing. Check the menu from outside the app (test-mac-app skill, "Menu check").

A menu shortcut also fires while a text field has focus. Never use Delete, Command-Delete, arrows, or Return as menu shortcuts. Handle them on the list with .onDeleteCommand and .onKeyPress.

Names Swift already uses

Never name a type Task, View, Color, Image, Text, Section, Label, Menu, Group, or Settings. Task breaks every Task { }. Use Todo, TaskItem, NoteSection.

AppKit bridges

SwiftUI covers windows, lists, and forms. AppKit is still the answer for:

  • Floating panels that do not steal focus: NSPanel with .nonactivatingPanel hosting a SwiftUI view (NSHostingView, with sizingOptions = [] for a fixed frame).
  • Text views with custom behavior: NSViewRepresentable around NSTextView.
  • Status items with custom click handling: NSStatusItem.
  • Key and mouse monitors: NSEvent.addLocalMonitorForEvents. Remove the monitor when the view goes away.

For system hooks (hotkeys, Accessibility, screen capture), call the Skill tool with os-integrations.

Compiler errors

ErrorFix
cannot find 'X' in scope right after adding a fileswift package clean --scratch-path ~/Library/Developer/<AppName>/build
Main actor-isolated ... from a nonisolated contextMake the caller main-actor, or await the call
Sending 'x' risks causing data racesMake the type Sendable, or keep it on one actor
The compiler is unable to type-check this expressionSplit the view into smaller subviews or let constants
ambiguous use of 'Task'A type in your code is named Task; rename it

Fix the first error first. Later errors often come from it.

Swift 6 errors

Moving an existing Swift 5 app? Read ../../ship/build-and-verify/existing-app.md first: expect several build rounds, then hunt the runtime trap above.

ErrorFix
Static let of a non-Sendable type (formatter, NSFont, CFString)@MainActor on the enclosing type, a computed var, or a commented nonisolated(unsafe)
sending 'note' risks causing data races in a main-queue observerCopy the Sendable parts (an id, a pid) out of the notification before MainActor.assumeIsolated
Observer token captured before it is assignedKeep the token in a small @MainActor class
"pattern that the region-based isolation checker does not understand" in a task groupUse an array of Task { @MainActor in ... } and await each one
Vars changed from OperationQueue blocks under NSLockOSAllocatedUnfairLock(initialState:)
@objc action on an NSMenuItem subclass@MainActor @objc func

Done when the app builds with zero warnings in Swift 6 language mode and the story's acceptance checks pass.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.