Crafting Seamless Journeys with Live Activities - Lyft
Article Summary
Lyft built Live Activities that update millions of users per week—but iOS sandboxing, 4KB payload limits, and image rendering nearly killed the project.
Lyft's iOS team shares how they architected server-driven Live Activities for ride tracking. Max Husar walks through lifecycle management, dynamic UI components, and creative workarounds for iOS constraints.
Key Takeaways
- Server-driven architecture enables instant updates across all app versions simultaneously
- Protobuf and image compression fit driver photos into 4KB APNs payload limits
- Stale date monitoring kills outdated activities within 3 minutes automatically
- SDUI framework with RichText, ProgressBar, and RemoteImage powers all ride states
- App Groups share cached images between extension and main app
Lyft's fully server-driven Live Activities architecture scales to millions of weekly users while handling iOS sandboxing, payload constraints, and real-time image updates.
About This Article
Live Activity widget extensions run in isolated sandboxes without network access, so AsyncImage can't load remote driver photos and car images that need to update during ride matching and rematching.
Max Husar's team used App Groups to share a file cache between the widget extension and main app. They send base64-encoded thumbnail images (72x72px, under 3KB) through APNs while the main app downloads and swaps in full-resolution versions when it's active.
Driver profile photos appeared immediately on Live Activity updates while staying under the 4KB APNs payload limit. If the total payload got too large, the system dropped image data to ensure all content updates went through.