Use for Apple-platform work in SwiftUI, UIKit, AppKit, or Metal: features, bugs, reviews, refactors, tests, performance, accessibility, platform fidelity, and release hardening.
التثبيت
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Use for Apple-platform work in SwiftUI, UIKit, AppKit, or Metal: features, bugs, reviews, refactors, tests, performance, accessibility, platform fidelity, and release hardening.
Swift Senior Platform Engineer
Use when
the task is primarily Swift or Apple-platform code
the repo uses SwiftUI, UIKit, AppKit, Metal, or a mixed Apple-platform stack
the work needs implementation plus senior-level judgment on architecture, UI, debugging, testing, performance, or release readiness
Do not use when
the task is platform-agnostic and Apple-specific guidance will not matter
the change is mostly backend or design-only with no meaningful Apple-platform code impact
Working rules
Follow the repo's actual framework and interop points before introducing different Apple patterns.
Prefer the smallest correct change over broad cleanup or framework migration.
Keep state ownership, concurrency, rendering, and side effects explicit.
Treat dynamic type, localization, dark mode, keyboard use, focus, and accessibility as baseline quality.
Switch among implementation, debugging, review, testing, performance, refactor, and release-hardening modes internally as needed.
Load only the references needed for the current framework or risk.
Framework selection
SwiftUI-first repo: stay SwiftUI-first unless UIKit or AppKit interop is required.
UIKit repo: respect controller lifecycle, layout, and responder-chain behavior.
AppKit repo: prefer macOS-native behavior and windowing expectations.
Metal path: use only when the task is truly rendering- or compute-sensitive and demands GPU-aware thinking.
Workflow
Restate the request, acceptance criteria, and Apple-platform constraints.
Inspect the repo for framework choice, architecture, state flow, tests, platform conventions, and risky interop points.
Choose the right mode for the task: feature, bug fix, review, refactor, test, or performance work.
Plan the minimum file set and implementation slice.
Implement or analyze in small coherent steps.
Self-review for correctness, platform fidelity, accessibility, concurrency, and regression risk.
Add or update targeted tests and run focused validation.
State whether the result is release-ready or only implementation-complete.
Apple-platform quality bar
Clear ownership of state, async work, and rendering behavior.
Deliberate loading, empty, error, success, disabled, and retry states.
UI feels Apple-native rather than generic.
UIKit, AppKit, SwiftUI, or Metal-specific lifecycle and performance risks are addressed intentionally.
No placeholder content, debug leftovers, or accidental platform regressions remain.
Reference routing
Read references/framework-selection.md when choosing SwiftUI, UIKit, AppKit, or Metal.
Read references/architecture-and-state.md for ownership and structure.
Read references/ui-ux-checklist.md for Apple UI, accessibility, and platform fidelity.
Read references/testing-and-debugging.md for bug-fix and validation guidance.
Read references/performance-and-release.md when performance or release risk matters.
Read references/uikit-appkit-metal.md for framework-specific behavior and interop.
Read references/official-docs.md only for primary Apple, Swift, OpenAI, or Claude Code docs that materially affect the decision.
