Developers and Apple open up on new Swift programming language
Is its just-launched developer blog about the Swift programming language a sign of a new, more open Apple? Whatever the answer, the blog's information will no doubt be welcome to developers. Some are working away at adding new libraries; others are feeling a byte of angst about programming language future shock.
Featured
Apple's Swift Blog was used to announce that the new Xcode 6 beta, introduced at Apple's Worldwide Developer Conference (WWDC) in June, will now be offered free to all "registered Apple developers."
This appears to encompass both coders enrolled in one of Apple's paid Developer Programs for Mac and iOS platforms, as well as those developers who have simply registered for free.
This extension of the Xcode beta to the only-registered group looks to be another sign of Apple opening up its development resources, especially when matched with the announced OS X Yosemite Beta program (with a million user goal) and the current OS X Mavericks Beta program.
One of the first posts on the new blog was about compatibility. The post warned developers to be careful when managing versions of Xcode and Swift, as well as third-party frameworks.
"While your app's runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together.
This means that frameworks need to be managed carefully. For instance, if your project uses frameworks to share code with an embedded extension, you will want to build the frameworks, app, and extensions together. It would be dangerous to rely upon binary frameworks that use Swift — especially from third parties. As Swift changes, those frameworks will be incompatible with the rest of your app. When the binary interface stabilizes in a year or two, the Swift runtime will become part of the host OS and this limitation will no longer exist."
Meanwhile, the interest in Swift continues to grow as do the questions from developers. Here are some interesting articles I noticed recently:
The We Heart Swift blog posted a link to a video from the recent meeting of the San Francisco SLUG, Swift Language User Group, featuring a presentation by Keith Smiley. It runs down a number of features.
Programmer Mike Ash discussed the "Secrets of Swift's Speed" in a post on his blog. He admits that since the current Swift compiler is a "bit rough," his long article is really about why Swift performance should be speedier than Objective-C.
"Most of the slowness looks to come down to a lot of redundant retain/release activity being emitted by the compiler. I expect this to be fixed before too long, but in the meantime, it means that this article is going to be more about how Swift could potentially be faster than Objective-C than about how it's actually faster right now."
On the other hand, programmer Marco Armenti riffs on a worried post by web developer Ed Finkler, the co-host of the Development Hell podcast. They both admit to finding a diminishing tolerance for the learning curves accompanying new tools and languages. Armenti writes that some of Swift's bells and whistles may be nice — for someone else!
"Swift looks interesting, but in all of Overcast’s development so far, I’ve never run into a problem that’s the language’s fault that Swift would have handled better. It appears to solve problems I don’t have, to gain small (and still theoretical) optimizations that I don’t need, at the expense of many Objective-C features I really like.
I don’t even know if Swift saves a lot of complexity, as it promises: its code appears smaller, but it’s far more dense, which is deceiving. Simpler code is great, but less code that isn’t actually simpler doesn’t inherently help — it’s just harder to read, harder to learn, and more prone to hard-to-see bugs. Most Swift code samples I’ve seen haven’t been much simpler than Objective-C equivalents — just shorter."
In an interesting post at his Clark's Tech Blog, Clark Goble runs down Pythonic, which adds the standard Python library to Swift. He says that while robust, Pythonic doesn't add everything from Python. Still, Clark notes that he prefers to use native methods.
"I confess I prefer to use native methods whenever possible. For less commonly used methods I will even prefer Cocoa methods that aren’t really ideal. So in the Extensions or Categories I write for my own use I strip out anything I know I won’t use regularly. I love brevity, which is why I love Swift when combined with certain Python features. However I also think that only the most used methods should be brief. For lesser used ones I like the self documenting nature of Cocoa. That said, Cocoa was horrible for a lot of commonly used features like strings. That’s where Extensions in Swift along with some limited operator overloading is nice. Brevity where you need it and just where you need it."
Finally, there's the mention of Swift in a post to the Monday Note blog by Frédéric Filloux, who runs digital operations at Les Echos, a French business media group. He looks at a number of trends in the mobile market, including which platform is better for developers (Android vs. iOS) and the future of web applications. As I have pointed out in the past, more money is being made by iOS developers.
Filloux foresees a "new breed" of apps based on iOS 8 and built with Swift. All this may lead to changes in for developers.
Put differently: Advanced functionalities in Swift/iOS 8-based apps will raise the level of user expectations; publishers will be forced to respond accordingly: as apps reside side by side on the same mobile screen, news apps will be required to display the same level of sophistication than, say, a gaming app — that’s also why I’m less bullish on web apps. Behind the iOS/Android gap lies another question: Should publishers have the same app (content, features, revenue model across) all platforms – or must they tailor their product to platform 'moneygraphics'? That’s an open question.
Read more: