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