Date post: | 14-Apr-2017 |
Category: |
Software |
Upload: | kyle-sherman |
View: | 3,127 times |
Download: | 0 times |
@Kamilah Taylor (@kamilah)
Kyle Sherman (@drumnkyle)
2 Perspectives
• Kyle represents SlideShare app
• 4 devs, ~3 months for v1
• Kamilah represents Voyager
• Recently released LinkedIn app rewrite
• ~50 devs, ~1 year for v1
Why Swift?
SlideShare
SlideShare• Timing was right; had just started development
• Interoperability with ObjC
• Most of team coming from Ruby
• Safety Features
https://engineering.linkedin.com/ios/our-swift-experience-slideshare
LinkedIn Flagship App
LinkedIn Flagship App
• Immediately started learning Swift
• Tested Swift for new iOS features on current app
• Today widget
• Share extension
Project Voyager
Project Voyager
• Engineering discussions for app just started
• Another complete rewrite wouldn’t happen soon
• Concerned with potential pain of switching to Swift later
• Engineers were excited about language features of Swift like optionals
Growing Pains
Early Days (Betas)
Slow compilerSlideShare: 275 Swift files
Early Days (Betas)
• Syntax Highlighting and Autocomplete slow
• Select few classes had to be ObjC (IB support)
Abundant SourceKit Crashes
No migration tool for language changes
Later Days (Voyager)
Slow compiler (still a problem)Voyager: 2,748 Swift files
Xcode
• Compile times very very very long for large codebase (~25 min on 15” rMBP)
• Migration tool crashed on large codebase
• App binary size was large and load time had increased
Workarounds (Voyager)
• Code structure
• Dropped iOS 7 support
• Modularized using Cocoapod's devpods
• This broke debug symbols
• Converted devpods into dynamic frameworks
Workarounds (Voyager)• Lengthy, manual migration to new Swift version
• Xcode 7.0 decreased build times dramatically (+26% speed boost)
• Switched generated models to ObjC (to reduce the number of Swift files)
• Mac Pros for everyone! (12 cores gave us a 2x speed boost over the top of the line MBP)
Workarounds (Voyager)
• Xcode 7 reduced app binary size by 15%
• Increased cold launch time in iOS 9 due to Apple bug that lead to increase in time to load libraries (especially enterprise builds)
• Converted some dynamic libraries to static
The Pros
SlideShare
• Syntax way cleaner and easy for newcomers
• Optionals, initialization rules, static typing, etc. much safer
• Less crashes by using optionals and asserting instead of crashing
Voyager• Whole classes of bugs disappeared (i.e. NPE)...as
long as you never force unwrap optionals!
• Caveat - ObjC libraries that have not been annotated for Swift
Voyager• Swift lint
• Easier to onboard devs from web or Java
• Especially noticeable with how fast it was for interns to learn Swift
• Community is very active and helpful
• Functional programming
Libraries
SlideShare
• We have not integrated any Swift libraries
• Upgrading causes some problems with internal code because of our Today extension
Voyager
• Most internal libraries are still written in ObjC
• We have some internal and external libraries, written in Swift, integrated
• Cocoapods is how we do all dependency management
Key Takeaways for teamsFor large teams (and apps), modularize from the
beginning
Key Takeaways for teams
• It will be faster for you to train new devs on Swift
• Less newbie ObjC errors
Key Takeaways for teams
• ObjC is still a valid option and will have less issues
• There are still Swift bugs that will cause crashes in your app
• You won't spend time on workarounds for the language and the tools with ObjC
Key Takeaways for teams
• Managing Xcode version still a pain
• For example, bugs in iOS 8.1, Xcode 6.1, Swift 1.2, etc
• It took months to upgrade to Xcode 7.2
Great Time to Start!
• Xcode 7 and Swift 2 are much more stable
• Build times are significantly improved
https://github.com/SlideShareInc/swift-style-guide/
...One More Reason
Swift is now open-source!
So finally to the question everyone has…
Should I Use Swift?
For small teams; brand new app
YES
For small teams; existing ObjC code
YES, but…
If You Have an ObjC App
• Code new features in Swift; get familiar with it
• Go back and refactor ObjC where you would see a benefit
• Don’t recommend rewriting entire app unless planning a rewrite for other reasons
For large teams
Maybe
Considerations for Swift
• Less time spent on-boarding new developers (much less than ObjC)
• Fewer mistakes made and bugs created (much fewer)
• More workarounds needed for tooling and code (considerable issue for large teams)
You Decide What’s Right For You!