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

Kyle Sherman: Swift at Linkedin

1fa9cb8c7997c8c4d3d251fb5e41f749?s=47 Realm
December 11, 2015

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

1fa9cb8c7997c8c4d3d251fb5e41f749?s=128

Realm

December 11, 2015
Tweet

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?

  4. None
  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!