An alternative approach to building & shipping Swift apps

Working with 70+ iOS engineers uncovers many problems with Apple's tooling. By replacing Xcode's build system with bazel, we were able to decrease build times, stop doing clean builds on CI, and rely on remotely cached artifacts to stop developers from having to rebuild files they haven't changed.

Transcript

1. An alternative approach to building & shipping Swift apps
2. Lyft
3. → 70+ iOS engineers → 800k+ lines of Swift + 0 lines of Objective-C → 600+ "modules" → 1200+ Xcode targets → 800+ Interface Builder files
4. Xcode is hard.
5. .xcodeproj maintainability
6. yonaskolb/XcodeGen
7. Target configuration abstractions
8. Detaching what's presented with what's built
9. Building things you didn't change
10. What else?
11. Control over our build
12. Sharing tools across the teams
13. xcodebuild -> ?
14. → Compile sources with the right arguments → Package everything correctly → Do as little work as possible → Do all of that, fast
16. Build configuration
17. module( name = "Storage", deps = [ "Logger", ], ) unit_test( name = "StorageTests", deps = [ "Storage", ], )
18. Smaller Xcode projects
20. Hermetic builds
21. Never rm -rf DerivedData again
22. Remote build caching
24. Remote execution
26. So I should use bazel?
27. Control over your build
28. There are a lot of things you can do first
29. You're on your own*
30. *but we have your back
31. Bazel is great, once you need it
32. https://slack.bazel.build
33. Thanks! @SmileyKeith