Posted by: camz | June 22, 2007

Tomorrow’s Apple

I’ve been thinking about Apple recently, just like everyone else many thoughts have been provoked by the upcoming iPhone release as well as the latest beta release of Safari. I don’t own a Mac, and I’m not a Windows fan either, my background is in embedded systems and software, I run QNX, Linux, and Windows on my network.

The most interesting things that I have noticed seem to have been missed by the mainstream, or at least I haven’t seen or heard a lot of commentary on the things I’ve noticed.

Embedded Apple
The first thing that struck me about the announcement of the iPhone was the mention that it is running OS X. The iPhone is certainly not running an x86 processor, or even a PPC one, it’s closer to the iPod than it is to a Mac, and the iPod uses an ARM processor. Apple has not officially revealed which CPU is powering the iPhone, although this ars technica article is rumored to be correct.

Which means that Apple has a version of OS X for ARM. That’s a big deal. A really big deal. ARM is one of the predominate CPUs for low-power embedded systems. Apple now has OS X running on three CPU families: PPC, x86, and now ARM. To make this even more significant, is that the development environment is self-hosted. Developers (at least the one @ Apple) can code, develop, build, test, and debug their applications on their Macs, and once they have it working, and assuming they’ve allowed for the difference in pixel resolution, can recompile for the iPhone and have a running application. Of course this doesn’t have to be for the iPhone, the Apple division that is responsible for developing the iPhone is actually a consumer products group, and the iPhone is merely their first product. There are countless consumer devices that Apple can build using the ARM processor and their new embedded OS X.

Yeah, I’m making a big deal of this. Self-hosted development represents incredible productivity when developing software for embedded platforms. Not only has Apple boldly entered a new tier of consumer devices, but it has done so by equipping itself with a huge time-to-market advantage over it’s competitors.

Carrier 180°
Apple will have done something remarkable when they release the iPhone, and surprisingly, it has nothing to do with the iPhone itself. The market dynamic between wireless carrier and handset manufacturers has been distorted by the carriers for many years. Typically the carriers will dictate to the handset manufacturer which features they want in a handset and specifically how they want to be able to control those features. This is the concept of a “carrier lock” on a phone. Consumers don’t like it, but by providing the ability to control features and/or lock them to the carrier allows the carriers to subsidize the handsets since they have a reasonable guarantee of revenue stream from the device. Control of this revenue is huge factor in how much a carrier will be willing to subsidize a handset. It’s quite common for carriers to offer some handsets at ridiculously low prices or even for free with fixed-term contract.

Apple turned this dynamic around 180° on AT&T when they chose them as the provider. Steve Jobs knows that much of the success of Apple products is a direct result of the “Apple experience”. The engineering of the UI usually makes an Apple product much easier to use than the competition, and when combined with the elegant and sleek physical designs Apple is known for, the result is very high customer loyalty. That loyalty makes Apples customers quite willing to pay a higher price, a nice payback for the design effort. So, it should come as no surprise that the experience is paramount with the iPhone as well. If Apple were to allow the carriers to dictate what features could be controlled, it would negatively impact the experience. As an example, in the traditional model, many carriers might restrict the WiFi capabilities to file transfer, and prevent its use for VoIP applications to protect their revenue stream from airtime.

With the iPhone, Apple calls the shots, and leaves everything enabled. This too is a big deal, it is a complete 180° change in the dynamic between device/handset manufacturer and carrier. The effects of this change are much larger than the effect of the iPhone in the handset market. I’ll definitely be watching that to see how it turns out.

Windows Target
The last thing I want to mention is in regards to the beta release of Safari for windows. Ignoring the bugs and other issues that numerous others have found and discussed, what caught my attention was how much of the Apple GUI was present. I will openly admit that I don’t know a lot about the application development environment on the Mac, so I could be dead wrong on my interpretation here.

Jobs has talked a lot in his keynotes about core animation as a key feature in OS X, which I found interesting in the context of Safari. Now, I know that Safari has little use for core animation when rendering web sites, since web sites don’t do anything with it. When I went to a site that was password protected though, the dialog box that appear for the login credentials had some slick 3D animation as appeared and disappeared. Certainly looked like core animation to me, but I could be wrong. Others have noted that the font rendering in Safari differs from Windows. I won’t get into the debate over whether it is better to honor the font design or the pixel grid, that isn’t the important part of this. The important part is that the graphics rendering in OS X is display postscript, of which font rendering is a component. Does the presence of the Apple-style font rendering indicate that the GUI API includes Apple’s display postscript too? To me, the (apparent) presence of core animation and the Apple graphics render engine are significant. Display postscript provides an excellent hardware abstraction layer for graphics rendering, the presence of Apple’s DP in a Windows application would mean a low barrier for ALL Mac OS X graphics on Windows. I really have to wonder how much of the Mac OS X GUI / Windowing API is now available in a DLL for Windows.

As I mentioned previously, this is the one thing that I have less confidence in due to my lack of knowledge of the Mac OS X application development environment. If I am right though, the existence of core animation and the Mac OS X GUI API & render engine on Windows makes the possibility of windows as an cross-dev target quite high. Apple already has a universal binary that can carry PPC and x86 binaries simultaneously, it wouldn’t take much to extend this to also include x86/Win32 as well.

Tomorrow’s Apple
All of these things together have Apple well positioned to dramatically change the landscape for embedded device/application development as well as windows application development. The appeal of being able to produce Mac and Windows software with only a recompile would be a strong incentive to bring significant numbers of developers to the Mac platform. Could tomorrow’s Apple be the next Windows dev platform? I don’t know, but it seems to be within the realm of possibility, and that will make the future of software development very interesting indeed.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: