Kyle Sherman: Swift at Linkedin

When Apple first announced Swift, iOS developers across LinkedIn started learning it. This deck by Software Engineers Kyle Sherman and Kamilah Taylor describes LinkedIn's experience with writing 2 drastically different apps in Swift.

The SlideShare app has a much smaller user base, number of developers, and fewer features. The new LinkedIn app, Project Voyager, is a very large codebase with a large group of developers and a huge user base. This should give you the idea of what type of challenges and benefits both a startup and large company would have by switching to Swift from Objective-C.

This presentation was given at the Sillicon Valley iOS Developers' Meetup on 12/07/2015. Thanks to Tim Burks for hosting and organizing the event.

Follow Kamilah on Twitter & LinkedIn:
https://twitter.com/kamilah
https://www.linkedin.com/in/kamilahtaylor

Follow Kyle on Twitter & LinkedIn:
https://twitter.com/drumnkyle
https://www.linkedin.com/in/kyledsherman

Transcript

1. @ Kamilah Taylor (@kamilah) Kyle Sherman (@drumnkyle)
2. 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
3. Why Swift?
5. SlideShare
6. 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
7. LinkedIn Flagship App
8. LinkedIn Flagship App • Immediately started learning Swift • Tested Swift for new iOS features on current app • Today widget • Share extension
9. Project Voyager
10. 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
11. Growing Pains
12. Early Days (Betas)
13. Slow compiler SlideShare: 275 Swift files
14. Early Days (Betas) • Syntax Highlighting and Autocomplete slow • Select few classes had to be ObjC (IB support)
15. Abundant SourceKit Crashes
16. No migration tool for language changes
17. Later Days (Voyager)
18. Slow compiler (still a problem) Voyager: 2,748 Swift files
19. 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
20. Workarounds (Voyager) • Code structure • Dropped iOS 7 support • Modularized using Cocoapod's devpods • This broke debug symbols • Converted devpods into dynamic frameworks
21. 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)
22. 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
23. The Pros
24. 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
25. 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
26. 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
27. Libraries
28. SlideShare • We have not integrated any Swift libraries • Upgrading causes some problems with internal code because of our Today extension
29. 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
30. Key Takeaways for teams For large teams (and apps), modularize from the beginning
31. Key Takeaways for teams • It will be faster for you to train new devs on Swift • Less newbie ObjC errors
32. 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
33. 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
34. 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/
35. ...One More Reason Swift is now open-source!
36. So finally to the question everyone has…
37. Should I Use Swift?
38. For small teams; brand new app YES
39. For small teams; existing ObjC code YES, but…
40. 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
41. For large teams Maybe
42. 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)
43. You Decide What’s Right For You!