Live Activities are getting more screen space in iOS 27. At WWDC26, Apple announced updates to Live Activities, including Dynamic Island support in both portrait and landscape modes. Apple also supports Live Activities across the Lock Screen, Apple Watch, Mac, CarPlay, and StandBy, so the feature now extends well beyond the iPhone Lock Screen.
That makes the product question more relevant: when does persistent real-time information deserve its own interface, and when does the engineering work outweigh the benefit? We spoke with Viktor Gordienko, Senior iOS Engineer at inDrive, about where Live Activities make sense for product teams and what often makes implementation harder than expected.
Apple is expanding Live Activities across more devices and presentation contexts. How do you see their role in iOS products in 2026: are they becoming a standard UX pattern or do they still make sense only for a limited set of use cases?
It’s a high-value UX pattern, but it’s not universal. Live Activities have evolved into a complex ecosystem tool with Dynamic Island, Lock Screen, watchOS and macOS support. However, not every app needs one. In practice, even apps that can technically support several Live Activities at once need to be selective. ActivityKit does limit how many activities an app can run at once, but Apple doesn’t publish the exact number. In inDrive, I got up to eight running at the same time before I stopped testing. The Lock Screen was already cluttered at three, so the practical limit is much lower than the technical one.
Live Activities deliver when an app manages an active or timed process, where users benefit from real-time status updates. Live Activities act as smooth, ambient interfaces, bringing real-time micro-interactions directly to users without making them go through multiple app screens.
Which product scenarios benefit most from Live Activities? Is there a simple way for a team to decide whether users need them?
Ans:
Live Activities are most useful when users need to keep an eye on something without staying inside the app. These use cases fit session-based workflows because the system needs to keep track of what is happening during an active session. This includes driver arrival in inDrive or delivery tracking and sports scores, as well as tools such as timers and live audio processing. I also experimented with a Live Activity for real-time audio analysis in my own BPM Analyzer app, mainly to see where the technical limits of the format are.
There are also less obvious cases. BeReal, for example, uses a running timer for its two-minute posting window, while apps such as Perplexity can show the status of an ongoing task. Overall, we could narrow it down to a simple set of questions:
- Is the user session stateful, time-based?
- Do users open the app repeatedly just to check something?
- Can the core functionality of that check be summarized in a compact dynamic state?
Where is the line between a useful real-time interface and additional visual noise? What mistakes tend to cause notification fatigue?
For me, the line is whether the user needs that information right now. Live Activities make sense when they save someone from reopening the app just to check a status, such as where their driver is or when an order will arrive. They become noise when apps use the Lock Screen or Dynamic Island for promotions or updates that are not time-sensitive.
I’ve seen the same problem when several Live Activities run at once. In testing, even three widgets on the screen already felt crowded, which defeats the point if Live Activities simply replace notification clutter with widget clutter. There are smaller design mistakes too. For example, Apple recommends that Live Activities should not imitate regular notification layouts, including by relying on the app icon in the same way.
The same applies to notifications. If an app keeps sending unimportant alerts, people start ignoring them or turn them off altogether.
How much more complex is a Live Activities implementation compared with standard push notifications or home screen widgets? What do teams usually underestimate around ActivityKit, server-side updates, and lifecycle management?
Live Activities are noticeably more complex than standard push notifications or Home Screen widgets because they require several systems to stay in sync throughout an active session. Unlike timeline-based Home Screen widgets, Live Activities are driven by real-time app and push updates. This adds a few implementation challenges.
Engineers need to manage the push token lifecycle, including token generation and rotation, and build the server-side APNs flow to create, update, and end a Live Activity on the Lock Screen or Dynamic Island. They also need to keep local and remote states in sync, especially when background events and push notifications arrive at nearly the same time.
Lifecycle limits matter too: a Live Activity can stay active for up to 8 hours. After that, the system ends it, and it can remain on the Lock Screen for up to 4 more hours. Longer flows, like city-to-city rides or scheduled deliveries, need a plan for that cutoff. Updates should stay lightweight as well. The ActivityKit payload is capped at just 4 KB. Apps that genuinely need frequent updates can opt in with NSSupportsLiveActivitiesFrequentUpdates, but that still affects battery use.
There are UI limitations, too. For example, animations inside widgets and Live Activities are limited to two seconds, so an animation that works smoothly inside the app may need to be redesigned for the Live Activity.
Which metrics would you use to evaluate whether Live Activities justify the development and maintenance cost?
I would look at whether Live Activities improve the user journey enough to justify the development and maintenance cost. One useful signal is whether users can complete common tasks with fewer app opens. For example, if someone can track an order directly from the Lock Screen, a lower open rate may be a positive outcome rather than a sign of lower engagement. I would also track downstream actions, such as order completion or post-order reviews, to see whether Live Activities help users move through a specific flow.
Teams can also look at whether the Live Activity drives the intended action at the end of a session. Some ride-hailing and delivery apps, for example, use the final state to ask for a review, which makes review completion a measurable downstream metric.
Another important area is user behavior around the Live Activity itself. Dismissal and opt-out rates can show whether users find it useful or intrusive. If people regularly swipe it away or disable Live Activities in iOS settings, that suggests the feature isn’t providing enough value to justify the ongoing engineering cost.
As Apple brings Live Activities into more parts of its ecosystem, should teams design them with iPhone, Apple Watch, Mac, and CarPlay in mind from the start, or does that only make sense for certain products?
It all comes down to whether the app’s specific flow justifies the work of developing for the wider ecosystem. Designing for every Apple device might create unnecessary architectural complexity. The surfaces are not identical either. Live Activities from an iPhone can appear in StandBy, the Apple Watch Smart Stack, CarPlay, and the macOS menu bar, but the same presentation won’t work equally well everywhere. The Dynamic Island in iOS 27 landscape, for example, has less width to work with than in portrait. I would recommend separating the UI and state layers, focusing initial design and testing on the iPhone Lock Screen and Dynamic Island, then expanding gradually to watchOS, macOS, CarPlay, etc.
If a product team is considering Live Activities for its roadmap, what is the first question it should answer before development begins?
The first question should be: “Do users regularly leave the app while waiting for something, then reopen it just to check the latest status?”
If the answer is yes, Live Activities may solve a clear product problem. They work especially well when users want quick updates such as “Where is my driver?” or “When will my food arrive?” In those cases, the feature can reduce unnecessary app opens while making the waiting experience less frustrating. If the main goal is simply to keep the brand visible on the Lock Screen, the development and maintenance cost may be harder to justify.
Featured image credit
