Swift is Destroying iOS Development Productivity
As an iOS developer for several years, I am really surprised I am not hearing murmurs about how badly Swift is destroying Apple’s X Code development environment. It’s one of the worst signs of Apple’s lack of commitment to developers over the years. For years, X Code actually got better and faster. Now with Swift, it feels like the IDE barely works at all. Swift is a particularly unique attempt at designing a programming language. I am not sure a “mainstream” language has ever been developed in such way as to basically not have much of a conceptual premise, but rather design by fiddling, scrapping and redoing bridge-ware to the *other* Apple language objective C. I say attempt at a programming language, because sometimes Im not even sure Swift IS a programming language. To someone who has been writing software every day for over 20 years in various languages, Swift feels more like a piece of very slow Nag-ware that could increase productivity, if it could get out of its own way. It *is* a programming language by the fact that it can compile code. Other than that, I think the jury is out on it’s features and implementation. The jury however is NOT out that it has destroyed X Code productivity, possibly for good.
This may come at a good time for Apple. Since the app store is glutted with spam, dead apps, and apps people don’t need or want much if they could ever find them. Perhaps Apple believes while it is rethinking the app store, it has time to piss off developers with shoddy product like Swift. The app store could do with *fewer* apps rather than more.
The exit from Apple of Chris Lattner the Swift project lead, may be an opportunity to clean up this mess. X Code compilation times and syntax parsing are barely functional when writing apps in Swift. Even on the best Apple hardware Swift will flag errors un flag them and reflag them or not like a blinking Christmas tree bewildering developers wondering if the IDE is broken or if their code is.
Dubious language features like Optional types litter code with compiler hints which are hard to understand and become a constant IDE nag while trying to write code. Worse, the replacement hints that IDE suggest if left in place will actually *cause* the crashes that optionals intend to eliminate by suggesting force unwrapping nils.
But the IDE impact isn't the only problem with optionals, its that the compiler hints when dealing with fairly simple object nesting, are not something that a developer can deal with in a simple text editor. As a developer who can write syntactically correct code in many languages using a simple text editor which will compile on the first try, Swift’s optional really makes developers dependent on its quirks in a way that optionals don’t in other languages. Its not true that every new nice thing that developers can do to improve code quality should be part of a programming language. Optionals are a more rational choice for opt-in libraries. Swift itself should make ‘optionals’ optional with a compiler switch or find a different implementation.
A sign of Swift’s failures are that the language cannot be used to perform rudimentary tasks like parsing simple, bog standard web structures such as JSON without using operator overloading to deal with the side effects of the inflexible type system. In other languages statically typed or not, JSON can be parsed generically in a few lines of code.
Its true, even with Swift 3.0 (0.3?) *all* developers and their libraries still rely on objective C libraries to parse such a simple structure. Its hard to imagine what a more complicated XML, or YAML parser might force a Swift developer to resort to.
Every revision of Swift is also incompatible with the previous as Lattner continues to fiddle with it. Given that countless mobile shops adopted it early on, the 3.0 moniker is a serious insult when every version of X Code breaks your app and you have to “convert” the entire code base. If Swift deserves any scorn, that is perhaps the most deserved. 3.0 is actually 0.3. I have had major corporate dev leads tell me that the time they spent learning Swift was a complete waste of time. Seven year old objective C apps still run out of the box without modification.
Swift fulfilled its mandate when it eliminated objective C headers and pointers. It’s clear that the maintainers of X Code were not able to really parse the language that Chris Lattner envisioned with all its features. Parsing and compilation times for objective C are as just a guess a hundred X faster than Swift. Again, suggesting that Swift may not be a programming language at all, but similar to C++, a macro generation language that might be better suited as an optimizer of a scaled down Swift and not a front end language itself. As the creator of LLVM, its not surprising that Lattner would create something that is orthogonal to what developers are trying to accomplish. Like C++ , Swift shares the poor compilation times and the addition of typing features that only purists would seek, and yet disappoint with their lack of uniformity and true power.
In the end, Swift, perhaps especially in its open source variant will end up a footnote in the development of programming languages, where the designers of the language were more interested in the compiler than in the productivity of the developers who use it. Objective C was open sourced over 20 years ago, it was a great language but neutered, and useless by design as a language outside of Apple products, whose developers must use what Apple tells them to use. In the modern era of programming language design which is getting easier to implement every day, the greatest sin of all is to create a language which is not better than Java. Apple and Chris Lattner have committed this sin given every opportunity and all the resources required to do the opposite.