# Scaling iOS at Bumble: Part 2/3 -- The Assessment

DevFeed: [Scaling iOS at Bumble: Part 2/3 -- The Assessment](<https://devfeed.tech/articles/scaling-ios-at-bumble-part-2-3-the-assessment-22603.md>)

Original publisher: [Read original article](<https://medium.com/bumble-tech/scaling-ios-at-bumble-239e0fa009f2?source=rss----6353b5325b1a---4>)

Author: Jonathan Crooke

Published: 2024-02-15T13:49:17Z

Content type: article

Language: en

Sources: [Bumble Tech](<https://devfeed.tech/sources/bumble-tech.md>)

Topics: [iOS](<https://devfeed.tech/topics/ios.md>), [Tuist](<https://devfeed.tech/topics/tuist.md>), [swift-package-manager](<https://devfeed.tech/topics/swift-package-manager.md>), [bazel](<https://devfeed.tech/topics/bazel.md>), [toolchain](<https://devfeed.tech/topics/toolchain.md>), [Xcode](<https://devfeed.tech/topics/xcode.md>), [Requirements](<https://devfeed.tech/topics/requirements.md>), [Testing](<https://devfeed.tech/topics/testing.md>)

Tags: [bazel](<https://devfeed.tech/tags/bazel.md>), [ios](<https://devfeed.tech/tags/ios.md>), [ios-app-development](<https://devfeed.tech/tags/ios-app-development.md>), [performance](<https://devfeed.tech/tags/performance.md>), [requirements](<https://devfeed.tech/tags/requirements.md>), [swift](<https://devfeed.tech/tags/swift.md>), [swift-package-manager](<https://devfeed.tech/tags/swift-package-manager.md>), [testing](<https://devfeed.tech/tags/testing.md>), [toolchain](<https://devfeed.tech/tags/toolchain.md>), [tuist](<https://devfeed.tech/tags/tuist.md>), [xcode](<https://devfeed.tech/tags/xcode.md>)

## AI overview

This article recaps Bumble's assessment process for replacing parts of its iOS project and build toolchain. It describes onboarding, proof-of-concept work, full-app conversion, and assessment criteria for Swift Package Manager, Tuist, and Bazel, including blockers, user experience, and performance.

## Source excerpt

Scaling iOS at Bumble: Part 2/3 -- The AssessmentRecap In our previous post we discussed how we came to be investigating project and build toolchain replacement solutions for our iOS codebase at Bumble Inc. We began executing proofs of concept for Swift Package Manager (SPM), Tuist and Bazel. The Process Our investigative process for each tool was performed in roughly the same manner: 1. Onboarding With the exception of some light use of SPM as a third-party dependency manager, no-one on the team was fully fluent with any of the tools. This meant that at first, we needed to learn the basics, which could be achieved by creating a minimum-viable manifest for one of our node modules. This would involve learning the manifest format and core commands for building, testing etc. 2. Medium-sized proof of concept Following on from the initial onboarding, we would then progress to converting parent modules, traversing the tree post-order. At each level we'd cover more of our core requirements and encounter edge-cases. Throughout, we noted learnings, limitations and fixes. 3. Full-app conversion At this stage, since our module tree exhibits a strong level of uniformity, we'd now have gathered enough experience to fully convert the app's child modules, and do so using automated tooling. How we achieved this will be discussed below. Unsurprisingly, the top-level app target was its own challenge, and required considerably handcrafting. We only aimed to achieve a minimum-viable conversion at this stage, and didn't expect tests to pass. That said, we'd usually have a fairly conformant conversion anyway, that would launch successfully to its home screen and usually plenty more. 4. Assessment With a converted app target in hand, we would now have a candidate for assessment. But what did we want to know? Our analysis looked at these areas: Blockers: simple enough, any limitations or issues in the tool's functionality whereby it was unable to serve our basic requirements Subjective user