The Swift programming language was first announced by Apple at WWDC 2014, albeit in beta form. Released alongside an extensive iBooks manual, it was later discovered that Apple coded the WWDC app for that year’s conference in Swift without telling anyone.
NOTE: Anyone interested in learning to code, DaVinci Coders offers multiple courses designed to get you into the rapidly growing technology industry. For more info please visit davincicoders.com.
Swift 1.0, the first non-beta version of the language, was released in September alongside iOS 8.0. Version 1.1 arrived a month later with OS X Yosemite, and version 1.2 came out in February. Each of these language tweaks was accompanied by an update for Xcode, and Apple has been working to improve the general speed and stability of Swift and Xcode itself throughout it all.
Now that the language has been around in one form or another for about a year, we checked in with a wide swath of iOS and OS X developers to see just how things were progressing. Are there any other things about Swift that haven’t quite caught up to Objective-C? Are Apple’s promised improvements panning out? And what kind of things do developers want for future versions of Swift?
Most developers are on board
Developers have been quick to pick up on Swift, as pointed out extensively in a Bloomberg piece yesterday. In January of this year, analysis firm RedMonk found Swift to be the 27th-most-popular programming language (JavaScript is number one, Objective-C is 10th), calling its growth “essentially unprecedented.”
A survey of 26,086 developers at Stack Overflow found Swift to be the top language on its “most loved” list—developers programming with Swift intend to continue programming with it. It was also ninth on the “most wanted” list, which polled developers about the languages they weren’t using but were interested in learning about.
Of the developers we spoke to, most were shipping Swift code in some capacity. Some smaller, newer projects were entirely coded in Swift, but using Swift for new pieces of apps otherwise coded in Objective-C was more common.
“When Swift came out, we decided to build an app called Stream,” Raphael Miller, mobile application developer for Getty Images, told Ars. “We decided to build that in 100 percent Swift at the time.”
Stream is Getty Images’ more consumer-facing app, and Miller says the team was ready to build it right around the time Swift was released. The timing worked out well. Getty’s main Images app is a bit older and was originally coded in Objective-C, but Miller tells us that the app is now between 50 and 60 percent Swift code too.
“Our big app in particular, we’ve made a strategic decision to get those off of the old Objective-C codebase and move over to Swift now that things kind of feel like they’ve settled down in the language,” Miller said. “If we have stuff that’s already written in Objective-C that’s working fine we may do new features but if we have time we typically will rewrite stuff in Swift as well.”
Brady Archambo, the iOS engineering lead at Slack, told us the company’s iOS app was currently about 10 percent Swift code and that it would grow to between 15 and 20 percent “in the next month or so.” The transition has been a bit slower since the team doesn’t want to throw out perfectly good Objective-C code.
“We pretty much have not ported any existing code over to Swift,” he told Ars. “But often if we would rewrite a feature… we’d use Swift there. It’s just pretty much been rewrites.”
This seems to be a fairly common sentiment. Developers don’t want to toss out what’s working, and it’s rare to find developers who have completely dumped Objective-C. Still, Swift will become more common as more code in more apps is overhauled and replaced. Some developers have simply replaced code faster than others at this point.
“We’re only maintaining Objective-C to support our legacy code,” said Eduardo Fonseca, CTO at Playlist Media. “We are using Swift for 75 percent of our codebase. Most of our tools are already 100 percent Swift. We love the language and the attention Apple is giving to it.”
App developers who switched a larger portion of their codebases from Objective-C to Swift were sometimes able to significantly reduce the number of lines of code they were shipping. This was the case for Jason Patterson, director of mobile technology at Dow Jones, when rewriting sections of the mobile Wall Street Journal app.
“Our current focus is to revamp our content download and update subsystem, which was originally written in Objective-C and is around 15,000 lines of code,” Patterson told Ars. “Instead of fixing or enhancing that codebase, we decided to start anew in Swift. The process has gone fairly smoothly, and our updated framework is now just 5,000 lines of code. This represents a simplification in our architecture, but also shows that Swift represents more concise code.”
Easier to learn and teach, harder to mess up
One of Apple’s key selling points for Swift is that it prevents common errors and “eliminates entire classes of unsafe code.” In many cases, this makes the language easier to learn and to teach than Objective-C.
We spoke with several developers associated with App Camp For Girls, a small-but-growing group that wants to address the development community’s lopsided gender balance. The camp walks middle-school-aged girls through every step of the app development process, from coming up with ideas to coding on MacBook Pros and iPod Touches to marketing their new apps. (You can support this year’s camp through its ongoing Indiegogo campaign.)
“This summer we are definitely changing to Swift,” Jean MacDonald, creator of the App Camp for Girls program, told Ars. “We’ve rewritten our camp apps—each summer we have a few template apps that are kind of a barebones structure for the girls to build on, and those App Camp curriculum apps will also use Swift this summer. And we’re looking forward to it because the simplicity of Swift compared to Objective-C is going to make it more accessible, or at least less intimidating, for the campers.”
Other volunteers with App Camp for Girls were optimistic about teaching the language and generally had good experiences with it themselves. Lesley Baker, an iOS developer and a teacher with App Camp Seattle, was initially frustrated by learning Swift but quickly became “a complete convert.” She now finds it relatively easy to accomplish tasks in Swift that she once accomplished in Objective-C.
“That said, it’s also taken a bit to wrap my head around Swift’s ideology,” she told Ars. “Just rewriting my Objective-C code to Swift syntax can sometimes defeat some of the philosophical tenets Swift is trying to push around immutability and functional programming. But I appreciate taking that step back and really thinking about what my code is trying to accomplish and the safest way it can do that.”
Baker believes that Swift’s syntax is easier to understand and thus easier to teach and learn.
“When you’re first learning it’s usually about whether your code compiles or not, and I like that Swift won’t even let you compile in some cases without starting to think of some of those things,” she said. “Hopefully that will lead to a better understanding of what’s going on and not be too frustrating.”
Liz Marley, another volunteer with App Camp Seattle and a product manager at The Omni Group, told us more about the specific benefits and challenges of implementing Swift into the App Camp curriculum. They were able to make a proof-of-concept version of the curriculum in Swift “in just a couple of days,” and Marley says that Swift’s Playgrounds feature will help campers get more comfortable with experimenting with snippets of code.
“We’re still polishing the code and curriculum, but I think there will be some definite advantages this summer,” Marley told Ars. “The past two summers teaching Objective-C, we saw a number of our camper developers struggle with syntax, particularly forgetting to put semi-colons at the end of lines. Swift doesn’t require semi-colons, nor understanding when to use brackets versus dot syntax.”
While a few things that were more complicated with Objective-C became less so with Swift, a handful of things actually became more complex. Marley pointed us towards the process of converting a string to an integer, something that “will just work” in Objective-C so long as the string actually was a bunch of digits. “So the campers can see some calculations work, and then test the app more and discover that it crashes if a string of letters is used,” she noted. “However, in Swift, converting a string to an integer won’t even compile without dealing with Optionals. There are tradeoffs to each language’s philosophy, and an effective lesson plan needs to be tailored to the language being taught.”
Other working developers have mostly good things to say about how easy it is to pick up Swift and how the language wipes out some types of bugs.
“Talent is tight in mobile development, there’s a lot of demand for it,” Getty Images’ Miller told Ars. “We’ve noticed that with Swift you can bring in junior people quicker. That was a really big point for us, because they could start contributing much faster. The learning curve is still there, but it seems like people pick it up faster, and they’re less worried about syntax and more about just writing code.”
“The largest benefit is that Swift is an environment to write more ‘verifiable’ code,” said Dow Jones’ Patterson. “You can literally look at the code to see potential crash locations—for example, there is a construct called ‘optional unwrapping’ that has the potential to crash your app. It’s represented by an exclamation point so they stand out. It helps you write production-ready code, handling any failure cases at coding time, versus finding problems at runtime in testing or in the wild.”
But it’s still a young language, and not everyone is ready yet
Though most developers we talked to were coding in Swift with various levels of enthusiasm, others still hadn’t dabbled much. Commonly cited concerns included the relative immaturity of Swift and its development tools or a fear of mixing Swift code with Objective-C code. Others simply hadn’t had time to pick up a whole new programming language.
“In the beginning (i.e. last summer/fall), it seemed not quite ready for production use,” said Robert Tolar Haining, an iOS developer at Modest. “Nowadays, I don’t have those concerns, but I’ve just been too busy with other stuff to invest the time in learning a new language. On top of that, I work on a single code base, and it seems like it’s a bit complex to combine both Swift and Objective-C in a single code base.”
“I think we would want to see a freeze in Swift in order to seriously consider adopting it,” said Chris Carr, a mobile app developer for Michigan Labs. “We just haven’t felt that it’s production ready. With the changing specification between Swift versions, we just can’t waste our client’s time on changes required by a change to the underlying language spec. There’s really nothing you can do in Swift that you can’t do in Objective-C. Plus, consider that Apple’s WatchKit sample code and the open source ResearchKit are both Objective-C.”
So developers generally like Swift and they’re generally using Swift, but there’s no denying that it’s still a very young language. It’s currently changing at a fast pace, and the development tools continue to need improvement (though they’ve come a long way in the last year alone). Compiler speed is a commonly cited issue, although it has steadily improved as Xcode 6 has matured.
“Swift feels like a modern language,” said Primate Labs’ John Poole to Ars, “[That’s] especially in comparison to Objective-C, and unfortunately that means the compiler does more work.”
The developer tools were generally the things that devs complained about the most when it came to actually coding in Swift. This post by Kyle Sherman, a software engineer at Slideshare, details the progression of the tools from the first beta to the present. Early versions of the tools especially had problems with crashes and a lack of helpful error messages, and the latter problem still persists even though the crashiness has slowly improved.
“Sometimes the error messages in Xcode can be a bit obscure and frustrating to figure out,” App Camp’s Baker told Ars. “But I’ve seen improvement in that over the past year and imagine it will get even better.”
In other cases, the problems are with the ecosystem surrounding Swift rather than Swift itself. Alexander Babaev, technical director at DevPocket, cited community knowledge as a drawback to Swift in these (relatively) early days—devs just haven’t had as much time to mull and discuss and solve Swift problems yet.
“The biggest drawback so far is that a lot of third party libraries haven’t converted to Swift so we’re still stuck using bridging headers for any project that needs these, rather than being able to create a pure Swift app,” said Matthew Keable, a mobile developer at SimpleClick. “Even those that have started to produce a Swift version such as AlamoFire for AFNetworking, the Swift library isn’t as feature complete as the Objective C version. Given that about 15 percent of iOS users are still on iOS 7 we still need to support that platform. Sadly Swift can only properly import Swift frameworks for iOS 8, so it makes including these third party libraries a less than optimal experience when supporting iOS 7.”
“The biggest drawback, in my opinion, it’s that Swift is not as fast as Apple advertised—but hey, it’s not slow either,” Fonseca told Ars (the folks at Primate Labs have been tracking the speed of Swift executables over the past year). “The compiler is kinda picky and throws some weird messages sometimes. And, of course, the overall stability of Xcode when using Swift. [6.3.2] helped, but it’s still slow and buggy. The compiler messages are frustrating and whenever you mix Storyboards (known for bugginess and slowness by itself) and Swift, you have a recipe for crashes. I’ve sent so many Crash Reports to Apple so far—I don’t even remember how many.”
That said, developers mostly seem willing to keep up
Though Swift is a young language and it’s changing fairly rapidly, that part of the equation doesn’t generally seem to bother developers. Apple has changed or added to the language a few times—it went through the beta, then versions 1.0 through 1.2—but the alterations haven’t been too difficult to keep up with.
“To me, the changes so far have been significant and have been making my life better,” said a developer for Duolingo. “For example, the (backwards-incompatible) changes in Swift 1.2, which came out in February, were very welcome. In terms of language features, I’m particularly referring to the improved `if let` syntax, the more explicit `as!` syntax for failable casts, and `let` constants now being more consistent with `var` constants. These are not massive differences that change the face of the language. So far, the Swift developers have shown good taste with most things and I’m looking forward to seeing what follows.”
“In a code base like ours, it typically takes me an hour or two to update things,” he continued. “I knew I’d have to do this beforehand and accepted it, in exchange for a language that slowly improves until it reaches a stable version. Importantly, this has rarely happened.”
“When Swift 1.2 was released, we probably spent less than an hour fixing up the incompatibilities,” Patterson told Ars. “They were mainly errors with linking to the rest of iOS versus breaking changes in Swift itself, so everything was pretty simple to fix. We’re looking forward to what Apple does next with the language.”
“All changes were improvements,” said Fonseca. “Apple, as a company, is changing in my opinion. They are listening to the community and adding awesome constructs to the language. Nothing so far, in my opinion, was a pain to support—it was always some great improvement the community asked for and, of course, bug fixes and performance improvements. Nothing to complain about.”
Several developers—including Jeremy Tregunna, an iOS engineer at Shutterfly—were confident that even these changes would slow down over time as the language becomes more mature.
“Over time, the language will stabilize more than it has over the last year, so long term, this isn’t really a concern of mine,” said Tregunna. “I used to be a core developer of a programming language, and tend to spend a lot of time with newer languages too (Rust, Idris, etc.) so the fast pace is actually not that shocking.”
Where do developers want Swift to go?
Most of the problems developers have with Swift relate to just how new it is—a year isn’t all that much time for a programming language, especially given that Objective-C dates back to the early 80s. By the same token, much of what they want from Apple in subsequent versions are things they’re used to in other languages.
“Swift brings some much-needed syntax improvements for writing asynchronous code, but it still ‘looks’ asynchronous,” Patterson told Ars. “Other languages have first-class support for asynchronous tasks, such as C#, so the code ‘looks’ synchronous and the complexity of writing (and reading) the code is simplified. We’d love to see something like that in Swift.”
“As for what I’d like to see at WWDC, and I don’t expect to see this, but perhaps by Swift 2.0 or maybe 3.0, is support for optional borrow checking,” said Tregunna. “By this I mean to provide safety when sharing references to objects. This would allow us developers to eliminate certain classes of multithreading bugs, and better explain what our intent is, clearly within code. This is one area Swift really should improve memory safety, but doesn’t yet.”
“The biggest thing that we’re going to need to be able to go all-in on Swift is time,” said Keable. “Time for the big libraries to convert to Swift, time for iOS 7 to fade away so we can utilize frameworks properly. I’d like to see Apple publish a proper roadmap for Swift so we can plan for releases ahead of time. I’d also like to see them expand Xcode so that we get the same functionality for Swift and Objective C. Right now I’ve not encountered any language level issues or features that I’d like to see, but so far the projects we’ve used Swift for haven’t required any deep dives into low-level functionality.”
Update: As expected, Apple announced Swift 2 today, and it has announced that it will make the language open-source. Read more about Swift 2 on Apple’s developer site.
Image credit: Apple
Via Ars Technica
