Generate Apple HIG Status Component Code

Provides Apple Human Interface Guidelines guidance for status components - progress indicators, status bars, and watchOS activity rings - recommending the right indicator type and behavior for a given operation. It first checks for an existing .claude/apple-design-context.md project context file and only asks for information not already covered there.

Use when deciding how to show progress for a long-running operation, whether and how to hide the iOS/iPadOS status bar, or how to represent Move/Exercise/Stand activity data on watchOS. Related skills cover adjacent scope: hig-components-system for widgets/complications displaying progress or status, hig-inputs for gestures that trigger progress states like pull-to-refresh, and hig-technologies for the underlying HealthKit and VoiceOver APIs.

Progress indicator principles: show progress for operations longer than a second or two; use a determinate (filling) progress bar when duration or percentage is known, since it feels faster and more trustworthy than a spinner; use an indeterminate spinner only when duration is genuinely unknown, such as unpredictable network requests; place indicators inline near the content area rather than modal or distant; and never stack multiple simultaneous indicators - aggregate them into one representation or show only the most relevant.

Status bar principles: don't hide the status bar without good reason - reserve that for immersive experiences like full-screen media, games, or AR; match status bar style (light/dark) to content for adequate contrast; respect safe areas so no interactive content sits behind the status bar; and restore the status bar promptly when exiting immersive contexts.

Activity ring principles (watchOS): the ring metaphor is reserved for Move, Exercise, and Stand goals and shouldn't be repurposed for unrelated data; ring colors follow strong Apple Fitness conventions (red for Move, green for Exercise, blue for Stand); activity data should come from HealthKit APIs rather than manual tracking; and ring completions should be celebrated with animation and haptics.

Reference files: progress-indicators.md (determinate/indeterminate, inline placement, duration), status-bars.md (system info, visibility, style, safe areas), and activity-rings.md (Move/Exercise/Stand, HealthKit, color conventions).

Output format for each recommendation: indicator type with rationale (determinate vs. indeterminate), timing/animation guidance (duration thresholds, transitions), accessibility notes (VoiceOver progress announcements, live region updates), and platform-specific behavior. Clarifying questions asked when needed: whether duration is known, target platforms, typical operation length, and whether the indicator is system-level or in-app.

iOS/iPadOS/watchOS developers implementing progress feedback, status bar behavior, or fitness activity tracking who need Apple's platform-correct conventions rather than inventing custom status UI.