![]() While they were developed separately on iOS and Android (written in Swift and Kotlin, respectively), these frameworks provide similar benefits and functionality. To handle the responsibility of syncing data for the application, both of the mobile infrastructure teams developed DataProvider frameworks, which ensure that all the data needed by the app is present and up-to-date. Most of the engineers from Libslack joined these infrastructure teams. In addition to the feature teams, we added an infrastructure team for each mobile client, which was responsible for supporting data syncing and caching, among other things, and could take over the work done by Libslack. By the time we stopped Libslack development, the mobile client teams had been split into pillars, where mobile engineers worked with frontend and backend engineers on specific feature areas. When the Libslack project started, iOS and Android engineers were organized into two large teams, each working on the entire app. In the end, Slack decided the overhead of developing the library outweighed the benefits, and we sunsetted the project, moving back to implementing Libslack’s functionality separately in each client application. Also, as mentioned in Dropbox’s post, hiring engineers with C++ experience, particularly on mobile, is difficult, which would have made it difficult to grow and sustain the project. Most mobile engineers at Slack were not familiar enough with C++ and the processes for building and debugging Libslack to help fix issues in the library. Coordinating quality engineering for the library was difficult, as was determining when and what to hotfix. (While we were developing Libslack, our mobile clients shipped on different schedules they now share release cycles and ship on the same dates). To further complicate matters, there was overhead to integrate the library into the build system for each client, to ensure debugging worked properly across language boundaries, and to sync up Libslack with releases for each of the clients. Slack added Libslack when its mobile apps were already mature, so it was replacing existing functionality, and it had to fit into two different established architectures. Many companies successfully using shared libraries architected their mobile clients with one in mind. This brought the number of clients sharing Libslack down to only iOS and Android, which reduced the benefit. Due to conflicting caching strategies and difficulty integrating into the build system, the desktop client never adopted Libslack, and the WinPhone client was discontinued entirely. When the Libslack project began, the initial plan was for it to be used by the desktop, iOS, Android, and Windows Phone clients. However, there are also downsides to this approach. As described in our previous post about Libslack, there were certainly benefits to sharing code between client applications - a shared library increases consistency of behavior and prevents duplication of similar business logic in every Slack client. Many of the drawbacks Dropbox experienced with their shared library rang true for Slack as well. We will talk about some of the techniques we used to achieve that. While we are no longer building a shared library, Slack still needs to maintain consistency and reduce duplication of effort, while developing separate implementations of client infrastructure. In this post, we’ll discuss the reasons why we decided to discontinue the Libslack project, and what we are doing in place of it. We were spurred to write an update when Dropbox published this post about why they also decided to stop using a C++ library in their mobile apps. ![]() In the intervening time, we decided to move away from using a shared C++ library in our clients, but we haven’t discussed that decision publicly. That post described how Slack used the Libslack library in its mobile applications to encapsulate shared business logic, and to handle syncing and caching of data. Two years ago, I wrote a post about Libslack, Slack’s shared C++ client library.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |