3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. 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).

What this means is that the Flash-to-iPhone compiler feature of the upcoming Adobe Flash CS5 is in jeopardy. This fact is especially upsetting for me because I would love to be able to making iPhone apps using Actionscript. I'd like to be able to build on app for all platforms. The agreement would also affect MonoTouch, which allows C# and .NET applications to be compiled for the iPhone. Titanium, PhoneGap, and Rhomobile may also be affected.

Essentially, Apple is controlling developers even more than they already have been by trying to screw over Adobe. I liken Apple's behavior to the food industry giants in the movie Food, Inc. The farmers are like the developers. In the movie, the corporations began controlling the way farmers raised their animals (chickens, cows) and their crops (corn, soybeans). Chickens, for example, have to be fed large amounts of growth hormones so that each chicken can produce more meat. Thousands of chickens are squished together in huge chicken houses with no room to do anything but eat. Everyday a few chickens die from the harsh environment. Some of the farmers don't like what is happening but they can't do anything about it because these food companies control the industry.

Apple isn't putting growth hormones in our chicken, but it is beginning to control developers more and more. I fear that since the iPhone market share is going to continue to grow, Apple will be able to be more and more authoritarian with its App Store policies. Hopefully if enough people speak out against this Apple will change its agreement, but I don't know how likely that is.

I've been playing around with the technology a bit. First off, it was quite a hassle setting up the development environment for the Android version of PhoneGap. The instructions page is huge! Also, the way you build and deploy an application is cumbersome because you have to type out a command in the command line that needs information like the location of the Android sdk. Then, once the project is built, you have to import it into Eclipse, whereupon you modify it some more before deploying to a mobile device.

I have a Droid, so I can test out the app on a real phone as apposed to an emulator. I can see that this technology can be extremely useful if you are trying to build and app for as many different devices as possible, but I also think that the "feel" of the resultant app isn't up to par with a normal mobile app. It feels as if you're on the web in a browser. For instance, on my Droid, in the web browser, web links show an orange border around them when clicked. The same thing happens in the PhoneGap app. I don't know if there is some way to disable that, but regardless I also think that the UI for a PhoneGap app would not look like a normal app's UI. In order for the app to look like an Android or iPhone app, you would need to customize the interface for each phone. In addition to these problems, PhoneGap does not currently support the complete functionality of all three mobile platforms. On Android, there is no contact support, for example.

What I'm saying is that this technology is too young for developers to begin migrating towards it, though I do think it is a step in the right direction. It is quite inconvenient building three separate applications with three different languages, so PhoneGap gives me hope for an eventual pseudo-uniformity among mobile platforms. We'll see if in the future, PhoneGap can change my mind.