Background processing: An unexpectedly long journey
summary
Builds an iOS background fetch system that pre-fetches data and fires notifications and proves it raises engagement — sessions per user increase about 9% and article downloads rise — but testing takes three to five times longer than typical. Key gotchas: background fetch scheduling is unreliable, trimming RAM and calling the completion handler quickly matter, NSUserDefaults unavailable in background and files/keychain need specific attributes, and analytics can be skewed by background runs (observed >10x differences).
AI-written summary · about
chapters (23)
- 0:00Introduction
- 4:52Why not push notifications
- 5:50How did it go
- 6:32The testing phase
- 6:51Why it took so long
- 8:27Platform differences
- 10:21iOS 9 support
- 10:58Background processing scheduling
- 11:23Background processing in foreground
- 11:39Memory
- 12:45Completion handler
- 13:46Use background tests
- 15:27Dont trip over yourself
- 16:07Beware of Xcode
- 17:57Apple Developer Forums
- 19:56In the background
- 21:45NS user defaults
- 23:32Usage tracking
- 26:40Test it out
- 27:06What we learned
- 29:03Beacons
- 29:33Metrics
- 30:55Major lessons
related talks
51mQ&A Session
36mHidden engineering challenges of A/B Testing
33mFirebase iOS Deep Dive
37mMobile Testing: Pinpointing Invisible Problems
37mMulti-threaded Rendering on Android (with Litho & Infer)
31mBuilding Consistently Fast Flutter Apps
32mZero to Test, How to Run Your First Beta Testing Program
37miOS Parallel Automation: Run Faster Than Fast