Google announced over the weekend that its new Android application development tool (“Google App Inventor”) would be available this morning. It’s a move that adds an interesting and potentially very significant layer to the bloomin’ onion of mobile application development. It solidifies the notion that Google is betting long-term that their open development model, which allows (now quite literally) anyone with even a passing interest to develop apps and run them on their own device, or presumably to share them with friends. Google gets a front-row seat to see what people want and what people come up with when left to their own devices, potentially very valuable knowledge, incase you had any questions about what Google is really after (put simply, every bit of information they can possibly collect about your behavior and information).

The new development environment provides a visual toolbox of different phone and mobile device functionalities, which can be dragged, combined, and arranged by programming novices to achieve new functionality. Google is hoping that not only will the masses continue to buy apps, but that they’ll start to develop their own. Will this usher in an era of Apps2.0 and an explosion of user-content generated apps that will leave established developers and software publishers grimacing as the attentions of their loyal customers are distracted by a flood of arguably lesser quality but with a much broader arrayed set of specifically targeted functionalities, as in the way that traditional print and online ¬†publications have seen their audiences dwindle, drawn to blogs tailoring to very specific interests?

Potentially, it could be game-changer huge. As with so many things, the timing and positioning are critical, and I’m of the mind that it is both a bit premature and that Google may stumble when it comes to positioning. There is a certain contingent (well represented in the Android customer community) that is sure to embrace this ability immediately – and let’s face it, it’s a pretty cool idea. I think anyone who shares the sentiment that computer science and technological advances should promise to make ever increasingly complex operations accessible to casual users would see this as a significant step in the right direction.

Apple has specifically shunned the approach though, reserving the ability to program its mobile devices for those ¬†experienced in traditional programming languages and application design patterns. Apple argues that if you aren’t aware of certain things (like which processes cause a battery to drain quickly, or the inability to recognize when software you’ve written is hogging resources and memory), you can’t effectively program a mobile device and deliver a good experience. Whereas Google assumes a use-at-your-own-risk approach, Apple attempts to control the experience of using their device even when said device is running 3rd party applications.

Watching these two strategies unfold is going to be fascinating. I’ll reiterate the idea that I don’t think it’s a zero-sum game, at least not to the degree that the desktop wars were. Neither Apple nor Google may ever achieve the percentages on mobile devices that Microsoft achieved on the desktop, although it’s also entirely conceivable that either could. With so much of the world’s mobile market territory unclaimed however, I think the current primary focus is on building awareness of platforms, and while though specter of a battle looms, both companies have a lot of growing to do before they will actually have to battle it out for each others customers.

I wouldn’t rule out the notion that Apple will eventually deliver a rapid application development tool for iPhone and iPad, enabling similar functionality. Their mobile Bento database software already allows for custom databases and information strategies implemented by end users, though it’s hardly equivalent to a development tool. It is important to remember, however, that Apple has been in the OS business for a bit longer than Google, and the first thought that occurred to me while reading the description of App Inventor was that it sounded like the grotesque love-child of Bento and Apple’s “Automator” software, which allows non-programmers to document and automate certain application processes on desktop Macs. Automator actually is a well implemented system that allows casual users to build little applications – there are plenty of crucial differentiators (Bento cannot, for example, tell what that your device has changed orientations), but to a casual consumer, a description of Apple’s Automator might very well be mistaken for Android’s App Inventor. Drag, drop, and you’ve got your own solution. The only problem is that Automator has been out for a few years, and while I’ve seen some it do some nifty things on the Macs of my friends, very few people have ever heard of it, and I’ve never met a non-geek who wasn’t scared stiff at the idea of writing their own automator apps. And that brings me to my conclusion, which is that most people don’t actually want to write apps. I could be wrong, and I think the right tools might go a long way to change this over time, but for the time being, looking over the App Inventor documentation, I can’t see this system as it stands compelling very many people who aren’t already avid techies.

Best case scenario: A new era of mobile apps and innovation ushered in by those who haven’t studied at MIT or Standord, political outsiders-if-you-will, forever changing the landscape of what people expect and want from apps (hint: simple is the answer, but Apple already has simple, and they built it with the best and brightest of the establishment).

Most likely scenario: A few cool apps from the handful of people who play with the tools, and a never ending cascade of PowerPoint presentations reinvented as Android apps.


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>