TechPrufer
Get started
Slack
Slack logoSlack · Feature trail

Mobile Codebase Modernization

8 posts · Sep 2017 – May 2022

What this trail covers

This thread tracks the evolution of Slack's mobile codebases, focusing on modernization efforts to improve app architecture, adopt industry trends, and lay the groundwork for future innovation. Initial posts detailed the Duplo initiative's goals of stabilizing, modularizing, and modernizing iOS and Android codebases. This post details the decision to move away from a shared C++ client library (Libslack) due to integration overhead and hiring difficulties, and the subsequent development of separate platform-specific codebases. LibSlack was designed to encapsulate common business logic and data handling, aiming for a 'LibSlack sandwich' architecture with platform UI on top, LibSlack logic in the middle, and a platform layer at the bottom for native capabilities. It focused on data caching, lazy loading, and offline functionality. The choice of C++ was made for its cross-platform compiler support and modern features. Djinni was used for generating cross-language headers, though it had performance costs and limitations with JavaScript. Development and debugging involved a reference client and a move to daily CI builds with source code integration for easier debugging. Unit tests achieved ~70% coverage and were gated on PRs, with integration tests also required. Future work included on-device performance testing.

All Slack trails
  1. Scaling Slack’s Mobile Codebases: ModernizationThis post details the 'Modernization' phase of Slack's Duplo initiative for mobile codebases. On iOS, it covers adopting a VIPER-variant feature architecture, implementing stricter linting rules to prevent anti-patterns, increasing Combine adoption for reactive programming (temporarily using CombineX), and driving further adoption of the SlackKit design system. On Android, it details migrating to modern libraries like Moshi (replacing Gson), WorkManager (replacing Android Priority Job Queue), and an internal networking library called Guinness. It also discusses establishing best practices for Coroutines and experimenting with Jetpack Compose. The post concludes with Duplo initiative results, showing significant improvements in codebase modernization and modularization percentages, reduced CI build times, and improved CI build stability.
  2. Scaling Slack’s Mobile Codebases: ModularizationThis post details the 'Modularization' phase of the Duplo initiative for Slack's mobile codebases. It explains the strategy of breaking down app targets into smaller, independent modules (Features, Services, Libraries) on both iOS and Android to reduce interdependencies, decrease build times, and allow for independent development. Key benefits such as improved build times, clearer code ownership, and disentangled dependencies are discussed. On iOS, the adoption of Bazel as the build system is highlighted as crucial for modularization and performance gains, including the shift from dynamic to static library linking. The post also covers the use of code generation for creating new modules, managing CoreData models, and handling feature flags. The Android modularization strategy, including its module types and dependency injection approach with Dagger, is also outlined.
  3. Stabilize, Modularize, Modernize: Scaling Slack’s Mobile CodebasesThis post details the 'Stabilization' phase of Project Duplo, which aimed to address tech debt in Slack's mobile codebases. It describes the challenges of monolithic app targets, tangled interdependencies, global state, and long build times on both iOS and Android. It also highlights stalled migrations (e.g., Swift adoption on iOS, Kotlin/Moshi adoption on Android) and inconsistent design patterns (MVVM+C on iOS, MVP on Android). The post explains the decision to refactor in place rather than a full rewrite and outlines the three core themes of Project Duplo: Stabilization, Modularization, and Modernization.
  4. Building Android Conversation BubblesThis post details the technical implementation of Android Conversation Bubbles for DMs and Group DMs. It covers the prerequisites: using MessagingStyle, implementing Sharing Shortcuts with custom avatar generation and asynchronous updates, and employing a trampoline Activity to route shortcut intents to the correct UI (Compose, Messages, or Bubbles). A hacky but effective method for detecting Bubble launches on Android 11 using display name prefixes is described. The post also addresses challenges in ensuring the Bubble displays the correct content by disabling navigation and opening specific flows in the main app, and a bug fix for dismissing notifications when a Bubble is active. Finally, it explains how the Slack websocket infrastructure was adapted to support team switching within Bubbles.
  5. Client Consistency at Slack: Beyond LibslackThis post details the decision to discontinue the Libslack project, a shared C++ client library, due to integration overhead, build system complexities, debugging challenges, and hiring difficulties. It describes the subsequent development of separate DataProvider frameworks on iOS (Swift) and Android (Kotlin) to manage data syncing and caching, providing similar functionality to Libslack but with greater flexibility. It also introduces the Client Foundations Council for cross-client knowledge sharing and conformance suites for ensuring feature consistency.
  7. PanModal: Better support for thumb accessibility on Slack mobileThis post details the technical implementation of PanModal, a custom iOS modal transition library. It explains the use of UIKit's UIViewControllerTransitioning API, including delegates, animators, and presentation controllers, to create a draggable modal. The post highlights challenges with gesture recognition when integrating with child UIScrollView components and the solution using KVO to manage scroll offset changes. It also discusses the design goals of creating a simple, robust API that supports any UIViewController subclass and maintains 60 FPS performance.
  8. When a rewrite isn’t: rebuilding Slack on the desktopThis post details the technical approach to rewriting Slack's desktop client, moving from manual DOM updates and eager data loading to React and lazy data loading. It addresses the challenge of multiple Electron processes per workspace by introducing a multi-workspace aware architecture using Redux, where each workspace gets its own Redux store. The post also outlines the 'Ship of Theseus' incremental modernization strategy, using legacy-interop mechanisms (TS.interop and adaptFunctionWithFallback) to gradually replace old code with new, while maintaining interoperability. The success of this approach is demonstrated by significant memory usage reductions.
  9. LibSlack: The C++ Library at the Foundation of Our Client Application ArchitectureThis post details the initial development and rationale behind LibSlack, a cross-platform C++ library designed to encapsulate common business logic and data handling for Slack's client applications. It explains the 'LibSlack sandwich' architecture, the focus on data caching and offline functionality, the choice of C++ as the core language, the use of Djinni for API generation, and the strategies for development, debugging, and testing. The post highlights the benefits of code sharing for consistency and reduced development effort, while also acknowledging the challenges of cross-language integration and performance.