Wrapping up 2018 on Swift by Sundell
While 2018 has been the first year since Swift was introduced in 2014 without a new major release — it has still proven to be quite a transformative year for the language, its usage, and the community as a whole.
Not only did 2018 bring the first ever Swift-only Apple framework (if we don’t count PlaygroundSupport) in the form of CreateML, both Swift 4.1 and 4.2 brought several new features that heavily reduced the need for boilerplate, and we also saw a first sneak peak of iOS apps running natively on the Mac through “Project Marzipan”.
2018 has also been a huge year for Swift by Sundell. What started as a fun experiment in early 2017 has now grown to become my main job starting January 1st! While I’m extremely grateful for all of your support, reading this site and helping me spread the word about it — I still feel like we’re just getting started, and I look forward to continue expanding this site and launch brand new projects in 2019.
But before we get to that, let’s take a quick look back at 2018 — at what has been some of the most popular articles on this site, as well as general trends in the development of Swift, both as a language and the way we use it as a community — and where it looks like things are headed with Swift 5 and beyond.
Since a new article is published on this site every Sunday — all year long — 52 new articles (including this one) have been added during 2018. So which ones have been the most popular (counting by number of page views)? Let’s find out! 😀
How to implement navigation between the various screens of an app, in a way that’s unambiguous and easy to maintain, continues to be quite a challenge — especially as an app grows and new features are added. In this article I outlined my takes on the popular Coordinator and Navigator patterns — both of which can really help make navigation a lot more smooth — which turned out to be the most popular article of the year.
While it seems like many Swift developers consider the delegate pattern a thing of the past — and have instead opted for solutions like Functional Reactive Programming (using frameworks such as RxSwift) to communicate between objects — delegates continue to be an important part of Apple’s SDKs and frameworks.
It could also be argued that delegates are a simpler solution whenever an object and its owner have a one-to-one relationship, especially considering that most iOS and Mac developers are very familiar with them — so in this article I wanted to take a look at various ways of implementing the delegate pattern and how it can be made more “Swifty” using things like closures.
One of the reasons why testing hasn’t historically been very popular among iOS and Mac developers might be due to the fact that much of the logic we write when building apps has some form of asynchronous component — like a network call, or work performed on a background thread — and such code is almost always more difficult to test.
However, there’s a few ways that even the most heavily asynchronous code can be made testable — so in this article I wanted to highlight some of those ways and how they can be applied without huge modifications to the code that’s being tested.
One major shift going from Objective-C to Swift has been the increased focus on writing code that’s validated at compile time rather than at runtime. One trend that’s along those lines is the very popular use of a
Result type to model the results of (mostly asynchronous) operations, instead of using multiple optionals.
In fact, using result types has become so popular that an implementation of
Result has just been accepted for introduction into the Swift standard library and will be released as part of Swift 5.
In this article I wanted to show some of the practical implications of using result types, and some of the cool features that can be built on top of them.
The final top article of 2018 is all about view controller containment, and how building custom container view controllers — similar to
UITabBarController — can make it much easier to manage all the various states that a given screen can be in.
Even though first-class support for adding a view controller as a child to another view controller was introduced all the way back in iOS 5, many code bases still only use a single view controller per screen or feature — which usually leads to the common massive view controller problem. Custom container view controllers can be a great first step to start reversing that trend.
Speaking of trends, one of the major trends in the evolution of Swift as a language is the increasing use of the compiler as a code generation tool — which is a great way to counteract some of the boilerplate that Swift’s static type system sometimes forces us to write.
Continuing what was started with Swift 4.0’s introduction of
Codable and the automatic generation of conformances to it — this year brought automatic conformances to
Hashable, as well as conditional conformances, as part of Swift 4.1 — and then auto-generation of enum case collections with
CaseIterable in Swift 4.2.
I personally think that this trend will continue, as compiler-integrated code generation gives us many of the advantages of more dynamic programming — without sacrificing compile time safety. For example, imagine if Xcode would automatically generate a navigation graph in code based on our app’s storyboard, or if Swift would gain a built-in way to do container-based dependency injection by leveraging code generation.
There’s really a ton of possibilities here, and I think as a community we’ve barely scratched the surface of what’s possible — and even though there are several third party tools available for code generation, having it integrated into the compiler itself really brings things to a whole new level.
Another prominent trend in the Swift community right now is the increased focus on automated testing — whether that’s unit tests, UI tests, or some other flavor. It seems like more and more teams are discovering the value of using automated tests and continuous integration, even without working strictly with test-driven development.
A big part of that trend, as far as I see it, is that many developers — myself included — have realized that writing tests doesn’t have to be such a big deal, and that tests still have a ton of value even if a code base isn’t 100% covered or if certain ”shortcuts” are taken in the beginning.
Like with most things — there’s a balance to be struck somewhere in between always striving for a complete test coverage, following common practices regarding the way tests are written and worked with, and keeping up with a busy schedule. At the end of the day, testing is a tool, not a way of life.
You can find a lot of articles about testing on the category page.
With the upcoming public release of “Project Marzipan”, iOS 13 — which has been rumored to include some major changes to the system UI — and Swift 5 on the horizon, 2019 is looking to become quite an exciting year.
While the main focus for Swift 5 is on achieving ABI stability — it’ll also bring a few new features to the table, in a way that looks to be mostly backward compatible with existing source code.
The new built-in
Result type will make it easier to pass the same result instance across different modules, and create a uniform standard for all kinds of asynchronous results. The
String type’s new APIs for interpolation and raw strings should make working with more complex strings easier, and allow for some interesting new ways of expressing attributes and other string metadata. And
@dynamicCallable is another big step towards making Swift more capable of dynamic programming.
I’ll cover Swift 5 a lot more — and explore concrete, practical examples of the above features in action — both in future weekly articles and on upcoming episodes of the podcast, as we get closer to Swift 5’s official release.
Whether you’ve read all 52 articles on this site this year, just a handful, or if this is your very first one — I’m incredibly happy to have you as a reader. Being able to share my work with you this way — and hearing all of your feedback and encouraging comments — is so amazing, and I’m looking forward to expanding this site even more during the upcoming year.
Making Swift by Sundell my main job is both incredibly exciting and very scary — but it feels like one of those things that if I wouldn’t at least try it, then I’d regret it forever. All of your support — in both sharing my content with others and helping me connect with new sponsors — has played a huge part in giving me the confidence to make this jump, and I couldn’t be more grateful.
What do you think? What has been the biggest way you've changed the way you write Swift code this year, and what Swift 5 features have you the most excited? Let me know — along with your questions, comments and feedback — on Twitter @johnsundell.
Thanks for reading, and happy new year! 🚀