Agent skills for iOS, iPadOS, Swift, SwiftUI, and modern Apple framework development.
80
100%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Advisory
Suggest reviewing before use
ActivityKit owns real-time, glanceable Live Activities displayed on the Lock
Screen and Dynamic Island. Ordinary timeline widgets belong in widgetkit, and
generic APNs setup belongs in push-notifications; ActivityKit owns the Live
Activity lifecycle and payload contract. aps.content-state must decode into
the exact ActivityAttributes.ContentState shape, including any coordinated
custom date/range encoding. Modern ActivityContent lifecycle examples require
iOS 16.2+ unless noted.
See references/activitykit-patterns.md for complete code patterns including push payload formats, concurrent activities, state observation, and testing.
NSSupportsLiveActivities = YES.ActivityAttributes.ContentState; encode and decode a representative
fixture that matches the server payload contract.ActivityConfiguration and preview Lock Screen and Dynamic Island
states, including stale and terminal content.ActivityAuthorizationInfo.areActivitiesEnabled, then request and
observe the activity lifecycle.Run through the Review Checklist at the end of this document.
Define both static data (immutable for the activity lifetime) and dynamic
ContentState (changes with each update). Keep ContentState small because
the entire struct is serialized on every update and push payload.
import ActivityKit
struct DeliveryAttributes: ActivityAttributes {
// Static -- set once at activity creation, never changes
var orderNumber: Int
var restaurantName: String
// Dynamic -- updated throughout the activity lifetime
struct ContentState: Codable, Hashable {
var driverName: String
var estimatedDeliveryTime: ClosedRange<Date>
var currentStep: DeliveryStep
}
}
enum DeliveryStep: String, Codable, Hashable, CaseIterable {
case confirmed, preparing, pickedUp, delivering, delivered
var icon: String {
switch self {
case .confirmed: "checkmark.circle"
case .preparing: "frying.pan"
case .pickedUp: "bag.fill"
case .delivering: "box.truck.fill"
case .delivered: "house.fill"
}
}
}Set staleDate on ActivityContent to tell the system when content becomes outdated. The system sets context.isStale to true after this date; show fallback UI (e.g., "Updating...") in your views.
let content = ActivityContent(
state: state,
staleDate: Date().addingTimeInterval(300), // stale after 5 minutes
relevanceScore: 75
)Use Activity.request to create and display a Live Activity. Pass .token as
the pushType to enable remote updates via APNs. The ActivityContent request
shown here requires iOS 16.2+.
let attributes = DeliveryAttributes(orderNumber: 42, restaurantName: "Pizza Place")
let state = DeliveryAttributes.ContentState(
driverName: "Alex",
estimatedDeliveryTime: Date()...Date().addingTimeInterval(1800),
currentStep: .preparing
)
let content = ActivityContent(state: state, staleDate: nil, relevanceScore: 75)
do {
let activity = try Activity.request(
attributes: attributes,
content: content,
pushType: .token
)
print("Started activity: \(activity.id)")
} catch {
print("Failed to start activity: \(error)")
}Update the dynamic content state from the app. Use AlertConfiguration to
trigger a visible banner and sound alongside the update.
let updatedState = DeliveryAttributes.ContentState(
driverName: "Alex",
estimatedDeliveryTime: Date()...Date().addingTimeInterval(600),
currentStep: .delivering
)
let updatedContent = ActivityContent(
state: updatedState,
staleDate: Date().addingTimeInterval(300),
relevanceScore: 90
)
// Silent update
await activity.update(updatedContent)
// Update with an alert
await activity.update(updatedContent, alertConfiguration: AlertConfiguration(
title: "Order Update",
body: "Your driver is nearby!",
sound: .default
))End the activity when the tracked event completes. Choose a dismissal policy to control how long the ended activity lingers on the Lock Screen.
let finalState = DeliveryAttributes.ContentState(
driverName: "Alex",
estimatedDeliveryTime: Date()...Date(),
currentStep: .delivered
)
let finalContent = ActivityContent(state: finalState, staleDate: nil, relevanceScore: 0)
// System decides when to remove (up to 4 hours)
await activity.end(finalContent, dismissalPolicy: .default)
// Remove immediately
await activity.end(finalContent, dismissalPolicy: .immediate)
// Remove after a specific time (max 4 hours from now)
await activity.end(finalContent, dismissalPolicy: .after(Date().addingTimeInterval(3600)))Always end activities on all terminal code paths -- success, user/app
cancellation, sign-out/session stop, unrecoverable app error, and terminal server
failure. If the server says the tracked event can no longer continue or be
represented accurately, apply or send a final terminal state and end the activity
instead of leaving stale progress visible. When reviewing duration claims,
distinguish the active lifetime (up to 8 hours unless the app or user ends it
sooner), system-ended Lock Screen presence (up to 4 additional hours, for 12
hours total from start), and app-ended .default dismissal linger (up to 4 hours
after ending).
The Lock Screen is the primary Live Activity display surface. Every device with iOS 16.1+ displays Live Activities here. Design this layout first, then adapt for Dynamic Island where available.
struct DeliveryActivityWidget: Widget {
var body: some WidgetConfiguration {
ActivityConfiguration(for: DeliveryAttributes.self) { context in
VStack(alignment: .leading) {
Text(context.attributes.restaurantName).font(.headline)
if context.isStale {
Label("Updating...", systemImage: "arrow.trianglehead.2.clockwise")
.foregroundStyle(.secondary)
} else {
Text(timerInterval: context.state.estimatedDeliveryTime, countsDown: true)
.monospacedDigit()
}
}
.padding()
} dynamicIsland: { context in
DynamicIsland {
DynamicIslandExpandedRegion(.center) {
Text(context.attributes.restaurantName).font(.headline)
}
DynamicIslandExpandedRegion(.trailing) {
Text(timerInterval: context.state.estimatedDeliveryTime, countsDown: true)
}
} compactLeading: {
Image(systemName: "box.truck.fill")
} compactTrailing: {
Text(timerInterval: context.state.estimatedDeliveryTime, countsDown: true)
} minimal: {
Image(systemName: "box.truck.fill")
}
}
}
}The Lock Screen presentation has limited vertical space. Avoid layouts taller
than roughly 160 points. On iOS 18+, use supplementalActivityFamilies when
you provide adaptive layouts beyond the default: .medium for iOS/macOS
Live Activity sizing and .small for watchOS Live Activity sizing.
ActivityConfiguration(for: DeliveryAttributes.self) { context in
// Lock Screen content
} dynamicIsland: { context in
// Dynamic Island
}
.supplementalActivityFamilies([.medium, .small])Dynamic Island presentations appear only on devices that include Dynamic Island. Design all three modes, but treat the Lock Screen as the primary surface since not all devices have a Dynamic Island.
Used when one Live Activity occupies Dynamic Island compact space. Space is extremely limited -- show only the most critical information.
| Region | Purpose |
|---|---|
compactLeading | Icon or tiny label identifying the activity |
compactTrailing | One key value (timer, score, status) |
Shown when multiple Live Activities compete for space. Only one activity gets the minimal slot. Display a single icon or glyph.
Shown when the user long-presses the Dynamic Island.
| Region | Position |
|---|---|
.leading | Left of the TrueDepth camera; wraps below |
.trailing | Right of the TrueDepth camera; wraps below |
.center | Directly below the camera |
.bottom | Below all other regions |
Apply a subtle tint to the Dynamic Island border:
DynamicIsland { /* expanded */ }
compactLeading: { /* ... */ }
compactTrailing: { /* ... */ }
minimal: { /* ... */ }
.keylineTint(.blue)Push-to-update sends Live Activity updates through APNs, which is more efficient than polling from the app and works when the app is suspended, subject to APNs delivery, priority, budget, and throttling.
Pass .token as the pushType when starting the activity, then forward the
per-activity update token to your server. Update tokens can rotate, so observe
activity.pushTokenUpdates and re-register every emitted token:
let activity = try Activity.request(
attributes: attributes,
content: content,
pushType: .token
)
// Observe token changes -- tokens can rotate
Task {
for await token in activity.pushTokenUpdates {
let tokenString = token.map { String(format: "%02x", $0) }.joined()
try await ServerAPI.shared.registerActivityToken(
tokenString, activityID: activity.id
)
}
}Send an HTTP/2 POST to APNs with these headers and JSON body:
Required device-token HTTP headers:
apns-push-type: liveactivityapns-topic: <bundle-id>.push-type.liveactivityapns-priority: 5 (lower priority) or 10 (immediate, counts against budget)The aps.alert payload controls visible alert/banner/sound behavior; priority
alone does not create an alert.
Put timestamp, event, and the full content-state inside aps. Validate
update, end, and push-to-start bodies against the complete examples in
Push-to-Update Payloads,
including the exact Codable date/range representation.
Start a Live Activity remotely without the app running (iOS 17.2+). Push-to-start tokens are ActivityKit-specific tokens from Activity<Attributes>.pushToStartTokenUpdates; they are distinct from ordinary app/device APNs tokens and per-activity update tokens:
Task {
for await token in Activity<DeliveryAttributes>.pushToStartTokenUpdates {
let tokenString = token.map { String(format: "%02x", $0) }.joined()
try await ServerAPI.shared.registerPushToStartToken(tokenString)
}
}Add NSSupportsLiveActivitiesFrequentUpdates = YES to Info.plist to increase
the system-managed push update budget. When cadence matters, check
ActivityAuthorizationInfo.frequentPushesEnabled and observe
frequentPushEnablementUpdates; Apple does not guarantee a fixed update rate.
Schedule a Live Activity to start at a future time. The system starts the activity automatically without the app being in the foreground. Use for events with known start times (sports games, flights, scheduled deliveries).
let scheduledDate = Calendar.current.date(
from: DateComponents(year: 2026, month: 3, day: 15, hour: 19, minute: 0)
)!
let activity = try Activity.request(
attributes: attributes,
content: content,
pushType: .token,
style: .standard,
alertConfiguration: AlertConfiguration(
title: "Game Starting",
body: "The live score is ready.",
sound: .default
),
start: scheduledDate
)Use the iOS 18+ style: request parameter to choose persistence behavior. Use
.standard for persistent Live Activities such as deliveries, rides, sports
scores, timers, and flight/status boards. Use .transient only for a
short-lived expanded Dynamic Island presentation; it can auto-end when the user
locks the device, collapses or shrinks the expanded presentation, leaves the
app, or does other work outside Dynamic Island.
let activity = try Activity.request(
attributes: attributes,
content: content,
pushType: .token,
style: .standard
)Live Activities can appear on a paired Mac and on the CarPlay Home Screen. No additional ActivityKit API is required, but validate compact layouts; buttons and toggles in Live Activities do not perform actions in CarPlay.
Broadcast updates to many Live Activities at once with an APNs-created channel
ID. Enable the broadcast capability outside Xcode, create the channel on the
server, then subscribe with .channel(channelID). Channel pushes update or end
Live Activities; they do not start them. Use apns-channel-id and expiration
for channel pushes instead of the device-token apns-topic example above.
let activity = try Activity.request(
attributes: attributes, content: content,
pushType: .channel(channelIDFromServer)
)DON'T: Put too much content in the compact presentation -- it is tiny. DO: Show only the most critical info (icon + one value) in compact leading/trailing.
DON'T: Update Live Activities too frequently from the app (drains battery). DO: Use push-to-update for server-driven updates. Limit app-side updates to user actions.
DON'T: Forget to end the activity when the event reaches any terminal state. DO: End activities on success, cancellation, sign-out, unrecoverable errors, and terminal server failures. A leaked activity frustrates users.
DON'T: Assume every device has Dynamic Island. DO: Design for the Lock Screen as the primary surface; Dynamic Island is supplementary.
DON'T: Store sensitive information in ActivityAttributes (visible on Lock Screen). DO: Keep sensitive data in the app and show only safe-to-display summaries.
DON'T: Forget to handle stale dates.
DO: Check context.isStale in views and show fallback UI ("Updating..." or similar).
DON'T: Ignore push token rotation. Tokens can change at any time.
DO: Use activity.pushTokenUpdates async sequence and re-register on every emission.
DON'T: Forget the NSSupportsLiveActivities Info.plist key.
DO: Add NSSupportsLiveActivities = YES to the host app's Info.plist (not the extension).
DON'T: Use the deprecated contentState-based API for request/update/end.
DO: Use ActivityContent for all lifecycle calls.
DON'T: Fetch network data or location directly from Live Activity views. DO: Pre-compute display values in the app or server and pass them through ActivityKit updates or pushes.
ActivityAttributes defines static properties and ContentStateNSSupportsLiveActivities = YES in host app Info.plistActivityContent (not deprecated contentState API)context.isStaleactivity.pushTokenUpdatesActivity<Attributes>.pushToStartTokenUpdatesalertcontent-state JSON matches the actual ContentState Codable shape, including coordinated date/range encoding.default lingerActivityAuthorizationInfo checked before startingfrequentPushesEnabled checked before assuming high-cadence pushesstyle:, .channel, and supplemental familiesstyle: choices are justified: .standard for persistent Live Activities, .transient only for short-lived expanded Dynamic Island presentationsaps.alert behavior are handled separately.tessl-plugin
skills
accessorysetupkit
references
activitykit
references
adattributionkit
references
alarmkit
references
app-clips
app-intents
app-store-optimization
app-store-review
apple-on-device-ai
appmigrationkit
references
audioaccessorykit
references
authentication
references
avkit
references
background-processing
references
browserenginekit
references
callkit
references
carplay
references
cloudkit
references
contacts-framework
references
core-bluetooth
references
core-data
core-motion
references
core-nfc
references
coreml
references
cryptokit
references
cryptotokenkit
references
debugging-instruments
device-integrity
references
dockkit
references
energykit
references
eventkit
references
financekit
references
focus-engine
gamekit
references
healthkit
references
homekit
references
ios-accessibility
ios-ettrace-performance
ios-localization
ios-memgraph-analysis
ios-networking
ios-simulator
references
mapkit
metrickit
references
musickit
references
natural-language
references
paperkit
references
passkit
references
pdfkit
references
pencilkit
references
permissionkit
references
photokit
push-notifications
realitykit
references
relevancekit
references
scenekit
references
sensorkit
references
speech-recognition
references
spritekit
references
storekit
swift-api-design-guidelines
swift-architecture
references
swift-charts
references
swift-codable
references
swift-concurrency
swift-formatstyle
references
swift-language
swift-security
references
swift-testing
swiftdata
swiftlint
swiftui-animation
swiftui-gestures
references
swiftui-layout-components
swiftui-liquid-glass
references
swiftui-patterns
swiftui-performance
swiftui-uikit-interop
swiftui-webkit
tabletopkit
references
tipkit
references
vision-framework
weatherkit
references
widgetkit
references