Where Coding Agents Go Wrong on Apple Platforms

"The most dangerous answer is the one that was true last year, on the other platform."

Why Apple Work Is Hard for Models

Every line of Swift in this family was written by coding agents working with Dad, which makes the family's incident log an unusually honest record of how those agents fail. Apple platforms are hostile to recall in three specific ways. The APIs move every year and carry a different availability on each OS. The training corpus leans heavily toward iOS SwiftUI tutorials and Swift 5-era code, while real Mac apps still live in AppKit. And a great deal of Apple knowledge is written as clicks — "open Signing & Capabilities, pick your team" — that do not survive a generated project or a terminal build.

Five Failure Shapes From the Record

The delivery reflex. A session finished an iOS milestone, installed it over a cable onto a locked phone, and reported the work done with TestFlight listed as a future step — twelve days after the family's TestFlight pipeline already existed. The cable install felt like shipping. It was a build check.
The click that does not persist. Setting the development team in Xcode's UI works until the next xcodegen regenerates the project and silently drops it. A handoff that said "create the App Store Connect record" without saying the archive had already registered the identifier sent the next step to Certificates, Identifiers & Profiles, which refused with no explanation — and three apps invented workaround identifiers that afternoon. The instruction was written by someone who had watched the archive run, for someone who had not.
Platform transfer. SwiftUI has a dictation API on iOS, so it must exist on watchOS. It does not: the watchOS SDK marks it unavailable, and the only honest way to know was to read the SDK's interface file.
Commands that succeed at doing nothing. security find-identity -v hides a self-signed identity, so a build script concluded the certificate was missing. pkill -f with a guessed pattern matched no process, exited quietly, and was reported as "killed and restarted by launchd".
Absolute claims about the platform. "This screen is the only way to switch dictation language on the watch" shipped as a button. The real switch was a swipe up on the system's own dictation screen. A claim of the form X is the only way to reach Y cannot be proven by getting X to work.

The Counter-Habits

Read the installed SDK, not memory. Availability attributes in the .swiftinterface files are the ground truth for what your Xcode can call on each platform.
Probe before you design. A ten-line program settles most "does the platform do X" questions faster than an argument.
Name the fact you actually verified. Uploaded, processed, assigned and installed are four facts. Report the one that is true.
Prefer the pipeline over improvisation. A family script that encodes a trap is worth more than a fresh, confident sequence of commands.

Code

Ask the installed SDK, not your memory, whether an API exists on a platform·bash

SDK=$(xcrun --sdk watchos --show-sdk-path)
IFACE="$SDK/System/Library/Frameworks/SwiftUI.framework/Modules/SwiftUI.swiftmodule/arm64e-apple-watchos.swiftinterface"
grep -n -B4 'public struct TextInputDictationBehavior' "$IFACE"
# @available(iOS 17.0, visionOS 1.0, *)
# @available(macOS, unavailable)
# @available(watchOS, unavailable)     <- the answer, straight from the SDK you build with
# @available(tvOS, unavailable)
# public struct TextInputDictationBehavior : Swift.Equatable, Swift.Sendable {

Exercise

Pick two SwiftUI or UIKit APIs you believe exist on iOS. Using the SDK-interface grep from the code block, check their availability on watchOS and macOS. Then write down one claim about Apple platforms you have repeated recently without verifying, and the ten-line probe or SDK lookup that would settle it.

Hint

Swap SwiftUI.framework for the framework you care about and change the platform in --sdk (macosx, iphoneos, watchos). If the symbol does not appear in the interface file at all, that is also an answer.