All the more space elsewhere then . . .

Apple's new not-quite-a-computer platform seems to incorporate a lot of decisions that readers think are limiting. That's just going to make it much easier for Android, WinPhone7 etc. to sweep into first place leaving Apple as the small time wacko you always wanted them to be, no?

It's far from clear that SugarCRM is banned anyway.

What's actually happened is that iPhone OS always had immigration controls. Adobe wanted to wheel in a few million Flash developers, change iPhone into Flashphone and get a free, functional Flash marketplace for small developers. Apple said NO, NO and NO. So Adobe thought they'd found a loophole in the rules and prepared a fleet of busses to drive their hoardes in. Two days before launch, Apple passed emergency legislation to block them. What part of NO hadn't Adobe understood?

A variety of smaller busses that used to come in to iPhone land also appear to be blocked by the legislation. I'm sure it will get sorted out.

What this is actually about is making and keeping the WEB open. Now that dependency on Internet Explorer has been defeated, that means removing the dependency of video and advertising on proprietary Flash. And Apple is the only one strong enough to do it for us. Thank you Apple, from me at least; sorry about the ingrates.

Haha

Yes, perhaps he may have to hire a developer for each platform he wants to 'support'. Firms seemed to be able to do this back in the 80s, when computers were far less common.

I'm reminded a little of Bernard Matthews and his threat - ages ago - to leave the country if a minimum wage was introduced - 'I can't afford to pay it' - really, Mr.Matthews? Can't or don't want to.

And the same thing strikes me with most cross-platform development - investors like it, because it saves them money. As a consumer, the results mostly suck, because they tend to be done with pretty much contempt for the end user - Huawei's Mac app, for instance, is written in Java, but hasn't even bothered with the one-line switch required to put the menu at the top of the screen like a native application. That is one line of code required - provided you knew you should and could do it - which most Java developers don't - i.e. you still actually need developer/designers who understand your target platforms, and your x-platform tool of choice.

Instead, what's more typical is firms want to write on one platform and for it to 'work exactly the same' on others. (How many people here who work in software development even have a single Mac or Linux client within the organisation?).

As it happens, I think this story may already be old, anyway - Apple have reviewed and accepted at least one of these toolkits as OK (I just can't see which one, but I thought it was Appcelerator).

I wonder if toolkits that convert down to C code, which is then compiled by the XCode toolchain are allowable, while the issue with the Flash approach is that rather than converting Flash-to-C and then compiling the C, it's doing it's own compilation and linking in a translation library?

Which would also give Adobe a route out - converting byte-code back to unreadable C code, and providing the source of the library.

That would make a lot of sense - if Apple want to reserve the right to bring in a higher powered Intel based iPad model, or a custom CPU, or go 64-bit - then having their development community dependent on third-party binary blobs would be a bad idea. (Particularly given Adobe's history with OS X and even 64-bit Windows and Linux support).

But if those libraries are also compilable portable source, then there shouldn't be an issue.