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