iOS @ Over: Starting a Platform Team
The challenge that all scaling teams face is in dealing with the growing pile of technical debt and performance problems. With a few people in a team, it is easier to coordinate on refactoring and knowledge sharing. With a larger team, collaboration and communication become increasingly complex. Once those teams start moving faster, it becomes even harder to slow down and deal with that growing pile of tech debt.
In this post, we will explain what happened within our team at Over and what led to the creation of the iOS Platform Team 🚀
🏚 The cracks of a scaling team
As our team scaled, so too did our codebase. We develop primarily in Swift and this has a massive impact on our overall build times (hopefully this improves this WWDC 🤞). It would take around 20 minutes for our build server on Buddybuild to build and run all our tests for a Pull Request. A clean build of Over can take up to 3 whole minutes. These times add up each day and it makes things worse when we started noticing how we would switch to Slack, or surf the web while we waited. All that context switching while waiting for builds really hurt our productivity.
Another pain point we experienced was a growing pile of technical debt. One such example is when we replaced our Circles feature with Teams. This was quite a large refactor that was also implemented as a feature flag. This meant that both Circles and Teams were coexisting. Once we finally shipped, the team continued moving on to support Teams and couldn’t really justify the time it would take to delete the old code. After all, shipping meaningful features to our users is our top priority.
The above issues are just the tip of the proverbial iceberg ❄️. Once we took a step back, it was evident that we have a need for a dedicated team that is free from product work and can focus on helping our iOS team be more successful. We identified an individual on our team, Jamie Raad, that was willing to dive into creating the Platform Team and defining the workload and prioritisation effort. Let’s see how that went down… 😃
✍️ Defining our platform team
The platform team exists to ensure the continued success of user-facing feature teams. As the platform team is not tied to feature work and product deadlines, it is free to focus on broader challenges that inhibit the team from either shipping more smoothly or working productively.
Here was a list of tasks we prioritized as a team that we should start with:
- Improve build times (locally and on Buddybuild).
- Investigate new crash reporting tools.
- Remove Realm from the App.
- Ad-hoc requests from various departments.
The platform team is also responsible for listening to the technical needs of the team and working on new and improved APIs to assist with software delivery. Having a dedicated team also means we have the resources to investigate things such as obscure bugs that are hard to reproduce, image preloading mechanisms and approaches to reusable generic feeds. These are just a few off-the-cuff examples of areas in which the platform team can improve the way we work.
👀 The first set of results
With the platform team set up and ready to go we embarked on our first challenge: Build times. The goal here was to try and determine which of our frameworks took the longest to build so we can figure out exactly where to optimize. Ultimately, being able to reduce build times by at least 50% would be a huge accomplishment.
To get the results we followed these guidelines of passing different diagnostic options into the compiler. We passed in -driver-time-compilation & -Xfrontend -debug-time-compilation. More about them here.
xcodebuild -destination 'platform=iOS Simulator,name=iPhone 8' \-sdk iphonesimulator -workspace Over.xcworkspace \-scheme Over -configuration Debug \clean build \OTHER_SWIFT_FLAGS="-driver-time-compilation \-Xfrontend -debug-time-compilation" | \tee profile.log
We decided not to use debug-time-function-bodies since we’re just looking for overall build times, not the time per function. We then wrote 2 scripts to process the output of each option and this finally gave us an indication of our build times.
Script Results
Our script read through the build logs and calculated the total time of all Swift files inside each CocoaPod and we ignored files in Over. Below is just a short list of the top offenders
RealmSwiftExecution Time: 13.662400000000002Wall Time: 38.39059999999999UnboxExecution Time: 12.765Wall Time: 30.538700000000006AlamofireExecution Time: 9.7638Wall Time: 26.3308FacebookCoreExecution Time: 8.8349Wall Time: 24.321099999999994AlamofireImageExecution Time: 3.0501Wall Time: 10.8478FacebookLoginExecution Time: 1.3653999999999997Wall Time: 5.8422KeychainAccessExecution Time: 1.2674Wall Time: 1.9256OverLoggingExecution Time: 0.5084Wall Time: 1.1639CocoaLumberjackExecution Time: 0.3282Wall Time: 0.4215
Armed with this knowledge we knew what we had to do first. After identifying Realm as the slowest building 3rd Party framework we wanted to test the impact of manually adding and configuring it without using CocoaPods. Thankfully, Realm supplies a pre-built binary that you can manually add to your project. The advantage of a pre-built framework is that Xcode will not compile it when building the project. This speeds up the build process versus CocoaPods, which builds and compiles our frameworks every time we do a build after a clean or delete of derived data. This one change had a massive impact on our build times. We saw a reduction of roughly 100 seconds! 🎉
One disadvantage is that several steps are involved when adding frameworks manually. What helps is that Realm supplies a ready-to-go compiled Framework, not all libraries do that and for those cases, we would have to compile them ourselves.
Since this was a cumbersome process, if this continued, Carthage would be a good alternative dependency manager. The advantage being that it will compile the frameworks for us, as well as provide 1 script to strip the architectures from all frameworks.
Nevertheless, the above exercise demonstrated the importance in inspecting our build times and that there are tangible ways to improve them. Our goal was to reduce build times by 50%, which we did 😬. This is good enough for now and we have some really interesting opportunities for reduction in future.
🚀 What’s Next?
The platform team will continue to experiment with build times among many other things on our backlog. We honestly can’t wait to see what we achieve with this new team. From big things like investigating new architectures to small bugs that we have struggled to fix (looking at you iCloud ⛅️).
One really exciting avenue to explore is the potential of such a team to incubate new talent. Since they are free from feature work it could be a great place for a junior developer to join and focus on exploring the codebase and picking up issues that do not have hard deadlines.
Want to hear more? Be sure to follow us on Medium and Twitter @EngineeringOver
