Hopefully Benjamin Disraeli will posthumously forgive me for the major abuse of his quote (made famous by Mark Twain), but the fine folks over at the Omni Group gave us all a sneak peek into some very interesting data they’ve been allowed by users to collect on various details of the operating system their applications run on.
Even though this is a very rough snapshot of the Apple landscape — OS X users who have at least one installed Omni Group application that has checked for updates and allowed data to be collected — it does provide some fodder for discussion and analysis.
Which Cat Rules?
The Omni folks seem to have an even spread of Tiger and Leopard users. While we do not have hard numbers to go with the data, it would seem that any developer who makes a calculated decision to develop a Leopard-only application needs to realize they are targeting a fraction of those who upgrade or just those who have purchased new systems.
The most reliable and recent official information I could find (quickly) noted that Apple’s Leopard update penetration was at 19% by end of March 2008. Since the chart does not distinguish between upgraded systems and newly purchased ones with OS X Leopard pre-installed, it is interesting to see that there is a convergence, which would lead me to believe that we are seeing a slowdown in Leopard migration and an small, steady increase in new systems with Leopard.
This next chart was very encouraging (as I tend to care more about security than anything else) since it shows that Mac users are pretty good at updating their systems within a small delta of minor versions being published by Apple (at least when it comes to Leopard).
If there is any indication of whether the Omni data is more skewed to a certain part of the Mac user-base, it was this next chart. I am not ready to believe that 50% or more of all Macs are now Intel-based, however Apple has had great sales data to report quarter-after-quarter. Even if we take the 50% at face value, I think it shows that the Universal Binary is not going away any time soon and that makers of Intel-only software have to fully understand their market or have legitimate constraints for such a decision (e.g. VMware or Parallels). It also stresses the need for developers to test their creations on as diverse of a platform spread as possible.
I was surprised to learn that the majority of users in this subset of Omni customers also works with only one display and this makes me wonder if the data takes into account the built-in display on Apple’s mobile systems when collecting the statistics.
There Has To Be A Better Way
Atomic Bird, makers of (among other utilities) Macaroni — a handy system maintenance utility — has also published some other statistics compiled from their use of the data collected via the Sparkle auto-update framework. There is some correlation and some divergence in the data as their information shows a clear migration from Tiger to Leopard. It may be that their user-base is just more likely to have updated, especially since they are likely to care about things like that given the types of products Atomic Bird makes.
Because both examples are skewed to a particular software vendor, it would be very interesting to see more aggregated statistics from Sparkle or even the new Google Update Engine (once use of it takes off in the OS X developer community). Either project could allow for application-specific information to be stripped and system/component information to be forwarded to a central collector. Either service could then give some information away for free and possibly monetize their service by providing more thorough data to developers who want to make serious decisions as to how to proceed with development choices.
There would definitely be security and privacy concerns with an aggregated service, but with proper code review/auditing it should be easy to verifiably allay consumer and developer fears. Ultimately, the availability of such information would mean the creation of better software and be a significant help to many independent Apple developers.