Mobile App Development: Catching Crashers
Article Summary
Twitter's iOS team shipped beta builds to employees and discovered crashes that would never show up in testing. The culprit? Jailbroken devices and unprefixed Objective-C categories.
Ben Sandofsky, Tech Lead for Twitter's iOS team, breaks down how they used Crashlytics to catch and fix crashes before production. This 2013 post remains a masterclass in mobile debugging methodology.
Key Takeaways
- Jailbroken devices added unprefixed categories that collided with Twitter's own code
- SQLite multithreading required three rewrites: GCD queues to native threads to disabled shared cache
- Employee dogfooding with crash reports dramatically shortened the feedback cycle
- Category prefixing prevents future collisions when iOS adds methods to existing classes
Detailed crash data from pre-production builds helped Twitter eliminate entire classes of bugs before users ever saw them.
About This Article
Twitter's iOS team hit database lock errors in production after switching from NSKeyedArchiver to SQLite. They learned that SQLite's write locks work globally across the entire database, not just at the table level. This caused crashes when multiple parts of the app tried to access the database at the same time.
Ben Sandofsky's team rebuilt their SQLite framework multiple times to fix the issue. First they tried using separate GCD queues for reads and writes. That didn't work, so they switched to native threads instead of GCD to keep database connections on the same thread. Finally, they disabled SQLite's Shared Cache feature.
After switching to native threads and disabling Shared Cache, the crash graph dropped significantly. The database schema lock errors that had persisted through their earlier attempts finally went away. The team could then ship a more stable version to users.