@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!