Rumor has it that Google may be considering making Apple’s Swift a first class language for Android development. Predictably, the internet has been pretty excited about this possibility. My lack of enthusiasm for Swift has been fairly well document, so I’m going to keep my comments to a minimum. Swift on Android shares the same API problem as Swift on iOS and this likely has more to do with legal wrangling than technology.
Java and Objective-C are very object oriented languages and the Android SDK and Cocoa Touch APIs reflect that. Swift is a far more functional language than either of them. “Good Swift”, which I have been told is functional and not just “Objective-C in Swift” doesn’t really go so well with a OO designed API on Apple’s platform. Why should that problem not exist on Android as well? Maybe Google and Apple will rewrite their SDKs to be more functional, but that’s not where they are right now.
Oracle is suing Google and has been suing Google for Android’s use of the Java programming language, which Oracle acquired in its acquisition of Sun. The lawsuit is ridiculous and a destructive waste of resources, but that’s a pretty fair description of the US legal system, so it is likely to continue to be an ongoing concern for Google. If Google were to stop using Java on Android, that might put them in a better position regarding the suit and it’s pretty clear that the licensing on Swift would prevent any similar issue from cropping up between Apple and Google.
Yes, I’m admittedly bias, but it’s important to think about the practical and ulterior motives that Google might have for adopting Swift and not just blindly jump aboard the hype train. Swift is a decent programming language, but it’s not the right solution to every problem and we should only make changes when it makes sense to do so. Let me know what you think on Twitter or Google+.
As is well documented on Twitter, I’ve had my share of frustrating system locking beachball of death experiences with Xcode, so it should come as no surprise that I’ve been keeping a keen eye on JetBrains’ AppCode IDE for iOS and MacOS development.
Being a user of two of JetBrains’ other IDEs, Android Studio and RubyMine, I found the on-boarding experience for AppCode to be pretty familar and was able to get up and running in just a few minutes. Overall, the keyboard shortcuts are very similar to their other IDEs and there’s a lot of value in having a similar setup on multiple IDEs.
AppCode also includes many of the refactoring tools that you’ll be familar with if you use any of JetBrains’ other IDEs and has impressilvely just about been able to keep up with Swift 2.0. However, it’s pretty clear that the AppCode team’s fighting an uphill battle to keep up with the development of Swift and is still refining how the refactoring tools deal with the langauge — the AppCode team will likely have to devote continued effort to keeping up with Swift for the forseable future.
Unfortunately, keeping up with Apple’s development of Swift seems ot have come at a cost, the integrated UI designer. As explained here, the Designer has been made a plugin that can be added after you install the main AppCode package. It’s also worth noting that the plugin doesn’t work on all interface file types and was not useable at all for three out of the four test iOS projects that I used to evaluate the Designer. On the one project that it did work with, it was pretty disappointing and not at all an acceptable replacement for the tooling provided in Xcode for user interface design.
What I and I imagine the vast majority of iOS and MacOS developers want out of AppCode is for it to be what it originally was planned to be — a full Xcode replacement, but there’s a lot of ground to cover before it can qualify there. If JetBrains is serious about AppCode, then they’re going to need to improve the user interface designer to the point where 100% of an iOS or MacOS development project can be done in AppCode. Let me know what you think on Twitter.
Now that we are just dabbing our toes into 2016, it’s given me some time and cause to look back at the year that was. A lot of things were happening in 2015 but they broadly break down into who was involved: Apple, Google, Microsoft, VC Startups. Today, we start with Apple.
Swift: Arguably, the largest and most positive impact Apple has had on the take space this year was in releasing and open-sourcing their new programming language Swift. Swift is on track to take the development world by storm and benefits greatly from the success of the iOS development platform with the general development community.
IBM Partnership: Apple is not historically the easiest company to partner with but this year they’ve unveiled a partnership with IBM to bring the iOS platform deeper into the enterprise space. This might have some impact but my bet is that most enterprises who are interested in mobile are going to focus on Cordova or other HTML5 based solutions for their line of business development needs. Even in the worst case, the deal with IBM gives Apple some well needed good press.
Sub Apple-Par Products: The Apple Watch was well hyped, enthusiastically covered, and basically a disappointment. Apple Music is… well… not exactly what anyone had hoped and let’s not even talk about the battery case. Their product launches this year have run counter to the usual level of quality we’ve come to expect in terms of fucntional design and user interface design. Also, they still have some serious issues when it comes to cloud services.
Successful as they may be, Apple seems to be have been stumbling in 2015 in terms of product launches while making significant strides with Swift. The Watch felt rushed and I’m hopeful that version two will be a lot more stylish and functional. All in all, Apple might want to revert back to their previous focus and take just a little more care in polishing products before launching them in 2016.
Listeners to last week’s Coder Radio know that during the live feed WWDC coverage, I was less than enthused with the announcement of Swift, Apple’s new programming language for iOS and OS X. My initial reaction was based on the somewhat unclear way they announced Swift; it was not very clear what they wanted us developers to use Swift for and that led me to the wrong conclusion that Swift is designed to be a near to medium term 100% replacement for Objective-C – this simply is not the case. So far, I’ve read through the Swift book on iBooks and the documentation publicly available twice and found something very surprising – Swift reminds of QML in QT.
This might sound a bit odd, given that in a lot of significant ways Swift and QML are very different languages, but they actually share a kindred spirit and will likely take the same place in my tool-chain – layouts. Yes, both Swift and QML are technically capable of so much more than layouts but really they are both well suited for that task in particular. Why do you think the WWDC demo was so UI / visuals heavy?
So the bottom line is no I don’t hate Swift and no I don’t think it will be the end of Apple development as we know it. And yes, I will be using it but, at least for the next year or so, in the same capacity as QML and its relationship with Objective-C will be same as QML’s with C++ in my QT code-bases.
Questions? Comments? Find me on Twitter.