App Development Strategy

At the moment, I own an Android phone and an IPod Touch.  I do a lot of work on home automation and have begun to integrate both devices into what I do, envisioning them as essentially remote controls for operating the various automated appliances and articles in my house.   Presently, this is done using the browsers on both devices, but I thought it couldn’t hurt to dip my toe into the waters of “app” development to better understand how to leverage those technologies.  I don’t, personally, think that the notion of “apps” will continue to be as en vogue over the next decade, as we’ve done this dance before in the late 90’s with shrinkwrap software on the PC versus web applications, but I digress. If downloadable applications for the phone are funneled toward the phone browser like desktop applications to the desktop browser, that’s at least a few years out and will be heavily influenced by the current state of today’s apps.

Because my IPod was closer when I decided to play around with app development, I decided to set up to write apps for it first.  I was and am not interested in publishing to Apple’s App store, but since I have jail-broken the device, I just wanted to run my code on it alone.  I was surprised to find out that Apple has made no provisions whatsoever to allow app developers to use any sort of development environment outside of the Mac suite.  That is to say, Apple’s official stance appears to be that if you are interested in developing apps for IDevices (including just your own), you need to pay Apple $100 per year for membership, and, assuming you don’t own a Mac (I don’t — all of my computers run Windows or various flavors of Linux), you need to purchase one.  For those keeping track at home, that means that a developer would need to pay at least $700 for the privilege of enriching the device experience.

Apparently, I’m not the only coder whose reaction to this was something short of sprinting to the nearest Apple Store waving my credit card. This site offers five work-arounds for the limitation. Dragonfire offers a pay-to-play system that will set you back a much more reasonable $50. No doubt, there are others as well.

None of that really appealed to me, so I put my IPod back in its charging spot and pulled out my Android phone. The experience was a full 180. I googled “develop android apps” or some such thing, and the first site that came up was the one offering a free download of the Android SDK, asking me whether I wanted to use Windows, Linux, or Mac, and then providing detailed instructions as to how to setup the IDE and get started. So, I did all of the above and shortly had my first real, live app running on my Android phone.

Now, I have my own opinions about various technologies, companies, and practices, but the purpose of this blog is not to engage in the typical “fanboy” debates, proselytize, or anything of that nature. I am generally pretty agnostic in such discussions and willing to use whatever gets the job done. So, what I’m saying here isn’t a knock on Apple or their products, but rather an explanation of why I find this disparity between accommodating developers to be rather curious.

In the early 2000’s, I was fresh out of college and struggling to find a job in the .com bubble burst. Anxious to keep my skills relevant, I decided to write some code on Windows XP, using Visual C++ 6.0. Much to my chagrin as an unemployed kid, I learned it would cost me at least $300 that I didn’t have. My solution? I formatted half of my Windows hard drive and dual booted Linux, where I did all of my development with GCC and friends for free.

A lot of people went this route–so many, in fact, that Java took off, and Linux took a huge bite out of Windows’ domination on the server front. Nothing gets an operating platform moving faster than a lot of people creating software for it, and this ushered in a Linux golden age of sorts. Granted, Linux isn’t rivaling Windows for end-user desktops by any stretch, but it’s a lot more prevalent than it would have been had Microsoft not discouraged developers from writing software to run on its OSs.

Microsoft tacitly recognized its former stance as a mistake and introduced developer express versions of Visual Studio, allowed open source plugins to the same, and generally made developing Windows applications a pleasure rather than an expensive chore. As a result, C# has gone from being Microsoft’s cute imitation of Java to a bona-fide and robust development option with substantial market share.

Fast forward to the present, and Apple seems to be imitating Microsoft’s blunder. And that’s what I find curious. To make matters more interesting, Microsoft did this when they had a monopoly on the desktop. Apple is doing it without even a majority on the smart phone. I understand that the strategy might be to boost Mac sales, but at what cost? It’s now established that alienating developers can give a toehold to otherwise irrelevant competitors. So, what happens in the long term when you alienate developers while already having very viable competitors–competitors who, I might add, are welcoming them with open arms?

I personally find it somewhat annoying that I can’t write apps for my IPod without buying hardware or software, but I don’t presume to think that this matters to anyone but me. But, it doesn’t really even matter to me all that much. I’ll just write apps for the Android and use my IPod’s browser in the future. And so will others. Android’s marketplace of apps will grow as quickly and robustly as the wild world allows while Apple’s grows as quickly as Apple’s current cachet allows. And history has shown that an operating platform is only as good as the software written for it. As the developers go, so goes the product. And Apple, in my opinion, would be wise to stop letting the developers go.