This started as a regurgitation of the wisdom of Chris Stephenson – CTO of 955 Dreams who make the acclaimed Band of the Day mobile app (and others). He’s also a much-missed ex ThoughtWorker. We had lunch on Friday :)
You have iOS development substantially in XCode (or AppCode if you want a refactoring power-up over XCode). Interface Builder is the designer friendly tech that supplements both of those. For Android development, you’ll use standard Java tools: Intellij or Eclipse. There would be Visual Studios for Windows, if you were developing for that, which many don’t. Firefox Mobile OS will probably be a more open tool choice. Ubuntu Phone will be open again, but also has QtCreator for the natively supported QML apps.
Then there’s DropBox who moved to C++ development, with some home grown stuff. My buddy Samuel Audet is building out ByteDeco as a portal for C++ libraries which are ready to go for (amongst other native platforms) Android development. C++ libraries are already usable from Objective-C codebases.
Pool of available talent
This was Chris’ astute comment, expanded some:
The vast majority of development shops targeting mobile apps and wanting a native experience are going to target the idiomatically correct native port. Even in the San Francisco bay-area were there are hundreds of thousands of mobile application developers, you need to simply hire from the pool of people with established skills. If we cheekily suggest there’s only two platforms, That would be experienced iOS devs, or experienced Android devs, or (far fewer) devs with experience both. There’s no huge pool of available cross-platform developers, and that should drive decision making for many.
DropBox can make those people for their choice of technologies, and there’s reasons to want to gain that experience at Dropbox. Make means cross-train of course, and if you are a company of some size, with a way of smoothly on-boarding newbies you could do it. Dropbox could make more, by perhaps publishing frameworks, examples and how-to documentation so that others could do the same.
The major vendors can move the entire community in one direction, but only when it’s not a complete re-skilling. Apple are doing that with Swift, and it looks to be a good incremental move for them, but still lock-in sadly. Microsoft upset their fat-client windows developers when they put a question mark over their Silverlight technology, as there was no incremental path that was clear.
As cross-platform frameworks and micro-platforms get created, there’s a potential for them to gain a footing, but unless there is a significant pool of people with matching skills it is always going to be a gamble to choose that tech as your development platform, and look to hire people for it. Crossing that chasm is very hard.
In the end though, it is about whether the cross-platform tool is compelling enough. Chris and I agreed, as we parted, that for a cross-platform tool to be adopted and to cross the chasm, for a given application, it would need to concentrate on delivering a lowest lines of code possible, while simultaneously being very elegant. In both of those regards it would need to be more alluring by a margin over the incumbents.
Then there’s glass ceiling points I made a few days ago that all parties have to be mindful of as they craft technologies for us to use.
Google vs Microsoft, and the art of war (redux)
Something I wrote previously posited that Google launched Android to delay Microsoft’s Bing rollout, and consequential ad-revenue gains against Google. In the timeline we’re talking about (2007 to today), we have witnessed that WindowsCE/PocketPC has disappeared and Windows Mobile has been created instead (soon to be renamed to just Windows, or something). We’ll agree that the Bing deliverable wasn’t the huge Google-search (and ads) destroyer that it was hoped to be. We might also agree that the Windows mobile platform hasn’t culminated in a threat to Android in the six or so years or development. A double-whammy perhaps?