app-extension-architecture-workflowlisted

# App Extension Architecture Workflow ## Purpose Choose and structure an Apple app extension before implementation. Apple documents app extensions as separate bundles whose code runs in a separate process; the extension point and host define the lifecycle, APIs, and activation contract. This skill owns those reusable mechanics, not product-specific framework behavior. It owns extension-point routing, target and process boundaries, activation, entitlements, app groups and shared containers, bounded data flow, privacy, testing, signing, and distribution. It does not absorb MailKit, File Provider, Finder Sync, Safari, Messages/iMessage, communication-notification, VoIP, Push to Talk, widget, intent, or other product-framework guidance. ## When To Use - Use this skill when a request needs an Apple app extension but the right extension point, host relationship, or target structure is unclear. - Use this skill when planning a containing app and extension targets, process isolation, activation, app groups, shared containers, XPC, privacy boundaries, signing, or distribution. - Use `mailkit-workflow` for macOS Mail content blocking, message actions, compose sessions, or message security. - Use `file-provider-and-finder-sync-workflow` for remote storage synchronization or Finder badges, menus, and monitored-folder visibility. - Use `safari-extension-control-workflow` for Safari-specific extension and SafariServices choices. - Use Messaging Collaboration Skills for Messages/iMessa