How Slack modernized its mobile apps and became fully Swift on iOS
Slack has managed to update its iOS and Android apps and embrace new design trends. Among other things, this enabled a full switch to Swift for iOS.
When Slack engineers decided to revamp their iOS and Android apps, they had to deal with the reality of two years-old codebases that had grown organically and had accrued significant technology debt in the past. over time. After discarding the idea of a complete rewrite as well as code reuse across multiple platforms, they settled on a complete refactoring.
Choosing this option meant that we had to deal with our existing technology debt – we had to migrate our old code and reorganize the applications in place, while keeping the application shippable and continuing to develop new features.
To accomplish their result, the team devised three different goals: stabilize their codebase to get rid of technology debt; modularize applications into separate components; modernize their design and technology stack commitments.
Stabilization was the first enabling step. On iOS, this included rewriting in Swift the remaining parts of the app that were still written in Objective-C. According to Slack engineers, the coexistence of Swift and Objective-C code in the same project slowed compilation and impacted performance, but most importantly hindered the adoption of new Swift language features due to requirements. interoperability.
Additionally, they had to rewrite code that accessed Core Data directly and make it use their own Core Data-based persistent framework, which improved performance and stability. Likewise, all network operations have been rewritten to use an internal connectivity framework.
On Android, most work has focused on splitting a few monoliths used for networking and database access, in the latter case adopting SQLDelight and migrating all existing SQLite queries to use it. Additionally, the Slack team adopted the repository pattern, which made it easier to support smarter caching and improved performance.
A key factor in the stabilization phase was tracking progress with clear metrics associated with each of the goals described above. For example, to track the Objective-C to Swift migration, the team used a script to count the number of remaining Objective-C files, while counting deprecated class and method names was useful for the rest of the objectives. .
The modularization, as mentioned, was to cut out a number of components from the two existing monoliths. This effort reduced interdependencies and build times, which had increased with the codebase, but more importantly allowed separate teams to work more independently.
Slack engineers have provided far more information and details about the stabilization phase of their project than can be summarized here, so be sure to check out the original post for the full picture.
