Real World Swift
Article Summary
Duolingo shipped their first Swift app in 2015 and achieved a 0.2% crash rate. Here's what they learned building a high-stakes testing app where crashes cost users real money.
When Duolingo launched their Test Center iOS app in Swift (just months after Swift's release), stability was critical since users pay for 20-minute language certification exams. The team documented their experience moving from Objective-C to Swift for a production app with significant user volume.
Key Takeaways
- Achieved 0.2% crash rate with Swift, most crashes from Objective-C libraries
- No exception handling in Swift prevented entire class of bugs
- Result<T> and Optional<T> types caught errors at compile time, not production
- Xcode tooling was unstable: slow completion, frequent crashes, weak debugger
- 14-second iteration time vs 2-3 seconds in Objective-C for same changes
Swift's type system and functional features enabled building a stable production app (0.2% crash rate), but immature tooling significantly slowed development velocity.
About This Article
Duolingo was building a production app for paid language certification tests that lasted 20 minutes. If the app crashed during a test, users would have a bad experience and might demand refunds. The team needed the app to be rock solid from the start.
The team used Swift's Optional<T> and Result<T> types to handle failures at the type level. This forced them to deal with edge cases when they compiled the code, rather than hitting runtime exceptions like they did with their old Objective-C code.
Swift's functional programming patterns and static type system helped Duolingo catch entire categories of bugs before release. Of the top 5 crash groups, only 4 came from legacy Objective-C library dependencies. The rest came from Swift code itself.
