Blog

Collateral Damage

The iPhone 4.0 SDK brings a lot of new features to the platform, it also brings a new iPhone Developer Agreement. John Gruber from Daring Fireball points out to the updated section 3.3.1 of the agreement effectively bans everything not originally written in C, C++ or Objective-C:

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).

It clearly states that you cannot do iPhone OS development with the language you want. This rules out Adobe’s near-ready Flash compiler — which was probably the point — but it also bans the use of other languages in games and applications that would benefit from it. Basically, Apple is telling us what language to use not only for the front-end, but also the back-end of our software.

Michael Tsai writes it best:

Leaving aside the question of whether it’s reasonable to ban cross-platform applications rather than let customers decide whether they’re useful, I worry that this new regulation will also affect native applications. There are a variety of reasons that a developer might want to leverage other languages (either at build time or runtime) for code reuse, libraries, or development speed and power. Consider, for example, an AI or game engine written in Lisp that compiles down to ARM assembly or C.

I’ll also have to agree with Hank Williams about this:

Developers are not free to use any tools to help them. If there is some tool that converts some Pascal or, Ruby, or Java into Objective-C it is out of bounds, because then the code is not “originally” written in C. This is akin to telling people what kind of desk people sit at when they write software for the iPhone. Or perhaps what kind of music they listen to. Or what kind of clothes they should be wearing. This is INSANE.

Steve does not want to allow Adobe’s tools to be able to generate compiled code for the iPhone. But with this additional twist he doesn’t even want Adobe to be able to generate objective-C which is then compiled by Apple’s tools. The ridiculousness of specifying the manner in which one writes their code is hard to understate.

Insanity at its best. If I need to write a parser for my application, can I write it in Lex/Yacc? No, because even though those tools just generates small snippets C code from a grammar it wouldn’t be originally written in C. What about regular expressions? What about routines optimized using assembler code?

And how will they enforce that? Given proper inlining in the compiled code, they can’t really tell in what language you’re working. Sure, in some cases it’ll be obvious, but in many cases it’ll slip easily.

My impression is that rules of this kind are only there to give a semblance of coherency. We already know Apple reserves itself the right to refuse any application for whatever reason they like when you submit them, and to remove them even after they were accepted. A rule that outlaws practically anything even though it’s not coherently enforceable is a great way to justify arbitrary decisions without having to publicly acknowledge the real reason.

Magic Launch 1.2, Macword Review, Volume Pricing

This week has been full of news concerning Magic Launch. Tuesday, I released version 1.2 with two new criteria. The same day Macworld published a review by Rob Griffiths, giving Magic Launch a score of 4.5 mouses out of 5. And today I’m introducing a better thought and (much) less expensive volume pricing.

Magic Launch 1.2

Version 1.2 brings a new criterion that let you create a rule that will open a file in an application only when the application is already open. This can be very useful to make sure your files won’t launch heavy applications accidentally.

Another new criterion let you check the access path of a file. With it you can check if any part of a path contains a specified component. For instance, to match a file contained in any folder named “Generated” in a certain application, you can use the criterion like this:

access path  contains  /Generated/

One last mostly unpublicized but certainly welcome change is the removal of the system confirmation prompts about opening Magic Launch Agent for the first time when first double-clicking a document.

Macworld Review

Rob Griffiths from Macworld wrote a nice review about Magic Launch this Tuesday. Skipping to the conclusion, he says:

In my testing, Magic Launch worked very well, used no measurable system resources, and gracefully solved the problem Apple introduced with Snow Leopard. It’s well worth its cost if you spend a lot of time working with the “generic” file types—text files and images, especially—most affected by this change.

I would say it the customizable rules also solve problems that never really had a solution before. But it’s certain that for someone like Rob who feels aggrieved by the new rules about opening files in Snow Leopard, being able to restore the behaviour using creator codes is probably the most wanted feature, and apparently Magic Launch fixes that very well.

All in all, Magic Launch got 4.5 mouses out of 5, a quite good rating. Thank you Rob.

Volume Pricing

I got some comments lately about how Magic Launch can come quite expensive for potential consumers wishing to use it on many people desks. Previously, the only volume pricing option was a site license priced at about the same price as a 50-users license. This left no option to get a good deal if you had, say, 50 users.

The new volume pricing is much more thoughtful. It progressively reduces the price as the number of licensed users increase. The savings can be quite dramatic. For instance, if you purchase a 20-users license, you get a 50% rebate (per user) over the single-user license. You can look at the exact pricing on the purchase page by clicking the “volume pricing available” link above the quantity field.

With this I hope Magic Launch becomes a better options for small departments or companies who wants to equip everyone with Magic Launch.

D for Xcode 1.2

It’s been a while since DMD for Mac OS X has been available, but I haven’t made an official release of D for Xcode to support DMD. Today I’m fixing that.

So D for Xcode 2.1 now supports DMD. It comes with an installer package that does the following:

• Install D plugin for Xcode
• Install Xcode file and project templates for D
• Download and install latest version of DMD 2.x
• Download and install latest version of DMD 1.x

This means that someone can just run the installer and immediately start writing and compiling D code within Xcode, a nice improvement on the previous state of things. It’s using DMD 2.x by default, but there is no problem installing both versions at the same time and changing the default if you prefer working with version 1 of the language.

More details and some screenshots on the D for Xcode website.

AACS and planned obsolescence

Customers generally don’t like planned obsolescence, although we’ve still learned to see this as a normal part of most product life-cycle. There are many ways to plan obsolescence, but hardly any goes as far as the Blu-ray format is pushing it to obsolete your old HD TV. If you have a Blu-ray player connecting to older HD video equipment, you might start to lose its HD capability some time next year (depending on the goodwill of the content distributors).

The “problem” lies with AACS, the mandatory digital right management system built into every Blu-ray player, which includes a plethora of ways to cripple the video signal so that you only get standard definition output. I quoted the word “problem” in the last sentence because, obviously, those who created AACS only see that as a feature, a feature aimed at preventing illegal copies (as if that will work!).

That “feature” obviously has a cost. Every manufacturer has to implement a decryption system to read the content of a Blu-ray disk. The decryption keys are tightly kept secret by the AACS licensing authority, which forces manufacturers to enter in an agreement where the licensing authority can dictate what each players must do and must not do.

As part of the enforced rules, Blu-ray players are required to obey the image constrains written on the disk. Image constraints can forbid the player from sending an HD-quality signal to any non-AACS-encrypted output. This means that if your HD TV is connected through component video out (YP_bP_r), or if your hardware isn’t able to negotiate a proper AACS-encrypted channel over HDMI for some reason, you won’t be able to see that disk in high definition.

The impact though this day has been mostly null, because disk manufacturer have been forbidden by AACS from including these strict image constrains, that is, until 2011.

So in 2011, owners of Blu-ray players will become part of a live experiment where some newly-released disks might or might not play in HD depending on the a decision from the disk producer combined with some unpredictable characteristics of their various pieces of equipment and the way they’re wired together. From a machiavellian point of view, I guess it’s going to be fun to watch if the content producer decide to go with it. From a consumer point of view, it’s a little scary.

There are many other situations where AACS mandates crippling the video quality or even completely prevent the disk from being read, but this one is probably the most important issue in the short term.

Reference

• 2010: The Year AACS and HDMI Kill Off Component Video, Clint DeBoer, Audioholics