relevancekit
Increase widget visibility on Apple Watch using RelevanceKit. Use when providing contextual relevance signals for watchOS widgets, declaring time-based or location-based relevance, combining multiple relevance providers, helping the system surface the right widget at the right time on watchOS 26, or routing mixed RelevanceKit/WidgetKit/HealthKit/MapKit Smart Stack scope.
Security Assessment
About relevancekit
RelevanceKit supplies on-device contextual clues that raise a widget's visibility in the Apple Watch Smart Stack, telling watchOS when a widget matters based on time, location, fitness state, sleep schedule, or connected hardware. Targeting Swift 6.3 and watchOS 26+, the skill explains the two mechanisms watchOS uses to judge relevance and when to pick each. A timeline provider approach adds a relevance() method to an existing AppIntentTimelineProvider, attaching RelevantContext clues to timeline entries; this shares code across platforms, though only watchOS acts on the data, and suits widgets that always have something to show with relevance as a supplement. The relevant-widget approach uses RelevanceConfiguration with a RelevanceEntriesProvider to build a widget driven entirely by relevance clues, letting the system create individual Smart Stack cards per matching entry, which is ideal when a widget should appear only when conditions match or when several cards should surface at once. Those configuration types are watchOS 26+ only. Key types span both modules: RelevantContext from RelevanceKit and WidgetRelevance, WidgetRelevanceAttribute, and WidgetRelevanceGroup from WidgetKit. Permission requirements are mapped per clue: location clues need the containing app to request access and the widget extension to declare NSWidgetWantsLocation (checked via CLLocationManager.isAuthorizedForWidgetUpdates), fitness clues need HealthKit access to workout or activity-ring types, and sleep clues need sleepAnalysis, while date and headphone clues need none. Time-based relevance can be a single date or a date paired with a DateKind hint such as .scheduled or .informational. A boundary-routing section keeps the skill focused on relevance concerns and hands timelines, rendering, and widget pushes to WidgetKit, workout and health data to HealthKit, and search, directions, and geofencing to MapKit/CoreLocation. The skill is flagged beta-sensitive, advising a documentation re-check before strong availability claims.
FAQ
When should I use a timeline provider versus a relevant widget?
Use a timeline provider's relevance() when the widget always has data and relevance is supplementary; use a relevant widget (RelevanceConfiguration plus RelevanceEntriesProvider) when it should appear only when conditions match or when multiple cards should surface at once.
Does RelevanceKit do anything on iOS?
RelevantContext is declared across platforms (iOS 17+, watchOS 10+), but relevance functionality only takes effect on watchOS; calling the API elsewhere has no effect.
What permissions do location relevance clues need?
The containing app must request location access and the widget extension must declare NSWidgetWantsLocation; in code, check CLLocationManager.isAuthorizedForWidgetUpdates before relying on location clues.
Which clues require HealthKit?
Fitness clues (.fitness(.workoutActive) needs HKWorkoutType; .activityRingsIncomplete needs exercise, move, and stand time) and sleep clues (.sleep needs sleepAnalysis).
Which APIs are watchOS 26+ only?
RelevanceConfiguration, RelevanceEntriesProvider, and RelevanceEntry. The timeline-provider relevance() approach works on shared provider code across iOS 18+, macOS 15+, visionOS 26+, and watchOS 11+.
Install relevancekit
Quick Setup:
- Copy the skill folder to
.claude/skills/ - Claude will automatically detect and use the skill
Repository
dpearson2699/swift-ios-skills