Swift

Use this skill for Swift code that needs strong API boundaries, predictable threading, and idiomatic Apple-platform integration. When the code is part of a Nitro Module, pair this with build-nitro-modules for generated specs, Promise mapping, and HybridObject constraints.

Workflow

1. Read the local Swift code, generated protocols, and surrounding API shape before editing.
2. Choose the public type model first: make invalid states unrepresentable where Swift can express them.
3. Choose one concurrency model for the feature before writing implementation code.
4. Keep synchronous properties and methods cheap, local, and nonblocking.
5. Make queue hops, hardware/session negotiation, I/O, and fallible async work explicit in the API.

Type-Safe API Design

• Represent state variants with types, not nullable clusters. Use protocols plus conforming structs/classes when variants share a public contract, or use enum with associated values when the set is closed and value-like.
• Keep related fields nonoptional on the same variant. If barcode and barcodeType are meaningful only together, put both on ScannedBarcode; do not make both optional on a generic scanned-data struct.
• Use optionals only for real domain absence inside one state, not for expressing which state the object is in.
• Prefer compile-time flow over caller-side probing. If callers need repeated if let chains to discover valid field combinations, the API shape is probably wrong.