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

CocoaHeads SKG #10 - Migrating to Swift

CocoaHeads SKG #10 - Migrating to Swift

By @attheodo

CocoaHeadsSKG

January 02, 2017
Tweet

More Decks by CocoaHeadsSKG

Other Decks in Technology

Transcript

  1. Main Perspectives Engineering Developers who don't feel ready to migrate

    Engineering Management Managers who see many risks in migrating
  2. Where are we with Obj-C? Not exactly what we want...

    ...but keeps doing the job for years and years
  3. Where are we with Obj-C? Developed in the early 1980s

    A strict superset of C in order to allow OOP Deep roots in C Modernisation too difficult Complex build system Apple adopts it as an ecosystem language in 1996 APIs, frameworks and design patterns have been battle tested for decades Not going away at least for another 10 years...
  4. So, why Swift? Released in 2014 by Apple for the

    Apple ecosystem (but not only) Open source Swift in the server Only one guy has > 4 years experience No, we can't hire him Chris Lattner = LLVM ❤ Modern, fast, safe Patterns and best-practices still being molded Breaking changes Everyone said "wait for Swift 3.0". Well, we're there.
  5. What are the differences? 5 Pillars New features Value types

    on steroids Multi-paradigm Tooling Safer Language features prevent errors & crashes Velocity Less files, less code, faster compile times Cleaner syntax The faster your understand, the faster you write C/C++ interop is a little clunky
  6. What are the differences? New features "Everything we can do

    with reference types we can now do with enums, structs and tuples (value types)" Mutable data structures are risky in multithreaded environments In fact Swift stdlib uses 95 value types and 4 reference types Enums are now building blocks Tuples can lead to more verbose APIs without making them complex (i.e arity, return types) None of this can co-exist with ObjC though. Only in newly developed features.
  7. What are the differences? New features "Swift is the first

    protocol-oriented language" Composition VS Inheritance
  8. What are the differences? Tooling Header files C infrastructure has

    complex building phases: Committed dependencies git submodules CocoaPods/Carthage Swift Package Manager
  9. What are the differences? Velocity Time Less files in VCS

    Less code to write Less code to commit Less code to review Less code to maintain Faster compile times ⏰
  10. What are the differences? Velocity Time “On the old version,

    that was a project that took more than a month, with multiple engineers. And with Swift, that was a project that took a week for one engineer.” https://goo.gl/akMIjy Well, ok obviously. They had a clearer set of requirements at that point.
  11. What are the differences? Cleaner syntax return [ [ [

    [self.title lowercaseString] stringByReplacingOccurrencesOfString:@"visit" withString:@""] capitalizedString ] stringByTrimmingCharactersInSet: [NSCharacterSet whitespaceAndNewlineCharacterSet] ]; return str.lowercased() .replacingOccurrences(of: "visit", with: "") .capitalized .trimmingCharacters(in: CharacterSet.whitespacesAndNewlines)
  12. WHY DO WE WANT SWIFT? Why write more clean and

    predictable code? ✅ Because we want to ship less bugs Why use latest practices? ✅ Because we want to attract the best future colleagues ✅ Because we want to take part in shaping them Why make development more enjoyable and faster? Product wants faster releases... Engineering wants an enjoyable environment... Let's converge . .
  13. Management Reasons for switching TOMORROW Junior people are unlikely they'll

    start with ObjC Swift is the cool kid in the block, people are enthusiastic about it. Swift ObjC
  14. Management Reasons for switching ACME Ltd can attract brand exposure

    by taking part in the shaping of the ecosystem
  15. Management Risks An organisation's most feared word: CHANGE Migrating to

    Swift is a strategic change All BUs need to be aware & aligned with this strategy Engineering still needs to keep aligned with the overall strategy though... Easier said than done Change always starts with lots of friction ​Needs cross-functional planning & coordination
  16. Management Risks Difficult to justify ROI at early stages Most

    things will be transparent to end users at first... Development might feel slower at first... However down the road: Development will have more velocity and stability More, and more stable, features Happy users! Relevant teams (QA, support) will get relieved Healthier and less stressful synergy between Product and Engineering
  17. SWOT Analysis STRENGTHS Better long term support Healthier Engineering, QA,

    Support sunergy Faster & more stable releases Bleeding edge tech stack Great side-by-side interop with ObjC (set our own pace) WEAKNESSES Possible slowdown in early weeks (coordination costs) Real benefits of the language will shine at full migration Probability to spent a few days migrating when v4.0 comes out Throw out some of our current code
  18. SWOT Analysis OPPORTUNITIES Attract better developers now and in the

    future Expose brand by more actively taking part in the ecosystem Embrace the change with a new, clean, testable & scalable architecture Pay off accumulated technical debt THREATS Cosmic event that causes Apple to really mess Swift/ObjC interop Swift ABI roadmap is a lie It just not works™
  19. Suggested Roadmap Discuss new architecture (1 day) Finish web/iOS parity

    in ObjC ✍ ✍ Create a styleguide, document API (~2-3 days) Clean up zombie-code (1-2 days) ✌ ✌ Rewrite data layer in Swift (~1-2 weeks) ​The foundation of views & business logic Flexible architecture + tests Adjust presentation layer to use the new architecture (1 week)​ Every new file gets written in Swift When there's slack time, rewrite existing VCs in Swift
  20. Suggested Roadmap Bottom line it will take a total of

    1 month to truly start harvesting what we seow. After all, it's still good ol' Cocoa framework we're dealing with.