In the past few weeks, there have been disappointment after disappointment coming out from Apple for developers. While the iPad seems to have made a big splash news-wise, its release has been lightly overshadowed by some other announcements from Apple — the iPad will not allow Flash, Java or Silverlight content within the browser.
In the past, the world just ‘understood’ that the Flash player wouldn’t work on mobile devices — these are devices that are measured in inches, not GHz, and have to operate in very loosely connected environments (AT&T). We accepted this, but of course wanted it so we could experience the entire web.
With the introduction of the iPad, a “computer replacement” device, there really is no more excuse. The technology works, and has been proven. All of a sudden a press release goes out claiming Flash would shorten battery life, would make the device hot, and catch on fire, etc. The list goes on as to why Flash shouldn’t be included. As people started to get the devices in their homes, the reviews were consistently “this device would be much better if it had Flash” or “I miss Flash.”
Earlier this week, Apple dropped another bomb — Applications submitted to the store to work on the iPhone / iPad / iTouch cannot utilize gestures designed for their own applications. For example, the pinch to expand gesture is reserved for Apple created applications ONLY — new applications have been denied access to the store because they emulated these features. This is a huge mis-step in the UX world. In UX, there is a general feeling that gestures and human interactions should be consistant between applications. This is why Windows became so wildly popular — if you figured out how to use one Windows application, you figured out how to interact with most of them. Apple doesn’t want that the be the case — they want to have the “Apple” way, and the “other” way.
Finally, a draft copy of the new EULA that will be included with the iPhone OS 4 SDK was released. This EULA has some provisions in it that make some very large and sweeping restrictions on HOW you create your applications.
Up until now, the major restriction was that you could not execute any code that was not included and compiled in the inital application (for example, runtimes like AIR and .NET would not be possible). The theory behind this was about security — they didn’t want malicious code to be downloaded and run on the iPhone. This also is one of the blocks of having the Flash player on the iPhone.
However, the new SDK EULA now reads :
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).
Essentially, what this boils down to is if you want to create iPhone, iPod Touch or iPad applications, you have to use Apple’s developer’s tools, on Apple’s operating system, which only runs on Apple’s hardware. Oh, and you have to sign Apple’s NDA, pay for their certificate, and submit to only their store. Although there are other tools, better integrations with workflows, etc., you CANNOT use them if you wish to deploy you app to anybody (including yourself). Oh, and if you know another language really, well, you better learn THEIR language (from scratch) and kinda make the application work.
Apple has always been about their image, and Microsoft has always been about the developers. Microsoft’s theory has been that if you make the developers happy, they will make cool apps that people will want to use. Apple has taken the other approach — make a cool device which will drive the consumers to demand the applications and developers. Now, for some odd reason, Apple thinks they can punish their developers AGAIN (remember the 90’s?) for trying to serve consumer demand.
One other final thought — Some of the biggest critics of Adobe in Apple’s camp say that Adobe is lazy. They keep showing that the Apple versions of Adobe’s products are missing features, are clumsy or are less stable. I need to throw out there that in the last 10 years (MacOS to Snow Leapord) Apple has forced all of their application developers to migrate first from Titanium, to Carbon then to Cocoa, which for larger applications results in complete gut-jobs. For example, if you want your application to be able to address 64-bit memory space, you MUST re-write the app in Cocoa. How can Adobe be expected to keep both Windows and OSX feature parity if Apple is making them rewrite the app every few years? Microsoft has allowed us to keep writing to the same libraries since Windows 95 / NT, allowing the applications to grow and create NEW features.
Well, enough ranting — here is a video Adobe showed during their MAX convention this last year on their efforts to get the Flash Player to work on the iPhone :
QueTwo's Blog 