Send to Printer

gadgets

Another Take on the Apple/Adobe Thing

April 12, 2010 8:45:04.380

I like the dispassionate take that Jean-Louis Gassee has on the Apple/Adobe thing, and - when I sat back and thought about it - this made a ton of sense to me:

Who, in his right mind, expects Steve Jobs to let Adobe (and other) cross-platform application development tools control his (I mean the iPhone OS) future? Cross-platform tools dangle the old “write once, run everywhere” promise. But, by being cross-platform, they don’t use, they erase “uncommon” features. To Apple, this is anathema as it wants apps developers to use, to promote its differentiation.

He goes on to say that allowing cross platform tools leads to other people winning the platform battle and low margins. While I'm not so sure of that (it depends on how much value those tools bring to the party), I do get the baseline worry about having outside tools effectively control progression.

Years ago, back in the VW 2.x and VW 3.x era, the source control tool of choice for Smalltalk (across multiple dialects for a time) was Envy. It was available for VW, for Visual Smalltalk, and for IBM Smalltalk. What both Digitalk and ParcPlace noticed was that customers were mostly oblivious to vendor upgrades; they waited until a new version of Envy was available. The process of "Envy-izing" VW or VS was involved and invasive, and both vendors let OTI do it. Eventually, Digitalk decided that was a problem, and they shipped their product with a built in version control tool. After some initial angst from customers, the upgrade lag stopped. ParcPlace=Digitalk did the same thing (later) with Store, and again - after some initial angst - the customer base stopped lagging upgrades so much.

That's what Apple is worried about - say they allowed the new Flash cross compiler, and Flash ended up staying as the standard video system. Skip forward a bit, and Apple wants to ship OS 5 for the iPhone - but for reasons of their own (maybe they have a crush of other projects), Adobe can't get to updating the Flash project for, say, 6-9 months. The new release falls into dead air, and "everyone" stays on the old release. Apple gets pressure to keep supporting the old release, and things are generally slower.

So I understand where they are coming from. That doesn't mean I have to like it; but heck, it also doesn't mean that I (or anyone else, for that matter) has to write apps for the iPhone/iPad ecosystem. I said yesterday that this policy might be "a bridge too far" for Apple, but today? I'm not so sure.

There's a flip side danger for Apple though; it depends on how things play out. Consider:

Adobe has readily courted most other mobile OS designs and has ported Flash to Android, webOS and eventually Symbian and Windows Phone.

Right now, Apple is the clear leader in the mobile space, and they are helped (ironically) by Google's desire to get HTML5 (which, in part, will obviate Flash) as the standard for web content. But... what if these other devices end up, in the aggregate, winning? At that point, Apple ends up lagging, as too much content simply wouldn't work on the iPhone (but would on the other devices). If Google weren't pushing so hard on HTML5, I suspect Apple's chances in this battle would be a lot lower. As I write this, it looks like they'll win this battle.

Technorati Tags: , , , ,

posted by James Robertson

Comments

Re: Another Take on the Apple/Adobe Thing

[anonymous] April 12, 2010 14:28:33.448

Frankly they could have used their ability to reject apps based on behaviour. If the app didn't *feel right* ie use of cross-platform simulation widgets then Apple could just say it didn't adhere to their UI standards or was too slow, or something.

Re: Another Take on the Apple/Adobe Thing

[gpummer] April 13, 2010 6:28:51.573

Their (Apples) argument is true also for native applications (or libraries). It's only a question of how much items you have sold. Imagine a game library (or a gps car navigation app) with 100000+ sold items.

I see the point with the UI argument. But at the other side: why should the developer of the app not(!) support/update to the new api? He/She looses customers, risks that the application is withdrawn from the store and so on...

Quite frankly i don't understand the move from Apple. Imagine I would write a VW (or Pharo, ...) virtual machine for the iphone and I would use the objective c api. If the api chances I chance my vm code. Where is really the problem? I can write an ugly UI with native code and with a cross compiler/vm. I can write a not working app with native code also, this is very easy. I tested some time ago a pharo port for the iphone. It worked (ähm, a little bit unstable) and it had the native UI.

Apple has choosen to verify every application. So they have the choice on their own (to withdraw an application). Are they really frightened of a big developer? Hye, they are Apple!

 Share Tweet This