Score:5, Offtopic

I'll admit that this one's grey area, but Apple posts data (about apps on the iPhone) on the public Internet. A user may wish to use that data in a more efficient manner, so they install an app to do it for them.

Oh, wait, they can't, because that app is banned, because it uses that data that Apple has posted on the public Internet.

As the App Rejections blog points out, this is kinda screwy. Apple can't stop screen scraping on the public Internet (robots.txt is voluntary, too,) but they own the iPhone platform, and can control anything that goes on on it.

Screen scraping is a valuable tool for getting at data when a site gives it to you in a form that's not really usable to filter on that data. Sure, it's sometimes abused, but in this case, it can only benefit users, and can't harm Apple.

Source: App Rejections

This isn't news either, but I'm posting it anyway.

Many have made the argument that it's OK if Apple makes a walled garden, because there's always other choices.

The problem is when Apple's walled garden is wildly successful, competing platforms may switch to a walled garden model. And, Microsoft, which is quite often accused of copying Apple at every opportunity, well, they're copying Apple on this one.

Windows Phone 7 will be a walled garden, too. Sure, there's some Windows Mobile 6.5 devices out there, and they'll continue past Windows Phone 7's release, but let's face it - 6.5 is crap.

And, AT&T's first Android device, the Motorola Backflip, requires some hacking to get apps from outside of the Android Market installed. Granted, they didn't do a good job of securing it, but they did try.

Arguably, this is more of a "why Microsoft and AT&T evil," but this points out why Apple's walled garden is dangerous for everyone, even if you're not an Apple customer.

Source: Engadget

Today's "Why Apple is evil" entry deals with something that's not quite news, but I wanted to cover it.

Apple is requiring that applications originally be developed in Objective-C, C++, C, or JavaScript (executed by Safari's JS engine.)

This is intentionally used as a way to prevent certain companies from making tools for the iPhone platform.

Despite what you might think about Adobe (honestly, my opinion is that they're the vile scum of the Internet, and Flash is worse than IE6, because at least there's alternatives to IE6,) this is still rather troubling - the market should push Adobe out with superior solutions, not anticompetitive actions, especially when those anti-competitive actions have collateral damage, and severely negatively affect developers. Apple is now mandating the development process, not just what the program does.

Of course, in classic Apple fashion, they're doing things horribly inconsistently - other development frameworks that clearly violate the agreement are being explicitly allowed, showing just how anticompetitive this is.

Waging a personal war is one thing. Waging a personal war using your developers and users as pawns is another.

Source: many, but I decided to post about this today because of The Register

You're probably thinking, "what? How can that be? Android has to be the most open, it's open source, right?"

And you'd be right... until you get into actual Android devices that are for sale. Other than the Google Dev Phone 1 (which has some other restrictions,) all of the devices are locked down at least somewhat.

There is one exception to my point - in one or two ways, Palm OS is more open than Windows Mobile. However, Palm OS is irrelevant nowadays, but I'll include it in the comparison anyway.

So, here goes, a comparison between the major smartphone platforms, in terms of openness. Openness will be compared on the following metrics: openness of source code, ability to run unsigned applications without jailbreaking, difficulty of getting applications signed if needed, presence of a "kill switch" for applications, cost of developing for the platform, and ability to manipulate the device filesystem from a user perspective (not an application perspective.)

I'll note that I'll use worst case scenarios for difficulty of signing.

In the case of Android, I'm using real world implementations, not the Google Dev Phone, and not Android distros on phones that didn't ship with it.

Palm OS
Source code: Closed
Unsigned apps: Allowed, no support for signed apps
Difficulty of signing apps: N/A
Kill switch: None
Cost of developing: Free (prc-tools)
Filesystem: Fully accessible

iPhone OS
Source code: Closed
Unsigned apps: Disallowed
Difficulty of signing apps: Difficult (all apps must go through inconsistent and restrictive approval process)
Kill switch: Yes
Cost of developing: $99 (SDK, more money for a Mac if you don't already have one)
Filesystem: Inaccessible

Blackberry OS
Source code: Closed
Unsigned apps: Disallowed
Difficulty of signing apps: Easy (purchase a signing key from RIM one time)
Kill switch: No?
Cost of developing: $20 (signing key)
Filesystem: Restricted access (it's also not actually a filesystem, but I digress)

Android
Source code: Open
Unsigned apps: Allowed, but not by default
Difficulty of signing apps: Easy?
Kill switch: Yes
Cost of developing: Free
Filesystem: Inaccessible

Symbian
Source code: Open
Unsigned apps: Disallowed (workaroundable, though)
Difficulty of signing apps: Self-signable for partial access, free rubberstamp for most access to one device, may be difficult (but documented) for full access
Kill switch: No?
Cost of developing: Free for self-signed, $20 for Symbian Signed Express, >$200 for Certified Signed, more for full access
Filesystem: Restricted access?

webOS
Source code: Partially open
Unsigned apps: Allowed through developer mode, normally signed apps required
Difficulty of signing apps: Unknown as of yet, should be easy to moderately easy
Kill switch: In development
Cost of developing: Free
Filesystem: Inaccessible?

Windows Mobile
Source code: Shared
Unsigned apps: Allowed (supports signed apps, some devices could theoretically require signed apps)
Difficulty of signing apps: Must purchase certificate from a CA, after that, easy
Kill switch: No
Cost of developing: Free for unsigned (although MS would prefer you buy VS,) $350 for Mobile2Market from Verisign (1 publisher ID, 10 content IDs) for signed, may be less from elsewhere
Filesystem: Fully accessible

If I'm wrong anywhere, let me know.

But, it is a sad, sad day when MS makes the most open OS in a field, and two of those OSes are Linux-based, and a third is open source.

That's my cell phone running the Apple ][ version of Lemonade Stand.

Yes. My cell phone. Running an Apple ][ app.

How?

AppleIIGo.

Pretty easy to use... download, extract, put disk images in the Disks directory, and (on Windows or Mac) run the relevant script, or enter the following command on Linux (taken RIGHT from the Windows CMD file, just with proper slashes instead of backslashes, and cp instead of copy ):

java -jar Tools/AppleIIGoPacker.jar
cp AppleIIGo/bin/AppleIIGo.jad AppleIIGo/AppleIIGo.jad

That cp operation isn't necessary if you use Sprint - and if you do use Sprint, upload it to your phone using Rumkin's Phone Uploader. (Upload the AppleIIGo.jar (not the jad) file from the AppleIIGo directory.)

Enjoy!