The Frustrations of Learning Swift (And Why You’ll Learn to Love It)!
New programming languages are born regularly; whether it’s a part of a computer science course, a small incremental evolution of an existing language, or something completely different, new programming languages are a dime a dozen. If you’re like me, however, you’ve been watching the rise of Swift, the evolution of Apple’s ecosystem, and the upcoming ARM revolution and decided to learn Swift!
As with learning any new programming language, there are going to be brick walls that you’ll run headfirst into. Swift is no different, and in my opinion, stands alone as the most frustrating popular modern language to date. Be forewarned: This is a cautionary tale, but one with a happy ending.
Continuity (Or Lack Thereof)
Let’s cut to the chase — the ability to view innovative code examples, or ways to accomplish a small task is paramount for most programmers. Sure, we could all rewrite the same algorithms, but typically there’s been someone before us who has done the heavy lifting… they’ve already battle-tested the code, managed the edge-cases, and typically its efficiency has been scrutinized and refined.
This brings me to my primary frustration with Swift — version continuity and compatibility.
In some of my early iOS projects, I found myself seeking out answers to basic fundamental questions, like the different ways to cast and validate data. What I found was a consistent theme: most code examples that are a couple of years old will no longer work in your version of Swift/Xcode. Here’s a primary example:
The mind-boggling thing for a programmer that is used to version continuity, and trying to learn Swift, is that the functional and syntax changes happen on very basic core functions, such as casting. Compare that to something like PHP, where they take a painstaking level of effort to ensure compatibility between versions, and you’ll understand the frustration. That, of course, comes with some downsides — but more on that later.
Interface Changes
Along with the language syntax changes, Xcode has had its own set of continuity-breaking customizations (Xcode is the primary IDE for Swift development, although there are alternatives available). Seemingly simple interface changes, such as iconography, can be a massive time-suck when you are trying to follow along with introductory courses, online examples, or just googling, “Where do I find the Connections Inspector?”
Some changes are subtle, but others have been relocated entirely. I originally wanted this article to document the changes for those who may be searching for a simple guide, “Looking for this? Look here…”, but determined that by the time of publication, it will likely change again.
The Future is Bright
There are certainly a lot of frustrations in Swift for new and old developers alike. With that said, there’s a lot to like here!
As I mentioned before, a language like PHP has clear downsides when it comes to its compatibility layer and design. A fascinating talk by the creator of PHP, Rasmus Lerdorf, lays out the case for preserving continuity in the code, but also the pitfalls of performance. When you are optimizing a language to run on the widest array of hardware and operating systems imaginable, any major change can have catastrophic impacts. As such, we’re just now seeing innovations in opcode caching, opcache preloading, and even a JIT in PHP that have been in development for years, but have had to go through multiple layers of preparation and planning to implement safely. If you haven’t watched it, but want to hear from a founder discuss the lowlights and highlights of a mature platform, it’s well worth the 1-hour presentation.
Alternatively, Swift operates in a much tighter ecosystem, with more rigid demands. The hardware is pre-defined, which limits the variability you have to code for, and Apps are expected to launch quickly, be highly responsive, and operate without crashing.
This has been a tough road for iOS. Despite a major marketshare advantage, limited device variability, and arguably tougher App Store restrictions, iOS hasn’t always been the better performer in terms of app performance.
In the top quartile of apps, Android apps crashed 0.15% of the time they launched, while top quartile iOS apps crashed 0.51% of the time. In the second quartile of apps, Android apps crashed 0.73% of the time and iOS apps crashed 1.47% of their launches.
Source: Tomio Geron, Forbes
Now note, this article was written 8 years ago, but even more recently, research firms have indicated similar sentiments. So you might ask yourself, “Why do most of the best apps land on iOS first?”
And the reason is simple — With over 95% of iOS devices operating on a version 1 release old or newer, that means that the variability or edge cases that you need to be concerned about are much fewer. Compare that to Android, where there are double-digits still using Nougat or Marshmallow, and you’ll start to unravel how Apple sees itself winning the platform race — and why I think you’ll learn to love Swift.
What do you think? Join the conversation and let me know your thoughts!
Additional resources to bookmark:
Xcode and Swift version compatibility list, by Ben Leggiero
Some great (and probably familiar) alternatives to Xcode for developing Swift, by Ambika Choudhury
