3.2 Visual anatomy of a push notification
3.3 Rich content options
3.4 Interactive controls
3.5 Live activities
3.6 Delivery and reliability playbook
Short on time? Download this chapter into your AI: MD / DOCX / PDF or get a complete guide: ZIP
Sidenote: banners don’t show up if Game Mode is on (the user is playing a game), Do Not Disturb mode is on, or a custom focus mode that mutes notifications.
Edge cases: StandBy (landscape Lock Screen while charging) and Live Activities, which show as mini-widgets with a thumbnail and caption.
- Banner — see an example above: temporary (by default) or persistent (user-modified settings) banner at the top of the screen.
- Alerts are not push notifications, just modal messages that require user actions.
- Badges are red counters on an app’s icon that show the number of unread notifications/messages (YouTube and Slack in this example):
Feature | Banners | Alerts | Badges |
Appearance | A temporary notification that appears at the top of the screen or on the Lock Screen. Contains a brief message. | A pop-up box that appears in the center of the screen, dimming the app interface behind it. | A small red circle with a number (or just a dot) that appears on the corner of an app's icon on the Home Screen. |
User Interaction | Passive & Optional. Banners disappear on their own after a few seconds. The user can swipe it away or tap it to open the app, but no immediate action is required. | Forced & Immediate. The user must interact with it by tapping one of the provided buttons (e.g., "OK," "Cancel") to dismiss the alert and resume using the app. | Indirect & Asynchronous. Requires no immediate interaction. It's a persistent, non-interruptive reminder that there is new content or information to see inside the app. |
Visibility | High but transient. It grabs attention for a moment but doesn't persist on the main screen (it can be found later in the Notification Center). | Highest possible. It is a modal view that takes over the screen and blocks all other interaction with the app until it is addressed. | Low but persistent. It is only visible on the Home Screen and does not interrupt the user's current task. It remains until the user opens the app and clears the condition that triggered it. |
Common Use Case | Informing the user of a new event, like a new message, an email, a news update, or the completion of a background task. | For critical actions, errors, or confirmations. Examples: confirming a purchase, warning of data loss, or system-level permission requests. | Indicating a count of unread items, such as unread emails, new social media mentions, or pending tasks in a to-do list. |
Level of Urgency | Low to Medium | High / Critical | Low / Informational |
- Default Behavior is Stacking: iOS groups notifications from your app by default. The most recent alert is on top, and users can tap the stack to expand and see all of them.
- Intelligent Grouping is Best: By default ("Automatic" setting), you can control how notifications are grouped. For example, a messaging app should group alerts by conversation, not just by app. To enable this, have your developers use a thread-identifier for each unique conversation or event thread. This creates a much better, more organized user experience.
Dev Handoff - 2: Grouping notifications
- Users Have Final Control: Be aware that users can override your app's grouping settings. In their device settings, they can choose:
» By App: Puts all of your app's notifications into a single stack.
» Off: Shows every single notification individually.
- Goal: Avoid Being Turned Off. A well-organized notification strategy that uses intelligent grouping makes your app feel helpful, not spammy, reducing the risk that a user will disable your notifications entirely. For ongoing events like a delivery or live score, use a Live Activity notifications, which updates a single widget instead of sending multiple alerts.
- “Time Sensitive” badge. A rounded capsule bearing the words Time Sensitive (plus a tiny clock glyph) appears just below your app name, instantly signalling extra urgency.
- Full-alert entrance. iOS lights up the screen, plays the configured sound, and animates the banner exactly like an “Active” alert—even when the notification would normally be hidden by Scheduled Summary or a Focus mode.
- Priority placement. Because they bypass Summary and Focus, these alerts pop in at the very top of the Lock-Screen stack and in Notification Center. Siri will also read them aloud on AirPods/HomePod by default (provide a short, descriptive title—it will be read verbatim).
- Hardware-mute still respected. They don’t override the Ring/Silent switch, so sound is suppressed if the device is physically muted.
- One-time educational card. The first Time Sensitive alert your app sends triggers a system sheet explaining what that label means and offers a one-tap “Turn Off” option; iOS will remind users again if your app overuses the privilege.
- When to use. Only for events unfolding now or within the next hour that directly affect the user (e.g. fraud attempt, courier at the door, medicine reminder). Never for marketing.
Dev Handoff - 1: Constants that indicate the importance and delivery timing of a notification.
Dev Handoff - 2: Apple's WWDC 2021 video on how to send time sensitive notifications
Feature | Regular Notification | User-Silenced ("Deliver Quietly") | Developer's Silent Notification |
What it is | normal pushes | Focus, DND, mute mode, etc. | Background app refresh |
Banner Alert | Yes | No | No |
Lock Screen Alert | Yes | No | No |
Sound/Vibration | Yes | No | No |
Appears in Notification Center | Yes | Yes | No |
App Icon Badge | Yes | Yes (Optional) | No |
Visible to User? | Yes | Yes, but only if they look | No, never |
- Title (displays your app name if not specified) — around 25-30 characters (may include emojis; recommended: 2 words).
- Body text — 2-4 lines of text, around 130-150 characters; may include emojis; up to 7-8 lines of text in an expanded view (when the user long presses it)
- App icon
- Counter (on an icon) of stacked notifications
- Timestamp
Optional:
- Subtitle — around 30 characters (may include emojis)
- Thumbnail image (can define which part/frame of the embedded image/video to include as a thumbnail)
- You can also set a custom alert sound — up to 30 sec.
- iOS system language
- long or short timestamp (e.g. "37m ago" vs. “8:55 AM” vs. "now")
- a larger system font size enabled
- use of emojis (4 bytes per one)
Pro tip: don’t truncate - the OS handles this itself.
Rich notifications (images, videos, buttons, etc.) require a Notification Service Extension (NSE) and, optionally, a Notification Content Extension (NCE). These are literally separate targets/bundles in your app — like sandboxed mini-apps — with their own lifecycle, limitations, and logic.
Notification Service Extension (NSE) = Fetch & Modify
Purpose: Runs in the background to intercept and modify the content of an incoming push before it’s shown.
Common uses:
- Downloading and attaching an image, video, or audio
- Localizing or customizing message content
- Decrypting secure payloads
Key traits:
- Triggered by mutable-content: 1 in the payload
- Must finish its work in <30 seconds
- Has no UI — it’s purely logic and content transformation
Notification Content Extension (NCE) = Custom UI
Purpose: Provides a custom UI when a user expands the push (e.g., long-press or 3D Touch).
Common uses:
- Displaying a video player
- Interactive maps
- Swipeable carousels
- Custom layouts with buttons or sliders
- Lives in a separate UI bundle with its own Info.plist
- Runs only when user expands the notification
- Can use full UIKit views (within limits)
Feature | Service Extension (NSE) | Content Extension (NCE) |
Fetch external media (image/video) | ✅ | ❌ |
Modify text, localize, decrypt | ✅ | ❌ |
Custom layouts/UI for expanded push | ❌ | ✅ |
Needed for rich media | ✅ | Optional (but nice) |
Runs on every push? | ✅ (if mutable-content) | ❌ (only on expand) |
- Your visible text (title, subtitle, body)
- Structural JSON
- Any custom data fields (like deep links or extra metadata)
Because Apple measures payload size in bytes, not characters, the usable space depends on:
- Language (e.g., English text takes fewer bytes than, e.g., Japanese or emojis)
- Whether you’re including extra metadata or URLs
Rule of thumb: Aim for ~2,500–3,000 characters total for English-only text. But trim that down if you’re using emoji, non-Latin alphabets, or attaching media URLs.
❗If the total payload exceeds 4KB, Apple simply rejects the notification. It doesn’t get truncated — it fails silently.❗
Dev Handoff: Sending notification requests to APNs.
Dev Handoff - 1: Modifying content in newly delivered notifications.
Dev Handoff - 2: UNNotificationServiceExtension, an object that modifies the content of a remote notification before it’s delivered to the user.
Platform | UI Context | Element | Recommended Visible Characters (Range) | Notes & Contextual Factors |
iOS / iPadOS | Banner Alert | Title | 25-50 | Highly constrained. The full message is rarely visible. |
Subtitle | ~30-60 | Often not displayed or heavily truncated. | ||
Body | ~60-80 (1-2 lines) | Only the first one or two lines are visible. | ||
Lock Screen / Notification Center (Collapsed) | Title | 30-60 | Varies with timestamp length and OS version (e.g., iOS 15 UI). | |
Subtitle | ~40-60 (1 line) | Provides a single line of secondary context. | ||
Body | ~110-170 (2-4 lines) | The core visible area for most notifications. | ||
Expanded View | Title | 30-60 | Remains a single line. | |
Subtitle | ~40-60 (1 line) | Remains a single line. | ||
Body | Up to ~250+ (7+ lines) | Reveals much more text. Presence of rich media reduces space. Payload is the ultimate limit. | ||
watchOS | Short-Look | Title | 20-40 | CRITICAL: The only text displayed. Must be a complete thought. subtitle and body are ignored. |
Subtitle | N/A | Not displayed. | ||
Body | N/A | Not displayed. | ||
Long-Look | Title | 20-40 | Full title is visible at the top of a scrollable view. | |
Subtitle | ~30-50 (1 line) | Visible below the title. | ||
Body | Full Payload | The entire body text (within the 4KB payload limit) is accessible in a scrollable view. | ||
macOS | Banner Alert | Title | 30-50 | More screen real estate, but brevity is still key. |
Subtitle | ~40-60 | Generally visible. | ||
Body | ~80-120 | More text is visible than on iOS banners, but still truncated. | ||
tvOS | All Contexts | Title | N/A | No user-visible text alerts are supported. |
Subtitle | N/A | Functionality is limited to app icon badging and silent background pushes. |
A 100-character message in English might take ~100 bytes, while the same message in Japanese could require ~300 bytes (or more) — still well within the 4KB limit, but that byte inflation adds up fast with longer texts or additional metadata. Emojis are especially heavy — up to 4 bytes each.
Pro tip: Use Apple’s loc-key system to fetch localized text from the app instead of sending full translations in the payload — it saves space and reduces risk.
Dev Handoff: Generating a remote notification.
More on localization in chapter 5.
- Use 0–1 emoji in the title, max 1 in the body—only when it adds meaning.
- No ALL CAPS; use Title Case and emphasize one word if needed.
- Watch payload budget (each emoji ≈4 bytes) and truncation risk.
- A/B on your iOS cohort: none vs 1 emoji; emoji choice; emoji at start vs end. Track open/tap-through, opt-outs, and long-term decay (Braze, 2025 warns novelty effects fade).
Dev Handoff - 1: Customizing the Appearance of Notifications.
Dev Handoff - 2: UNNotificationContentExtension, an object that presents a custom interface for a delivered local or remote notification.
- Inline string: Build the final title/body on the server (e.g., “Hi Sarah, your order shipped”). The whole string is shipped in the payload, so the bytes for Sarah eat into your 4 KB budget and into the on-screen real estate.
- loc-key + loc-args: Send a short key (ORDER_SHIPPED_TITLE) and a lightweight args array (["Sarah"]). The device swaps the placeholder with the user’s name locally, saving payload bytes and sidestepping most of the 4 KB limit.
Pro tip: Use loc-key/loc-args if you want to stay payload-lean, and budget for ~50 visible characters in the title and <80 in the body so the user actually sees their name without an ellipsis.
Dev Handoff: Generating a remote notification.
- Layout is fluid, not fixed. iOS auto-truncates titles and body text based on screen size and the user’s Dynamic Type settings. A headline that fits on an iPhone 15 Pro Max can lose ~15 characters on a smaller iPhone SE or when “Larger Text” is enabled.
- The bigger the font, the fewer the lines. Banner alerts normally show 1–2 lines of body text (≈ 60–80 chars). With Accessibility text sizes, that can collapse to a single short line (≈ 30–40 chars) even though expanded views still allow scrolling.
- Let the OS handle truncation. Apple’s HIG explicitly says “don’t truncate—let the system do it,” so front-load key information in case the tail gets clipped.
- Test at the extremes. Apple recommends validating on an iPhone SE with the largest text setting, and on a Pro Max at default size, across locked screen, banners, and expanded views, with and without media.
Rule of thumb: Design for the tightest case — ≈ 25 chars for the title and ≈ 60 chars for the first body line—so your message still lands when space is scarce. Front-load the noun/verb (“Order shipped”) and you’ll survive any device or accessibility setting.
- Skip the vanity: Your name & icon already headline the card—don’t repeat them in the title.
- Front-load the verb: 25-char title, 60-char first body line; sentence-case; no SCREAMING.
- One ping per thing: Update via collapse-ID instead of spraying follow-ups.
- Use badges like Post-it notes: Only for items that require attention, and clear them the moment the user opens the relevant screen.
- Sounds should be polite cameos: <0.5 s, unique, and always respect the hardware mute switch.
- a (static) map view
- text input fields
- static images
- image carousels
- animated image sequence (gifs)
- videos
- inline audio clips
- custom fonts/colors (for text and background)
- interactive controls (for example, buttons, switches/toggles, timers)
- may change the placement of items, including title, subtitle, and text.
Here are a few examples of rich notifications:
# | Vertical | Rich Elements Used | What the User Sees / Does | Why It’s Exciting |
1 | Clinical Workflow | Text-input field | “Patient John Smith’s dosage changed. Confirm?” → Nurse taps, types “Adjusted to 5 mg BID,” hits ✅. | Closes micro-tasks without opening the EHR—bye-bye context switching. |
2 | Smart Home Security | Toggle switch | “Motion detected near garage.” Expand → Arm/Disarm switch right there. | Turns a nervous moment into a one-tap fix from the lock screen. |
3 | E-commerce Fashion | Image carousel / animated GIF | “New arrivals just dropped!” Swipe color variants, tap Add to Bag. | Visual dopamine + zero app latency → higher impulse buys. |
4 | Telehealth Follow-up | Inline video clip (≤30 s) | “Dr Patel: wound-care demo.” Patient watches mini-video, taps Acknowledge. | Boosts adherence; no hunting for the video inside the portal. |
5 | Home Security | Static map view | “Glass break — Backyard.” Map pin shows exact sensor spot. | Instant geography context—vital when managing multiple properties. |
6 | Voice-Messaging / Chat | Audio attachment + play/pause + text input | “🎤 New voice note from Maria.” Expand → 15-sec audio auto-plays; reply button below. | Lets users triage messages hands-free; keeps WhatsApp-style flow alive. |
7 | Baby-Monitor / Smart-Cam Alert | Audio clip + snapshot | “Baby stirred at 02:14.” Thumbnail + cry audio; tap Open Live Feed. | Parents know if it’s a real scream or a sleepy whimper—fast. |
8 | Guided Meditation / Fitness | Audio intro + quick-start button | “2-min Mindful Break ready.” Expand → soothing chime starts; Begin Session button logs the workout. | Turns idle moments (elevator, queue) into wellness reps—friction-free. |
9 | Fintech / Stock-Trading | Live sparkline, +/- ticker, “Buy / Sell” buttons | “$NVDA just hit $150 (+3.4%).” A tiny sparkline animates; buttons let the user fire a market-order in one tap. | Converts FOMO into instant trades without app load time. |
10 | EdTech Micro-Learning | Inline quiz card + text input | “Spanish Sprint: Translate ‘apple’.” A text field takes the answer; success animation pops. | Turns dead time (lock-screen) into spaced-repetition wins. |
11 | SaaS DevOps / On-Call | Log snippet + “Ack / Snooze” switches | “CPU spike on api-prod-3.” Expand to skim the highlighted log lines; toggle Snooze 15 min or Ack. | Saves bleary-eyed engineers a midnight app dive. |
12 | Auction / Flash-Sale Platforms | Countdown timer | “Lot 27 closes in 00:01:59.” A live countdown ticks; place a bid by choosing one of the options | Captures impulse bids while urgency is red-hot. |
13 | Healthcare RPM (Remote Patient Monitoring) | Vitals chart (mini line-graph) + call button | “Mrs. Chen’s BP spiked to 165/98.” Clinician expands to view a 24-h chart and taps Call to start a session. | Lets care teams intervene faster than EHR alerts alone. |
14 | Travel / Hotel Concierge | Room-upgrade carousel + “Select” buttons | “Last-minute suite upgrade -50%.” Swipe photos; tap Book to lock it in. | Drives high-margin upsells during peak excitement. |
15 | IoT Industrial / Field Service | Live camera thumbnail + toggle | “Pump #4 vibration anomaly.” Thumbnail autoplay of the on-site camera; toggle Shut Pump. | Cuts mean-time-to-mitigation when every minute costs money. |
16 | Interactive Polls / Social Engagement | Radio buttons + vote count + custom ocean wave sound | “Weekend plan? 🏖️/🎢/📚” Choose and see live percentages update. | Sky-high engagement for community-driven apps. |
17 | Post-Service Feedback (ride-share, food delivery, customer support) | Five-star buttons (interactive controls) | “How was your experience with Alex?” Five tappable star icons appear; user taps ★★★★☆, optional comment box slides down. | Harvests fresh, high-quality feedback without forcing an app hop—response rates skyrocket. |
- Images: 10MB (JPEG, PNG, GIF, HEIF)
- Videos: 50MB theoretical, 10-25MB practical due to 30-second download timeout
- Audio: 5MB (MP3, M4A, AIFF, WAV)
Here’s the same notification that loaded in time vs. not loaded within the 30-sec timespan:
– Device registration, APNs certificates, simple payload handling.
Rich-push jump-start: 40 – 60h
– A senior iOS dev adds a Notification Service Extension (and, if needed, a Content Extension), writes the 30-second media-download logic, and QA’s across iOS versions.
Rich element | Extra iOS hours¹ | When it blows up |
Image (PNG/JPEG) | +8 – 12h | Huge files, dark-mode variants |
Animated GIF / image seq. | +10 – 16h | Frame count & memory limits |
Audio | +12 – 18h | Custom controls, background quirks |
Video | +16 – 24h | HLS vs. MP4 fallback, autoplay rules |
Map snapshot | +20 – 30h | Live ETA refresh, geofencing |
Carousel (3–5 imgs) | +24 – 40h | Extra buttons, tap-tracking |
Text-input field | +12 – 20h | Localization-ready, validation, secure text. |
Interactive controls (buttons, toggles, timers) | +16 – 32h | Backend state sync, analytics |
Reality checks
- Estimates assume a mid-/senior iOS engineer; juniors will need hand-holding.
- Each extra interactive control or text field drags in backend endpoints, analytics, and extra App-Review scrutiny—effort climbs non-linearly.
- Treat rich push as a cross-functional feature: iOS, backend, design, and marketing must spec it together to avoid the dreaded “why did the timeline just triple?” meeting.
- 88-94% on iOS 18+ (latest features)
- 98% on iOS 10+ (basic rich notification support)
- Reaction Rates: Rich formats improve overall user reaction rates by 25%.
- Open Rates: Notifications with images can increase direct open rates by up to 56% compared to text-only messages.
- Click-Through Rates: In one study, the CTR for notifications with images was seven times higher.
When a notification arrives, iOS gives the app's extension a few seconds to download the media. If the download fails for any reason (e.g., poor network, slow server, oversized file), the system automatically discards the rich media and displays the standard, text-only version of the notification. This prevents crashes or a broken user experience.
Dev Handoff: Instance Method didReceive(_:) - delivers a new notification to your notification content app extension.
- Tap buttons to perform predefined actions (e.g., mark as read, accept an invitation).
- Input text using text input actions (e.g., reply to messages directly).
- Scroll
- Go to different app sections by tapping different UI elements in the custom notification UI.
Can't do:
- Use gestures
- Change UI elements
Dev handoff: UNNotificationContentExtension - an object that presents a custom interface for a delivered local or remote notification.
- Dark Mode: Rich notifications adapt to the dark theme if designed with dynamic colors and images.
- Low Power Mode: Notifications still function normally, though background activities may be limited.
- Low Data Mode: Notifications generally work, but large media downloads (e.g., videos) may be restricted; basic functionality remains intact.
- Apple Watch: appear first as a "short look" and can expand to a customizable "long look" that can display rich content like images. However, interactivity is more limited than on an iPhone.
- iPad: The experience is largely similar to the iPhone
- Mac: Rich notifications are displayed in the Notification Center. While they can show media, their interactive capabilities and custom layouts are more restricted compared to iOS.
If it fails to download the content within these limits due to a poor network connection, or if it crashes due to low storage, the system will abandon the rich content and display the original, non-rich notification. This ensures the user still receives the core message.
You can choreograph fancy haptics with Core Haptics or UIFeedbackGenerator, but only while the app is in the foreground (i.e., after the user has already opened it).
Sidenote: possible on Android.
Action Buttons
These actions execute directly from the notification—whether that's completing an Apple Pay transaction, submitting a star rating, snoozing a reminder, or approving an expense report.
The key differentiator: users complete micro-tasks in 1-2 taps rather than the 5-10 steps typically required when launching an app.
Apple distinguishes between default actions (blue text) and destructive actions (red text) to prevent accidental data loss. For instance, "Delete Message" appears in red while "Mark as Read" stays blue. You can also require authentication for sensitive actions—forcing Face ID before processing a payment or approving a document.
The most effective implementations use clear verb-noun combinations ("Approve Request," "Decline Invitation") and leverage icons to transcend language barriers. Remember: these aren't just shortcuts—they're complete workflows compressed into the lock screen.
Dev Handoff: Declaring your actionable notification types.
Here are a few examples:
Complete List of Possible Interactive Controls
Control | Supported User Interactions | Technical Limitations & Considerations |
Buttons (UIButton) | Tap: The most common interactive element. Can trigger background tasks or open the app to a specific screen. | Fully supported. Can be styled with text, icons, and custom backgrounds. Can trigger actions that require authentication. |
Switches (UISwitch) | Toggle: Allows for simple on/off state changes (e.g., enabling or disabling a setting). | The state change can be handled within the notification extension. The visual state of the switch can be updated immediately. |
Text Fields (UITextField) | Type: Users can input short text directly into the notification. This requires the system keyboard to be presented. | The text field must be configured to work with the limited lifecycle of the notification. Keyboard management can be complex. The UNTextInputNotificationAction is an alternative for simpler text input via an action button. |
Steppers (UIStepper) | Tap: Users can tap the increment or decrement buttons to change a numerical value. | Each tap is a discrete event, making this a viable control. The associated value can be displayed in a UILabel and updated with each tap. |
Segmented Controls (UISegmentedControl) | Tap: Allows the user to select one option from a few choices. | A good way to offer a limited set of mutually exclusive options. The selection change is a discrete event that can be handled by the extension. |
Checkboxes (Custom UIButton) | Tap: For selecting or deselecting items in a list. Implemented using a UIButton with different state images. | While there's no standard UICheckbox, a UIButton can be easily configured to function as one, toggling between selected and deselected states on tap. |
- No Dragging Gestures: The single biggest limitation is that the system does not support any drag-based gestures. This means interactive controls like sliders and pickers are not possible.
- Tap-Only Interactions: Because of the gesture limitation, you should only design controls that respond to a simple tap. This includes buttons, switches, steppers, and segmented controls. Anything more complex is off the table.
- Strict Resource Caps: Your notification has very limited resources. It gets about 12MB of memory and a short processing window (around 30 seconds) to load and handle any interactions.
- Requires Modern iOS: Interactive controls are only available for users on iOS 12 and later. If your user base is on older versions, they will not see the interactive elements.
- Default (executes in background)
- Foreground (opens app)
- Destructive (displays in red for delete/remove actions)
- Authentication-required (triggers Face ID/Touch ID).
Dev Handoff - 1: Handling notifications and notification-related actions
Dev Handoff - 2: UNTextInputNotificationAction - an action that accepts user-typed text.
- 1 button: 25-35 characters
- 2 buttons: 20-30 characters
- 3 buttons: 15-25 characters
- 4 buttons: 10-20 characters
- API calls and network requests
- Database updates (Core Data, UserDefaults)
- Update app badge count
- Process text input from reply actions
- Schedule local notifications
Requires app launch:
- Payment flows (including Apple Pay)
- Camera or photo library access
- Complex multi-screen workflows
- Any processing over 30 seconds
- Biometric authentication beyond the initial system prompt
Data updates: Full Core Data access available using background contexts. UserDefaults work immediately. File system access is restricted when device is locked.
Background processing: Standard URLSession works well within 30-second limit. Avoid Background URLSession (8+ minute delays). For longer tasks, hand off to BGTaskScheduler.
- Text too long (gets truncated with ellipsis)
- Forgetting to register notification categories at app launch
- Creating double authentication prompts
- Using generic text like "Yes/No" or "OK/Cancel"
Apple's HIG requirements:
- Use title case ("Mark as Read" not "mark as read")
- Use active verbs (Reply, Delete, Accept, Decline)
- Be specific and descriptive
- Avoid pronouns (me, you, my, your)
Think of them as mini-dashboards for time-sensitive operations: your Uber driver's location updating every few seconds, a food delivery ETA counting down, or a sports game score changing play-by-play—all without generating new notification sounds or banners.
While technically built on ActivityKit rather than the notification framework, Live Activities solve the same core problem: keeping users informed without overwhelming them. They're particularly powerful for scenarios lasting 5 minutes to 12 hours:
- tracking a workout
- monitoring flight delays
- following a parking meter countdown
- watching your Instacart shopper's progress through the store.
The visual persistence means users can glance at their Lock Screen for updates rather than opening your app repeatedly, transforming anxiety-inducing wait times into transparent, real-time experiences.
Dev Handoff: Displaying live data with Live Activities.
Here are a few examples:
Most Common Live Activities Use Cases
Category | Use Case | Real-Time Updates | Example Apps |
Delivery & Transportation | Food/package tracking | Driver location, ETA, order status | Uber, DoorDash, Instacart |
Rideshare journey | Route progress, driver details, fare | Lyft, Uber | |
Sports & Gaming | Live game scores | Score changes, player stats, time remaining | ESPN, TheScore |
Fantasy sports | Point updates, player performance | DraftKings, FanDuel | |
Travel | Flight status | Gate changes, delays, boarding time | Flighty, FlightRadar24 |
Transit directions | Next stop, arrival time, transfers | Citymapper, Transit | |
Fitness & Health | Workout tracking | Duration, heart rate, calories, pace | Strava, Nike Run Club |
Medication reminders | Countdown timer, dose tracking | Medisafe | |
Commerce & Services | Parking meters | Time remaining, expiry alerts | ParkWhiz, SpotHero |
Queue/wait times | Position in line, estimated wait | Disney, DMV apps | |
Productivity | Timer/stopwatch | Elapsed time for tasks, pomodoro | Toggl, Forest |
Task progress | Steps completed, time remaining | Todoist, Things | |
Entertainment | Live audio/podcast | Now playing, progress, controls | Spotify, Overcast |
Event countdowns | Time until concert, ticket info | StubHub, Ticketmaster |
Key Success Factors: Events lasting 5 min–12 hours, requiring frequent status checks, with clear start/end points.
The user might need to enable the updates for your Live Activity:
- Duration: A Live Activity can be active for a maximum of 8 hours. After it ends, it remains visible on the Lock Screen for up to 4 more hours before the system removes it (total 12-hour visibility).
- Update Frequency: There isn't a hard number like "one per second." Instead, your app gets a "budget" of push updates per hour. Exceeding this will get you throttled. The key is to send updates only when essential data changes, not on a fixed timer.
- Payload Size: Each data update you send, whether from the app or a push notification, cannot exceed 4KB. This requires you to be concise and send only the necessary dynamic data.
Dev Handoff: Displaying live data with Live Activities.
- Minimum OS: Live Activities were introduced with iOS 16.1. To maximize features like push-to-start, targeting iOS 17.2+ is better. Adoption for a year-old OS typically exceeds 80-90% of active devices, so your addressable market is large.
- Device Compatibility: It works on all supported iPhones. On models without the Dynamic Island, the Live Activity is a rich notification banner on the Lock Screen. On newer models, you get both the Lock Screen view and the compact, persistent view in the Dynamic Island. As of iOS 18, they also appear in the Smart Stack on Apple Watch and are supported on iPadOS.
- Creative Control: You have significant control within Apple's templates. You design three distinct views with SwiftUI: a compact view for the Dynamic Island, an expanded view (when long-pressed), and a Lock Screen view. While you control the layout and data, the overall size, shape, and corner radius are fixed by the system.
- Network Loss: If a user loses connectivity, the Live Activity simply stops receiving real-time updates. It will display the last valid data it received. You should design the UI to show a "last updated" timestamp or a "connecting" state so it doesn't look like it's frozen. The activity will end automatically when it hits the 8-hour limit or becomes stale based on a date you can set.
- User Control: Yes. A user can disable Live Activities for your app in Settings independently of your standard push notifications. This is crucial—they can opt-out of this specific feature without silencing you completely.
- Battery & Data: Yes, this is a real concern. Live Activities, like any process that keeps the CPU awake and uses the radio for frequent updates, will consume more battery than the idle state. This is why Apple limits the update frequency and why you must be efficient. It's a trade-off between user value and resource consumption.
Scenario | Typical use-case scope | Total effort (hours) |
Simple – local-only timer | In-app start/stop, no server | 40 – 64h |
Moderate – food-delivery / ride-share tracker | One activity per user, server pushes images & status | 280 – 360h |
Complex – multi-game sports board | High-freq updates, dynamic assets, multiple concurrent activities, broadcast channels | 480 – 640h |
Figures include front-end, backend, integration testing, and a 20% contingency.
- Mini-app, not a widget. Each Live Activity lives in a Widget extension plus three Dynamic-Island states—the UI matrix alone eats ~40% of the budget.
- Token juggling gets real. Every activity has its own push-to-update token (PTUT); your backend must track and target them in real time.
- Integration & QA are the black hole. The client ↔ APNs ↔ server dance routinely burns 40-80h even on “moderate” builds.
- Broadcast model ≠ free lunch. iOS 18’s channel API removes fan-out pain for one-to-many events, but you still build the same UI and state machine first.
Dev Handoff - 2: WWDC 24 video on broadcasting pushes to live activities.
Pro tip: Run a 16-hour proof-of-concept to validate APNs token flow and asset caching before committing to a launch date—nothing torpedoes a roadmap faster than a sandboxed widget that can’t find its images.
- Guidelines: Apple's Human Interface Guidelines are very clear: No ads or promotions. A Live Activity is for information and task-tracking only. Using it for marketing is a fast track to rejection. You also cannot display sensitive personal information.
- Monetization: You cannot monetize it directly. The accepted strategy is to monetize it indirectly by including Live Activities as a key feature of your premium subscription tier. For example, a sports app might offer basic alerts for free but reserve rich, play-by-play Live Activities for subscribers.
Phase | What founders / PMs should insist on | Key API / payload knobs | Why it matters |
1. Detect | App watches connectivity with NWPathMonitor and, the moment status == .unsatisfied, fires a local activity.update() marking the UI “offline.” | NWPathMonitor, Activity.update() | Users see the loss of data instantly instead of waiting for a timeout. |
2. Degrade | The same update also shortens staleDate (e.g., now + 120 s). If the app is later suspended, ActivityKit will flip the widget to its built-in .stale state and show a “Last updated…” stamp. | stale-date field in payload | Guarantees the Live Activity never freezes with ancient data. |
3. Recover / Dismiss | Server keeps sending full-state snapshots (APNs stores only one per device) and, when the event ends, ships an event:"end" push with: • dismissal-date = past timestamp → instant removal • apns-expiration long enough to survive short outages | event, dismissal-date, apns-expiration headers | Ensures the activity cleans itself up—even if the phone was offline when the event finished. |
4. Clean-up safety net | On every app launch, code loops through Activity.activities, asks the backend for ground truth, and ends any “zombie” activities it finds. | Activity.activities | Catches the rare cases where the final push was missed or expired. |
UX checklist (what the user actually sees)
- Swap to a concise “Connection lost” label + relative “Last updated · 3m ago” timestamp.
- Dim or gray out stale data; optional ⚠️ icon from SF Symbols.
- Flip back to live visuals immediately after the first successful update.
# | Action item |
1 | Throttle your pings. Default to low-priority (apns-priority 5) updates and reserve high (10) for time-critical moments; exceed the budget and iOS throttles you automatically. |
2 | Pick the right priority header (5 vs 10). The header controls delivery latency and your update budget. |
3 | Attach a relevance-score (0–1). Higher scores float your Live Activity to the top of the Lock Screen or Dynamic Island when several are active. |
4 | Set a stale-date. If the device misses pushes, iOS flips to your “stale” UI instead of showing wrong data. |
5 | Use broadcast pushes (iOS 18+). For one-to-many cases (e.g., a game score) send a single update to a channel—APNs fans it out to every subscriber. |
6 | Handle pushTokenUpdates. Each Live Activity’s push-to-update token can rotate; listen for changes and replace the old token on your server. |
7 | Design layouts per context. Craft distinct SwiftUI views for Lock Screen, Dynamic Island (compact/expanded), and StandBy—don’t recycle a notification card. |
8 | Show “last updated” or offline states. Pair stale-date with a visual cue so users know data may be out of date. |
Dev Handoff - 1: Apple's WWDC 2023 video - Update Live Activities with push notifications.
Dev Handoff - 2: Apple's WWDC 2023 video - Design dynamic Live Activities.
# | Best practice | Why it matters | How to implement (one-liner) |
1 | Keep an offline queue. | APNs stores only one pending notification per app while a device is offline—extra alerts overwrite the first one in the queue. | Maintain a small FIFO queue keyed by device-token + bundle ID and flush it when the first push is accepted. Dev Handoff |
2 | Collapse follow-ups. | Users hate “notification machine-gun” bursts, and you pay for them. | Set the same apns-collapse-id (e.g., order-123) on every update so APNs shows only the freshest payload. |
3 | Render instantly. | Notification Content Extensions get ≈200 ms; slow setups delay delivery or show blank UI. | Pre-cache assets locally—no network calls inside didReceive(_:withContentHandler:). |
4 | Template by category. | Reminders and reports shouldn’t share the same UI. | Assign a unique categoryIdentifier and ship a dedicated Content Extension for each template. |
5 | Hide default clutter. | Duplicated system text under your custom view looks sloppy. | In the extension’s Info.plist, set UNNotificationExtensionDefaultContentHidden = YES. |
6 | Test with Push Notifications Console. | Early, real-device tests catch token errors and bad layouts before App Review does. | Use Apple’s web console to send and inspect pushes to any TestFlight device. Dev Handoff |
7 | Update in place. | Order status changed? Replace, don’t stack. | Resend the push with the same apns-collapse-id (and, if relevant, the same category) to overwrite the previous card. |
8 | Treat a push as a signal, not state. | APNs may drop, reorder, or collapse messages—relying on every notification breaks the user’s view of reality. | The correct approach is to ensure the final notification in a sequence updates the app's badge corewrote the card descriptionsunt accurately, and that upon opening the app, a full, up-to-date state is fetched from the server. |
written by Konstantin Kalinin
