Apple Communication Workflow
Purpose
Route an Apple communication feature to the documented framework and dedicated
workflow that owns it. This is a decision and handoff skill; use
apple-dev-skills for implementation, build, and device validation.
Supported Lanes
- iMessage app and collaboration: a Messages extension creates interactive,
app-specific messages; Shared with You connects app-owned collaboration
metadata to system surfaces.
- Communication notification: a Notification Service Extension enriches a
mutable remote alert before delivery; communication and Time Sensitive
behavior require the applicable capability and intent integration.
- Push to Talk: PushToTalk owns system controls and channel events while the
app owns the backend, audio transport, and channel membership.
- VoIP calling: CallKit or LiveCommunicationKit owns system call UI and
transactions; PushKit handles arrival; AVFAudio owns audio policy; SIP or
WebRTC remains a transport decision.
- Default app: iOS/iPadOS default messaging, calling, dialer, and carrier
messaging roles have distinct entitlements, routing, and regional limits.
- macOS companion: when there is no documented macOS default-app role, build
an app-owned client and integrations rather than claiming control of Phone or
Messages.
Workflow
- Use Xcode DocumentationSearch before planning Apple behavior; confirm framework availability and capability requirements.
- Route to exactly one detailed workflow:
imessage-app-and-collaboration-workflow, communication-notifications-workflow, push-to-talk-workflow, voip-sip-calling-workflow, or default-communication-app-workflow.
- For Phone or Messages MCP evaluation, inspect public source, supported API, requested permissions, storage, authentication, audit behavior, and live test evidence before recommending it. Never authorize or automate personal calls/messages without the user's explicit instruction.
- Hand implementation to the relevant Apple framework and Xcode validation workflows.
Output
Return the lane, detailed workflow, documented behavior, required
targets/capabilities or privacy keys, data and authorization boundary,
validation device requirement, and owning Apple skill. Clearly call out the
difference between a documented iOS/iPadOS default-app role and an app-owned
macOS companion implementation.
1---2name: apple-communication-workflow3description: Route an Apple communication request to iMessage collaboration, communication notifications, Push to Talk, VoIP calling, default-app, or macOS companion workflows before implementation.4---56# Apple Communication Workflow78## Purpose910Route an Apple communication feature to the documented framework and dedicated11workflow that owns it. This is a decision and handoff skill; use12`apple-dev-skills` for implementation, build, and device validation.1314## Supported Lanes1516- **iMessage app and collaboration:** a Messages extension creates interactive,17 app-specific messages; Shared with You connects app-owned collaboration18 metadata to system surfaces.19- **Communication notification:** a Notification Service Extension enriches a20 mutable remote alert before delivery; communication and Time Sensitive21 behavior require the applicable capability and intent integration.22- **Push to Talk:** PushToTalk owns system controls and channel events while the23 app owns the backend, audio transport, and channel membership.24- **VoIP calling:** CallKit or LiveCommunicationKit owns system call UI and25 transactions; PushKit handles arrival; AVFAudio owns audio policy; SIP or26 WebRTC remains a transport decision.27- **Default app:** iOS/iPadOS default messaging, calling, dialer, and carrier28 messaging roles have distinct entitlements, routing, and regional limits.29- **macOS companion:** when there is no documented macOS default-app role, build30 an app-owned client and integrations rather than claiming control of Phone or31 Messages.3233## Workflow34351. Use Xcode DocumentationSearch before planning Apple behavior; confirm framework availability and capability requirements.362. Route to exactly one detailed workflow: `imessage-app-and-collaboration-workflow`, `communication-notifications-workflow`, `push-to-talk-workflow`, `voip-sip-calling-workflow`, or `default-communication-app-workflow`.373. For Phone or Messages MCP evaluation, inspect public source, supported API, requested permissions, storage, authentication, audit behavior, and live test evidence before recommending it. Never authorize or automate personal calls/messages without the user's explicit instruction.384. Hand implementation to the relevant Apple framework and Xcode validation workflows.3940## Output4142Return the lane, detailed workflow, documented behavior, required43targets/capabilities or privacy keys, data and authorization boundary,44validation device requirement, and owning Apple skill. Clearly call out the45difference between a documented iOS/iPadOS default-app role and an app-owned46macOS companion implementation.
gaelic-ghost