Widgets, App Clips and Live Activities: Mobile App Extensions
Users see the app not just inside it. A widget on the home screen, a live match score in the Dynamic Island, a mini-experience without installation—all of these are separate entry points, each with its own constraints and its own stack.
WidgetKit: Why You Can't Just "Add a Widget"
WidgetKit works through a Timeline Provider—the widget doesn't live in memory constantly, but requests data snapshots in advance. The most common mistake: a developer tries to show real-time data via URLSession directly from getTimeline(). Apple doesn't forbid it, but with aggressive updates, the system starts throttling requests, and the widget hangs on stale data.
The correct approach: the main app updates data via WidgetCenter.shared.reloadTimelines(ofKind:)—after receiving a push notification or when the user returns to foreground. The widget reads data from a shared App Group container via UserDefaults(suiteName:) or file storage. No direct network requests in the provider in production.
iOS 17 introduced AppIntent-based interactive widget—buttons and toggles right on the widget without opening the app. Implemented via Button(intent:) in the widget's SwiftUI markup. Works only for simple actions; complex logic should transition to the app via widgetURL.
Live Activities and Dynamic Island
Live Activities—a mechanism for displaying live data on the Lock Screen and in the Dynamic Island (iPhone 14 Pro+). Launched via ActivityKit, updated via liveactivity-type push notifications with payload up to 4KB.
Architecturally, this is a separate SwiftUI target with two views: compact (Dynamic Island) and expanded (Lock Screen). Data is passed via ActivityAttributes—a strictly typed structure. The dynamic part is ContentState, the static (doesn't change during the activity)—in ActivityAttributes directly.
Typical problem: Live Activity doesn't update on device, even though push is sent. Reason—the app lacks permission for background push or apns-push-type is set incorrectly. In production, you need apns-push-type: liveactivity and the token from activity.pushToken.
App Clips vs Android Instant Apps
App Clips (iOS) and Instant Apps (Android) solve a similar problem—give the user functionality without installing the full app. But the implementation is fundamentally different.
App Clip is a separate target in Xcode, maximum 15MB, launched via NFC tag, QR code, Safari Smart App Banner, or link in Messages. Access is limited: no Keychain sharing with the main app without explicit setup, no HealthKit access, no push notifications (only ephemeral). App Clip Card is configured in App Store Connect, and metadata errors—a frequent cause of review rejection.
Android Instant Apps are built on modular architecture: the app is split into feature modules, each of which can be loaded separately via Play Feature Delivery. Instant App is a feature module with <dist:module dist:instant="true">. Limitation—no more than 15MB total for instant delivery.
| Parameter | App Clips | Instant Apps |
|---|---|---|
| Max Size | 15 MB | 15 MB |
| Launch Triggers | NFC, QR, URL, Safari | URL, Google Search, Play Store |
| Shared Keychain | Via App Group | Via SharedPreferences/Keystore |
| Recommended Scenario | Payment, landing, demo | Game demo, one-off services |
Development Process
Start with an audit: which app functions actually need to be outside it, and which mechanism fits. A weather forecast widget—WidgetKit. Real-time delivery tracking—Live Activity. Checkout payment—App Clip.
Test each extension in isolation. WidgetKit rendering is convenient to check via Xcode Widget Gallery, Live Activities—via emulator with forced push send via xcrun simctl push.
Timeframes range from 1 week for a simple informational widget to 4-6 weeks for an App Clip with onboarding and payment flow.