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