A little over a year ago, I was drawn to this marvelous device, named the iPhone. All the possibilities that it could bring opening up another outlet for me to develop applications for. Seeing the possibilities, like many developers, I ran out to the nearest Barnes & Noble and bought an “Introduction to iPhone Development” book. I diligently went though each and every chapter, getting acquainted to Objective-C and the iPhone development environment. Then it hit me! Do I want to be an iPhone Developer or a Mobile Developer? What happens when Android gains market share? What about Windows and BlackBerry? iPhone’s reign could only last for so long, and the pack is slowly creeping up.
The iPhone revolution placed blinders on us all, and many of us forgot the obvious. Remember years ago, when you would go to a site only to be greeted with a “Sorry we do not support your current browser, this site is optimized for IE 6″, you would be forced to close you current session on the non-IE browser and open up IE to view the site. What a pain! Eventually, javascript libraries like JQuery, and the adoption of CSS standards have made that less of an issue, although you still see this once in a while. The main difference however between the browser wars, and mobile wars is that browser all interpreted HTML and CSS, with only slight differences. Mobile phone native coding language on the other hand are extremely different. iPhone coding looks very different then Android, which look different the Windows Mobile. That means more resources need to be allocate on a project, costing the perspective client more money. Not exactly a smart investment, and unfortunately there is no “Export to Android” option in Apple’s XCode software.
To help put this in perspective, just imagine a client coming in, and being irate because a site you built for them only works in Firefox. I am guessing the conversation would go a little something like:
Client: Hey, I just checked out the site in Safari and it didn’t work
You: “Sorry, Safari is extra”.
Client: Extra? But i paid you to make me a website!
You: “No, you paid us to make a Firefox website”.
Client: “Isn’t that the same thing?”
You: “No that will require substantial more work, but we could give you an estimate on that”
Client: What about IE?
You: “Yep that will cost you too!”
Client: And Chrome?
You: Sorry we don’t have an in-house Chrome developer. We won’t be able to support that
Luckily I was not the only one to get this “ah-ha” moment, and I ran into multiple projects such as PhoneGap (@PhoneGap), Titanium (@jhaynie), and Rhodes Mobile (@rhomobile). Adobe eventually joined the party (disclaimer: I haven’t actually tried this yet) with the addition of the “Export to iPhone” option, which promises to include the rest of the mobile devices soon. I decided on PhoneGap, simply for the fact that it supported the most hardware (iPhone, Android, Windows 7 Phone, Windows Mobile, Blackberry, Symbian, Palm Pre, a few others), was written all in JavaScript/HTML5/CSS. PhoneGap creates a bridge between Objective-C and Javascript through WebKit so I could call native functions like the Camera, Vibrate, etc. on all the aforementioned devices. Being able to to use the same codebase for “ALL” devices is something that not only applies to my needs, but makes it easier to pursue a client, and pitch them an app that will work on as many mobile platforms as possible, giving them the highest return on investment.
There are scenarios where using a fully native solution would probably make sense, however even in those scenarios creating a fully iPhone solution doesn’t make sense. If you use something like Unity3D for high end game development you get iPhone, Android, and even Playstation exports. This holds true for other game development environments like Torque2D & 3D, and even Flash CS5.
Unforunitly all these options have entered a state of limbo, due to Apple’s new adjustment of it’s terms of service:
Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
No official word, but I highly doubt that PhoneGap will be affected by this, since it runs out of XCode and uses Objective-C to speak with JavaScript inside of Webkit, which seems to fall in line. I am pretty sure that Unity3D is also safe since you could open up a Unity3D project in XCode and see all the Objective-C. My problem is that there are other programs, specifically Flex/AIR and Mono that are very suited to do mobile development.
This by no means is this a gripe about Flash or any other program being left out, I’ve prided myself in using ANY technology that works and makes the most business sense for each specific project. Even if it means learning an entirely new development environment which is what I initially did by learning Objective-C. However, Objective-C made no sense for me nor my clients needs, if a project came up where Objective-C was needed then by all means I would code it in Objective-C. For now I am happy with PhoneGap. It does the job, and does it well, my only issue is that JavaScript isn’t naturally Object Oriented, which forces me to come up with solution to mimic an Object Oriented environment. This is what enables me to keep my sanity. It also allows me to make any adjustment, or enhancements to the PhoneGap code if the need arises, since i could easily fork the PhoneGap Objective-C code from their repository.
UPDATE (5/15/2010): Engadget reports that PhoneGap framework fine for App Store development
Browse Timeline
Comments ( 2 )
[...] This post was mentioned on Twitter by Alex Britez. Alex Britez said: I make “Mobile Apps” not “iPhone Apps” http://bit.ly/d5WTKF [...]
Tweets that mention I make “Mobile Apps” not “iPhone Apps” -- Topsy.com added these pithy words on Apr 12 10 at 4:21 pm
Melissa added these pithy words on 
