Upgrade to Pro — share decks privately, control downloads, hide ads and more …

An alternative approach to building & shipping Swift apps

6ab7ae85b84ebb323fab427b11500742?s=47 Keith Smiley
November 29, 2019

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.

6ab7ae85b84ebb323fab427b11500742?s=128

Keith Smiley

November 29, 2019
Tweet

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
  15. None
  16. Build configuration

  17. module( name = "Storage", deps = [ "Logger", ], )

    unit_test( name = "StorageTests", deps = [ "Storage", ], )
  18. Smaller Xcode projects

  19. None
  20. Hermetic builds

  21. Never rm -rf DerivedData again

  22. Remote build caching

  23. None
  24. Remote execution

  25. None
  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