Blog

Mac App Store

This week’s Apple announcements are interesting. First, there’s going to be a Mac App Store. Second, we got a nice, although short, preview of the next version of Mac OS X, Lion. And finally, the MacBook Air now comes with a higher-resolution display. But let’s talk about the App Store.

The Mac App Store seems like a good idea to me, at least in principle. As it won’t be the exclusive way to distribute applications, it won’t break other distribution channels. But it’ll make it easier for users to discover and install applications, and both tasks surely deserve improvements. Surely, the App Store rules are going to disqualify a lot of the currently existing applications from being listed, but even for the remaining ones that can be sold according to Apple’s rules, practical problems might arise.

One of those problems is going to be the licensing scheme. Developers are currently responsible for the licensing of their application. Today’s applications generally contain code that check if they have a valid license, which allows the developer to create license terms that are a good fit for its target audience.

With the App Store, the OS itself is going to take care of those licenses. While this is nice, it means that if a developer wants to continue to offer his application outside of the App Store, he’ll need to maintain two different versions: the App Store edition with no license code check, and the regular edition that can be distributed by other means and that requires a serial number or something similar.

Maintaining two versions is not terribly complicated, although it’s a little more hassle. But why would a developer bother about this instead of only publishing on the App Store? One reason is that he’ll probably make more money by selling in his own store. As low as you might find the 30% share Apple takes on App Store sales, selling on your own online store remains a lot cheaper. For instance, if you’re using Kagi, Fastspring, or Esellerate, they will manage your store website, will handle all the payments for you, and will only take a share of about 10%. All you’ve to do is write a serial number generator and integrate a serial number checker in your app. Sure, the App Store will have more robust DRM and list your app in its catalog and be more user-friendly, but is this worth the remaining 20%? If I put an application on the App Store, I might price it higher there than on my online store, as I’ll be able to sell it for less on my store and still make the same amount of money on each purchase.

A second reason for a developer to maintain his own online store is independence. As the iOS App Store has shown, you can never be sure Apple won’t decide to remove an application from their store. What’s more likely to happen though is that the developer might want to add a new feature that Apple doesn’t like. If that happens, likely the feature will make its way in the regular edition of the app, but not in the App Store edition. App Store customers lose again.

So while it makes sense for a developer to sell an app on the Mac App Store, if only for the visibility, it’s not necessarily a good deal for the consumer to purchase it from there. Stricter DRM combined with the possibility that some features were crippled to accommodate Apple’s restrictions and the likelihood of the price being higher; it’s probably best to check the developer store’s first.

There’s one exception however: if you don’t trust the application’s developer, perhaps you’d trust better the Apple-verified version. On the other side, if you don’t trust the developer, would you use its software in the first place?

Javascript Off

I’ve been browsing the web with Javascript turned off more and more frequently lately. While to a web developer this might look like I’m crippling the user experience, to me most of the time I find it more pleasurable. Even though I’m on a Core 2 Duo, websites are noticeably faster with Javascript turned off.

Javascript is blazing fast these days, and all browsers pride themselves about how fast they are at running Javascript. But even though Javascript can run fast doesn’t mean every script is well written and will run fast. Moreover it doesn’t affect at all the latency associated with loading more script files and the script performing additional network requests to do various tasks. For speed alone, this is worth giving it a try.

A second advantage is less tracking. In the absence of Javascript, the only way for a website to track you is with plain old cookies. With Javascript turned on, websites have so many way to track you. And it’s so tricky to get rid of those identifying tags; try erasing an evercookie for instance. I’m not paranoid, but sometime I value my privacy and I don’t want an advertising company to know about almost every page I’m visiting. With Javascript turned off, it’s one less bother.

The big disadvantage is that, for some websites, Javascript is pretty much required. You can’t view a Youtube video without Javascript for instance, even with the HTML5 player turned on. In my opinion, that’s just bad web design; Javascript shouldn’t be required to browse any website, except when the content can’t exist without scripting (this game for instance).

So when I encounter a website where it is worthwhile to activate Javascript, I hit Command-Comma then check the Javascript checkbox in Safari’s preferences, and I repeat this in reverse to deactivate Javascript when I leave. It’s certainly trouble, so for some sites I don’t bother and just leave.

And it’s pretty much the same story for Flash.

D/Objective-C: hit a dead end, start anew

About three years ago, I was working on a pet project of mine which consisted of using the D programming language’s template capabilities to create a fully transparent bridge with the Objective-C runtime. It worked fine: objects were transparently exchanged between the two worlds and it was quite easy to write D bindings for Objective-C classes. It wasn’t too long however before some flaws started to appear…

The Flaws

The first problem was that it was awfully slow to compile anything using the bridge. While I did manage to reduce the compile time by a factor of 2 or 3, it’s still not fast. But that’s not a fatal flaw.

A second problem was the small inefficiencies everywhere. Normally, a compiled Objective-C object is stored in a particular way in the generated object file, and the dynamic linker and the Objective-C runtime automatically take care of initializing things. But I can’t do that from D, I need to initialize everything at runtime, and lazily to avoid the problem of circular dependencies between module static constructors. There’s a lot of code for that in the bridge.

As a consequence of the lazy initialization, bindings sometime need to be initialized manually in advance in some cases. This is the case before loading a nib file for instance. This is less than ideal.

But the real show stopper is the size of the generated code for the bindings. The system I created needs to generate a lot of code for each and every one of the functions and classes you define bindings for. This makes the final executable awfully big (and might also explain in part the slowness while compiling). The small test application included with the bridge takes about 60 Mb of code, thats for something that’d be only a few kilobytes when written in Objective-C.

This wasn’t the case at first. This bloat appeared as I added bindings for more and more classes in Cocoa. It is a real problem because no one in his right mind will want to ship a 60 Mb application that contains so much binding code that stay unused most of the time. A solution could be that everyone would have to write bindings that only contains the classes and methods he needs, but this is of rather limited interest.

A New Approach

So how to make the bindings more lightweight and without this lazy initialization nonsense? I see one way: make the compiler aware of the Objective-C object model. If the compiler becomes aware of what is an Objective-C object, how to call its methods, and how to emit the object code for it, it’d become as good as a real Objective-C compiler with the only difference being the syntax used would be the D syntax.

So that’s what I’ve been playing with this last month. I played with the source of DMD and tried to make it generate code à la Objective-C.

There’s only one thing that works right now: declaring extern (Objective-C) interfaces and calling functions on them. It works like this:

extern (Objective-C)
interface NSObject {
    NSObject description();
}

Now, when you have an instance of the interface NSObject in variable object, you can write object.description() and it’d be equivalent to writing [object description] in Objective-C. Internally, it is transforming the call to objc_msgSend(object, @selector(description)). I’ve made compiler put the selector in the __OBJC,__message_refs segment where it automatically get registered with the runtime while loading the executable. That’s exactly what does the real Objective-C compiler, and it’s much better than generating code to register the selector lazily at runtime.

For methods with more than one argument, the compiler can’t deduce the selector’s name from the function name since the selector is generally split in two or more parts. So I had to come with a syntax to bind a manually-specified selector with the function. Here’s what it looks like:

extern (Objective-C)
interface NSString {
    void getCharacters(wchar* buffer, NSRange range) [getCharacters:range:];
}

And that works too! With this, calling string.getCharacters(b, r) emits the same code as the Objective-C method call [string getCharacters:b range:r].

All this is great, but still incomplete. As it stands now you need to somehow get a pointer to an Objective-C object, cast it to the right interface and call functions on it. It’s definitely not bad, but it’s not very useful in itself either. There’s a lot more work to do before Cocoa gets usable with D.

But the ground work is there, so it’ll be easier to continue. It’ll certainly be at couple of months before it works right, more or less depending on how much time I can devote to this project. I want the final result to allow mixing Objective-C and D objects pretty much seamlessly, including subclassing Objective-C objects.

If you’d like to use D with Cocoa on the Mac, I’d be pleased to hear from you. And if you want to encourage me further with this, you can make a donation: if I get enough support it might get easier for me to put more time advancing all this.

August Sale: 35% off Magic Launch

One thing you realize when you’re selling your own product is that it doesn’t provide a very stable income: one day you can make 20 sales and the next day zero, for no apparent reason. Even the monthly average varies significantly from month to month. But during the summer, sales have slowed significantly. So I’ve been thinking about doing something to help it.

As an attempt to boost sales this summer I’m slashing 35% of Magic Launch’s price. This offer is available to everyone. No coupon code, no limit on the number of users on the license. Not even the need to know about the offer in advance: you just go to the Magic Launch purchase page and you get the reduced price. This will last until the end of August.

Perhaps it’s to be expected that sales will slow down with many people taking their vacations during summer. I certainly hope it’s a temporary thing and not that no one want Magic Launch anymore. I know too that some of you are waiting for a promotion to make their purchase. If you’re one of those, now is your chance.