CocoaHeads SKG #10 - Migrating to Swift

By @attheodo

Transcript

1. Moving from Obj-C to
   @attheodo http://attheo.do
   

   View Slide

2. Main Perspectives
   Engineering
   Developers who don't feel ready to migrate
   Engineering Management
   Managers who see many risks in migrating
   

   View Slide

3. Where are we with Obj-C?
   Not exactly what we want...
   ...but keeps doing the job for years and years
   

   View Slide

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

   View Slide

5. So, why Swift?
   Exactly what you need!
   ...but some maintenance may prove costly
   

   View Slide

6. 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.
   

   View Slide

7. 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
   

   View Slide

8. 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.
   

   View Slide

9. What are the differences? New features
   "Swift is the first protocol-oriented language"
   Composition VS Inheritance
   
   

   View Slide

10. What are the differences? New features
    "Functions are first-class citizens"
    Functional Programming
    ⚡⚡⚡
    PLUS
    

    View Slide

11. What are the differences? Tooling
    Header files
    C infrastructure has complex building phases:
    Committed dependencies
    git submodules
    CocoaPods/Carthage
    Swift Package Manager
    
    

    View Slide

12. 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
    ⏰
    

    View Slide

13. 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.
    

    View Slide

14. 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)
    

    View Slide

15. SWIFT EVERYWHERE!
    

    View Slide

16. NOT EVERYTHING IS ENGINEERING.
    Let's take a step back.
    

    View Slide

17. View Slide

18. 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 .
    .
    

    View Slide

19. WHY DO WE WANT SWIFT?
    WE ALL WANT TO
    SHIP A GREAT
    PRODUCT.
    

    View Slide

20. Management Reasons for switching
    TODAY:
    Hiring good ObjC developers is getting
    tougher
    Proof:
    NOT HIRED
    

    View Slide

21. 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
    

    View Slide

22. Management Reasons for switching
    ACME Ltd can attract brand exposure by taking part in
    the shaping of the ecosystem
    
    

    View Slide

23. Management Reasons for switching
    Other management teams have already decided
    

    View Slide

24. 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
    

    View Slide

25. 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
    

    View Slide

26. 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
    

    View Slide

27. 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™
    

    View Slide

28. 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
    

    View Slide

29. 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.
    

    View Slide

30. Thank you
    Discussion
    

    View Slide