A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.

This is true as it stands, but I think the main reason why Apple can keep a pace and a high standard of inovation is because of how they manage the Lowest Common Denominator. And iPhone OS with App Store is the crown jewel.

Technology vs. User Base

The lowest common denominator is always of interest when developing applications and services for the end user with profit interests. The lowest common denominator is what defines your user base, and it is a hard game of balance. Sticking to the newest technology will allow you to progress faster with more elegant solutions, whereas using a more commonly available technology will give you a larger user base.

So the lowest common denominator should be as high as possible, while still economical. With Java ME a bold effort to rise the bar of the lowest common denominator is the MSA JSR-248. An effort to give Java ME developers a guarantee minimum of features. A noble effort, but in reality up to a year ago only Sony Ericsson was MSA compliant, making the aged MIDP 2.0 the de-facto lowest common denominator for any developer targeting a the majority of Java ME devices.

The lowest common denominator for an average Java ME developer is the MIDP 2.0 spec from 2002.

iTunes as a Hub

Apple has a different situation, largely due to it's decision to use iTunes as the hub for all mobile devices, iPods as well as iPhones. All iPods and iPhones charges the battery by plugging in the USB-cable to your computer, this have some large but not obvious benefits.

Most notably Apple knows with 100% certainty that all users will have their devices on a reliable and controlled connection often, in most cases on a daily basis. As the users also use iTunes to synchronize their media, any other synchronization is not a hassle but rather a bonus on top of something they already requested.

Adding software updates on top of synchronizing media and data content through iTunes is just genius. It is a two click operation for the user, and as a result Apple virtually guaranteed that all iPod and iPhone users have the very latest software installed on their device.

Back-porting Software

Apart from the technology decision with iTunes as a hub, Apple have also made a business decision by always back porting their latest software to all iPhone OS powered devices. iPhone OS 2.0 can be installed on any first generation iPod Touch or iPhone, and with iPhone OS 3.0 this summer all three generations will be supported.

This back-porting model is the total oposite of almost all competitors, where instead new features are explicitly locked to the latest hardware in order to sell devices. So if the end users can get all the new iPhone 3.0 as a free download, why should they buy new hardware? Will not Apple loose revenue on unsold third generation iPhone devices?

In short term probably will, but the big win is the Lowest Common Denominator. Whereas the competition have a common lowest denominator of several years, almost a decade, Apple and all of Apple's third party developers have a lowest common denominator of virtually weeks.

Conclusion

With a simple software distribution model that guarantees the lowest common denominator Apple has guaranteed that the common lowest denominator is the current software, period. This allows Apple, and all third party developer creating applications and services for their devices, the luxury of discarding all effort for backward compatibility, and technological compromises.

Apple and we are allowed to innovate with full steam ahead.

Update: Buttons created with UIButtonTypeRoundedRect is a special case returning a private subclass of UIButton, this bugfix can therefor not safely be used with rounded buttons. Good news is that they already have a large nice touch area.

With Objective-C you can

In short the problem is that the implementation of the factory method buttonWithType: in UIButton do not respect subclasses, so it will always return instances of UIButton. This is bad since it is the only method available to use to get custom buttons. Without access to the source code for UIButton changes can not be made to the implementation, so in order to fix the bug in UIKit we must wrap the original implementation of buttonWithType: with our own method that applies the bugfix.

Adding a category with a new implementation will not work, since that would shadow the original implementation. What is need is some sort of AOP, and Objective-C gives us enough of this but under the name of method-swizzling.

We can intercept method calls to buttonWithType: by swizzling the implementation with the implementation of our own method. In Objective-C all method implementations are called by name, that name is what is know as a selector. By swizzling the implementations we can make messages with the old selector call our new implementation, and vice versa.

We do this by adding a category to UIButton with this class method:

#import <objc/runtime.h>
+(void)load;
{
  Method oldMethod = class_getClassMethod(self, @selector(buttonWithType:));
  Method newMethod = class_getClassMethod(self, @selector(__buttonWithType:));
  method_exchangeImplementations(oldMethod, newMethod);
}

The class method load is called once for each class and category as they are loaded into the run-time, and is the optimal place to add initialization code. Think of it as static initializer blocks in Java.

And that is it, apart from implementing the actual bugfix in our __buttonWithType: method.

A better bugfix

The fix I did in my previous post only worked if the new subclass of UIBUtton did not introduce any new instance variables. This is a limitation, and not quite as obvious to new users of our bugfix, so this time around the bugfix will work with any subclass.

The trick here is allocate a new instance of the correct subclass if needed, and copy over the instance variables. Implementation:

+(UIButton*)__buttonWithType:(UIButtonType)type;
{
  UIButton* button = [self __buttonWithType:type];
  Class buttonClass = [button class];
  if (button && buttonClass != self && buttonClass == [UIButton class]) {
    size_t oldSize = class_getInstanceSize([button class]);
    size_t newSize = class_getInstanceSize(self);
    button->isa = self;
    if (oldSize < newSize) {
      UIButton* newButton = [self alloc];
      memcpy(newButton, button, oldSize);
      button = [newButton autorelease];
    }
  }
  return button;
}

At first glance the first statement might look like a recursive call, but remember that we have swizzled the implementations so it will call the original implementation of buttonWithType:.

Also note that we must autorelease the new instance that we allocated, and that we must not release the original instance as that one is already owned by an auto release pool.

And that is how you go about fixing bugs in Objective-C for code that you do not have access to the source code for.

Here is screenshot from the management console showing 81 active CPUs and 23 GB free memory:

I tried some Scala actors which worked very well. By running some CPU intensive calculations I concluded that it scaled linearly up to the number of CPUs. No surprise, but very cool when you are running 80 threads at full speed! Also cool to see that Scala runs smoothly which means that neither Scala nor Azul does anything strange. Just pure bytecode.

Somebody tried to configure the Azul JVM in Eclipse and was able to run JUnit tests on Azul. We were also able to run maven without any problems.

We tried to allocate lots of memory. No problem there either, although we had to specify -Xmx10G or something. By default you only get 1.6 GB....

A colleague started tomcat, produced lots of garbage and tried garbage collection at 8 GB of heap. No pause! However, there was some synchronization problem with Log4j since all 16 CPUs had to coordinate their work.

We encountered two problems:

• xstream apparently had a dependency to Unsafe which is not supported on Azul
• the program must be headless, so no Swing

A quick rewrite later and we had generated a 64 megapixel mandelbrot calculated in parallel on 40 CPUs. The only problem was saving the PNG file which was a single threaded operation...