# Bumble chooses Tuist for iOS project scaling after comparing SPM and Bazel

DevFeed: [Bumble chooses Tuist for iOS project scaling after comparing SPM and Bazel](<https://devfeed.tech/articles/scaling-ios-at-bumble-part-3-3-results-and-developer-quality-of-life-22604.md>)

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

Author: Jonathan Crooke

Published: 2024-03-12T15:23:14Z

Content type: comparison

Language: en

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

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

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

## AI overview

In the final part of Bumble's build and project-management overhaul, the team explains why it chose Tuist over Swift Package Manager and Bazel for its iOS project-scaling needs. It found SPM's Xcode integration too slow at its scale and considered Bazel powerful but costly to adopt and maintain.

## Source excerpt

Scaling iOS at Bumble: Part 3/3 -- Results and Developer Quality of LifeRecap This is the third and final post in a series on our 2022 & 23 build and project management overhaul. We investigated whether one (or none!) of Swift Package Manager (SPM), Tuist or Bazel would be the tool to overcome our project scaling challenges. In the first post we explained the state-of-play coming into this project. In the second we discussed the results of our proofs of concept. In this post we will explain our conclusions, and talk about the migration project itself. The decisionWe chose Tuist It shouldn't be much surprise that we didn't choose SPM. In fact, we found it to be entirely unsuitable for our use case. This isn't to say that SPM is a poor tool in general -- far from it. Initially we would have preferred to adopt it, however we couldn't ignore the fact that, at least regarding its Xcode-integration, SPM exhibits unacceptably poor performance for our use case, and at our current scale; and this is before we consider our expected future scaling! For those starting new, or smaller projects, SPM seems to provide a nice user experience. However, it also deserves to be regarded as a "first-party CocoaPods". It serves a very similar use-case, and may lead to similar performance drawbacks. Bazel was a different matter. It is undoubtedly a powerful tool, but is a high-investment choice; compared to both SPM and Tuist it diverges much from the traditional iOS development experience, increasing disruption for developers. Also, since Bazel experience is still quite uncommon, this adds extra onboarding load for new team members. We also need to support and maintain infrastructure internally; we have small infrastructure teams and Bazel presents concerns about poor bus factor for a tool that is a single point of failure. During our proof of concept it became clear that in spite of its power, Bazel would be costly for us in the short term. In comparison, Tuist hit a sweet spot between the