Yours truly speaking at Google I/O 2010

Skip ahead to 19:00 for the good bits (me)...

http://code.google.com/events/io/2010/sessions/connecting-enterprise-apps-docs-sites.html

De-emphasizing Mac OS at WWDC?

WWDC 2008:  Offered sessions on transitioning Mac developers to iPhone.  Makes sense.  iPhone OS was a new platform with few developers at the time - why not throw the Mac developer community at the iPhone.

WWDC 2009:  Offered sessions on transitioning iPhone developers to Mac.  That was a surprise to most, but again makes sense because during the previous year the Cocoa Touch developer community exploded and why not throw a few of them back to the Mac.

WWDC 2010:  Evidently it's about iPhone OS.

But is it?  Clearly not everyone is happy about Apple's strong iPhone OS emphasis at WWDC this year.  But maybe it isn't about iPhone OS maybe it's about Cocoa Touch?

Cocoa is the development frameworks for Mac OS.
Cocoa Touch is the development frameworks for iPhone OS.

Is there a difference between iPhone OS and Cocoa Touch?  Hell yeah there is.  There's no reason Cocoa Touch can't be part of Mac OS.  Cocoa Touch is a damn fine environment to develop software for devices with a multi-touch screen interface (by 'damn fine' I mean nothing else comes even close).

Let's not assume that multi-touch screens are exclusively for this new 'mobile era'.  Sure that might be the driver of multi-touch screens, but I can't see them staying there.  If we get a multitouch screen on a Mac, then we should get Cocoa Touch too - and all those wonderful iPhone developers have a place on the Mac.

Don't think a multi-touch screen has any business on a Mac?  Matt Gemmell's dad seems to think it does

Apple throwing the developer community behind iPhone OS might just be a front to transitioning us to developing in Cocoa Touch - for iPhone, iPad and Mac.  Glory glory hallelujah.

For a more in-depth analysis see my previous post on UIKit in 10.7

UIKit in 10.7?

Disclaimer: The following is nothing but pure speculation...

UIKit in 10.7 would mean an iPhone like environment on a touch screen Mac - even iPhone apps themselves. Seems nuts, but reserve judgement until the end.

First, a little background in Mac OS X / iPhone architecture...

Mac OS X and iPhone apps share a common underlying framework - Foundation. However, each platform has it's own application layer.

iPhone OS has UIKit = CocoaTouch

The UIKit framework contains the Application layer for iPhone apps. This includes the visual interface and user interactivity bits that makes the iPhone the iPhone. This is where touches, views, images, gestures, tables, controls and that other fun iPhone stuff lives.

Mac OS 10.0 - 10.6 has AppKit = Cocoa

Mac OS X's equivalent is AppKit and has views, windows, images, open panels, tables, controls, mouse pointers, printing etc.

The key architectural difference between Mac OS and iPhone OS is that neither has the other's application layer framework. There's no AppKit in iPhone and there's no UIKit in Mac OS X. Seems logical - what would the iPhone OS need with a save panel - after all the user interactivity is entirely different between the 2 platforms.

Good logic - Until you put a touch screen on a Mac in which case things change.

Could Mac OS 10.7 have both?

Some may argue that a Touch Screen Mac doesn't make any sense ergonomically - but what's the difference between that and an iPad with a keyboard dock?

The grab...

UIKit on Mac OS X is a very good choice if there ever is a touch screen Mac - and maybe even if there isn't. Here's why:

1. It's built for finger input

If the iPad is just a big iPod Touch, then an iMac with a touchscreen is just a big iPad. If you had told me a few months ago that UIKit was a possibility in Mac OS - I'd have laughed at you (perhaps the way some of you are laughing at me now). All of this changed with the iPad though - which has proven that UIKit (primarily the user interface) can scale up to much larger devices. It's a much smaller step to take UIKit to the Mac than it was to take it to the iPad. UIKit is the thing that makes touch input really really rock. Why wouldn't you use UIKit on a touchscreen Mac - I simply don't see what other choice there is. Sure you could bring touch stuff to AppKit (and it already exists in a sense) but why bother?

2. UIKit is more modern than AppKit

There's some brilliant design in UIKit (it's an evolution of AppKit after all) for example UIViewController, everything visible being subclasses of UIView and lots and lots of small decisions that make UIKit a pleasure to code for. More app for less code is always a good thing.

3. Third party developers

There's over 180,000 apps for the iPhone. I'm not sure how many apps are available on Mac OS, but I'm sure it's a LOT less than that. There's a huge amount of code and big investment being made in iPhone code - investment that most often can be leveraged on the Mac too. The availability of more apps on the Mac is a good thing - no matter what way you slice it. Everyone wins - users, developers, Apple.

4. The AppStore

Whatever you want to take away from the AppStore is irrelevant in the light of it working so damn well. Users get apps, developers sell apps and it's all so darn easy. Argument over. Bringing the AppStore to the Mac would be very welcome. Anything you throw at the AppStore is easily deflected by how well the model of having an AppStore on the platform works. Would the iPhone or iPhone app developers be as successful without the AppStore? I doubt it would come even close. Would the iPhone be as compelling without the AppStore? I doubt that too. Will and AppStore with 200,000 apps be awesome on the Mac platform? No doubts there.

5. A lot of iPhone apps are already usable on standard Mac hardware today

How do I know that? The simulator. Apple launched the iPad with thousands of applications, most of which had never been used on the actual device. Even using a mouse input instead of a touchscreen, the UIKit app environment is damn usable. There are so many iPhone apps that I wish I could have in my iPhone simulator and just use as apps on an everyday basis.

They'd be even better with a touchscreen, but they already work well enough to be useful.

Let's be clear that I'm not suggesting UIKit will replace AppKit anytime soon (or ever) - that simply doesn't make sense. I'm making the argument that having UIKit as an option on Mac OS makes an insane amount of sense - if you have a touch screen (and only slightly less sense if you don't).

Some Q&A….

Q. Would developers need to invest much time to bring their iPhone app across?

A. Probably just recompile. Unless they did something stupid - like violated iPhone SDK 4 term 3.3.1 and used an intermediate library like Flash to iPhone.

Q. Well what would happen to my other applications in Mac OS X - can I print and use my mouse and stuff?

A. Of course. AppKit and the traditional application environment can still exist quite happily. Maybe launching a UIKit app just goes modal - like FrontRow, which notably doesn't have a mouse either.

Q. Wouldn't that take a lot of work?

A. No. That's what the simulator does now. It runs UIKit on the Mac. Job done.

Q. But the iPhone / iPad runs on ARM and the Mac uses an x86 processor. Doesn't that pose a problem?

A. Evidently not for Apple and their Universal Binaries. These were introduced back in the PPC to x86 switch, but are still very much in use today. Todays apps that are compiled for 32 and 64 bit x86 processors are using a universal binary. You can even do PPC / x86 and 32 / 64 bit apps - all 4 permutations of which exist in the same universal binary. Right now apps that run in the simulator run as x86 apps whereas apps that run on the device rum as ARM apps - so the hard work is already done. Creating a Universal Binary containing both x86 and ARM code would be a walk in the park for Apple's engineers.

Q. Wouldn't you need an accelerometer or rotation or something?

A. Not necessarily. Sure some apps need it, but many many don't. Some apps need a camera, some need a GPS, some need a magnetic compass. It won't mean all iPhone apps will be available for the Mac - the same way not all iPhone apps are available for the iPod Touch.

Q. What about the extra screen real estate?

A. That became a non-issue with the iPad. Building apps for dynamic screen sizes is now a given when creating apps for the iPhone OS. Did you really think Apple were going to use 320x480 screens forever?

Xcode + iPhone SDK: The unsung hero of 100,000 apps

March 6 2008, Apple covered their roadmap for the iPhone SDK: http://www.apple.com/quicktime/qtv/iphoneroadmap/

That was JUST 20 months ago. Unbelievable.

Since then we've all gotten caught up in the AppStore hysteria, overnight millionaires (maybe), 100,000 apps and average Joes (or Janes) developing apps for the iPhone. This is a positively enormous change for mobile application developers, traditional Mac developers and mobile entrepreneurs.

Xcode and the iPhone SDK make all this possible. It's not just a toolkit to allow you to build apps for the iPhone, but an incredibly well crafted suite (lets not forget Instruments) that is designed to allow developers to do what they do best: develop something to meet their business problem.

Everything about Apples developer tools and Frameworks scream "focus on what you're trying to achieve with your software, we'll take care of all the mundane stuff". 1 button is all it takes to get your software compiled, installed on a device and running in debug. This doesn't come as a surprise to any of the 'old school' OS X developers, but sometimes we need to be reminded about how awesome this toolkit is and how much we take it for granted.

The economist in me continually nags that any time I waste messing around with development tools is time I'm not spending on making my software better. If Xcode and the iPhone SDK were pigs to work with, then we'd still have software, there just wouldn't be as much and it wouldn't be as good.

You could even go so far as to suggest that the iPhone SDK has created a significant competitive advantage and barrier to entry in the now hotly contested market of third party application development for mobiles. The iPhone SDK has a long and rich heritage rooted deeply in the NeXT era, it's not something you can just knock out in a few months.

Sure, there will be SDK's for those other devices, but will they be as good? I guess time will tell, but I wouldn't bet on it.

OmniStats, Gruber and 10.4 Support

John Gruber of Daring Fireball has a great discussion (as always) on Mac OS X major version use:

DF Stats

Omni

Adium

The 10.4 usage (36.4%) for Omni seems very high and developers might factor this into their decision to continue supporting 10.4. However it can be argued that Omni stats are skewed due to the Apple bundling agreements that existed while 10.4 was being shipped (these agreements ended before or early in the 10.5 era). All Mac hardware shipped with OmniGraffle during 10.4 (but not during 10.5) so the overall market share of 10.4 is probably lower.

If you're a developer (and according to Gruber 11.2% of his readers are) you might not be fortunate enough to be calling your own shots and have some 'platform agnostic' marketing guy or product manager telling you that you must support 10.4 because it's a significant portion of the market or your partners need it.

Supporting 10.4 is probably a bad move for most developers at this point (unless developing for education - maybe). Here's how to argue the case for 10.5+ against someone not fluent in the Mac platform.

1. Your software won't be as good if you're developing for 10.4

The economic problem is always the same - limited resources and unlimited needs. Whilst you can work around 10.4 limitations, doing so means you've got less resources allocated to other things - like solving your business problem better. There's some really cool tech in 10.5 - from the big stuff like Core Animation and NSOperation to the small stuff like gradients and bezier paths with rounded corners. Your software will almost always be better from using these newer technologies.

It's not just the development effort either, you need to QA and support 10.4 too. That really sucks for the poor schmucks who have that job (probably one of whom is you).

Make the choice: Do you want to make good software for 10.4+ users or great software for 10.5+ users? If you're still thinking you can do both, then re-read the above until you realise by definition you can't. Your software will always be better if you develop for 10.5+ because you'll have more resources to spend on solving your business problem better or making your software easier to use.

For many products, you'd get more users from better software than you would from legacy OS support, but that argument really hinges on how many users (particularly paid ones) you're likely to get from supporting an older OS, so market share stats might be important.

2. Current market share

There's no definitive source of how much of the overall market is 10.4 or 10.5+. Omni's stat (36.4%) are probably skewed towards 10.4 due to the old Apple OEM deal and Adium's stats (15.3%) are probably skewed towards an 'early adopter' crowd who stick with the latest OS. So let's assume the overall 10.4 market share is between 20% and 30%.

3. Future market share

By the generous Omni stats, 10.4 is showing a roughly linear decline from 50% on 1 Jan 2009, translating to a decline of 18% per annum. In a year from now, 10.4 will be really inconsequential. You'll need to make back all of your extra costs from these users the next year*, or you're at a loss. This isn't just the explicit costs like development, QA & support, it's the implicit costs too - like your software not being as good. Add to that the future costs of updating to newer technologies in 10.6 like Grand Central that are automatic if you use NSOperation (which is included in 10.5).

*If you're at the stage of deciding whether to support 10.4 or not, then it's probably a few months before your software ships anyway so you need to take into account what the market will be when you launch the software.

4. The OS market share argument is rubbish

Just like the Windows vs Mac market share rhetoric, the total market % isn't important anyway. What's important is the market share of users in your target / addressable market.

Think about it… Any consumer** using 10.4 is probably too frugal to buy Apple's software, a late adopter or using an old system. Do you really think they are going to install and (more importantly) buy your software?

**You'll notice the emphasis is on consumers. There are still some big educational customers with 10.4. If this is the case for you, then you should probably take the decline in market share into account and make an assessment based on that. You might still be stuck with 10.4 for a while longer, but make an informed choice.

But what if I already support 10.4?

This stuff is all still relevant. If you're keeping your software up to date, then you'll probably realise a lot of this already.

As Wayne Gretzky said "skate to where the puck is going to be", this is still relevant to all of your current and future development efforts.

Conclusion

There are some 10.4 users and some of them might buy your software, but are there enough to regain the costs, time and headaches of developing for 10.4 worthwhile?

Coolest thing I learnt at WWDC 2009

Cocoa's support for KVO and Properties is awesome, but every now and then I find something I can't do. I frequently use 'derived' properties, where a read only property is derived from a combination of instance variables. For example, we might have an object with firstName and lastName, then want a KVO compliant fullName.

Cocoa did offer some support for this in your own classes by doing a willChangeValueForKey: and didChangeValueForKey:. The real challenge comes when you want to have the derived accessor in a class category in the app layer where the base class is in a framework. The framework base class has no knowledge of class extension in the app layer, so can't post the willChange/didChange, so your derived accessor is not KVO compliant.

Let's look at how things used to work with a basic example using firstName, lastName, fullName in our own object.

Header...

#import

@interface Person : NSObject {

NSString *firstName;

NSString *lastName;

}

- (void)setFirstName:(NSString *)value;

- (NSString *)firstName;

- (void)setLastName:(NSString *)value;

- (NSString *)lastName;

- (NSString *)fullName;

@end

Implementation....

#import "Person.h"

@implementation Person

- (void)dealloc{

[firstName release], firstName = nil;

[lastName release], lastName = nil;

[super dealloc];

}

- (void)setFirstName:(NSString *)value{

if ([firstName isEqualToString:value]) return;

[self willChangeValueForKey:@"fullName"];

[firstName release];

firstName = [value retain];

[self didChangeValueForKey:@"fullName"];

}

- (NSString *)firstName{

return [[firstName retain] autorelease];

}

- (void)setLastName:(NSString *)value{

if ([lastName isEqualToString:value]) return;

[self willChangeValueForKey:@"fullName"];

[lastName release];

lastName = [value retain];

[self didChangeValueForKey:@"fullName"];

}

- (NSString *)lastName{

return [[lastName retain] autorelease];

}

- (NSString *)fullName{

return [NSString stringWithFormat:@"%@ %@",self.firstName,self.lastName];

}

@end

I presented this quandary to an Apple engineer at WWDC 09 and after a few minutes he found this in NSKeyValueObserving.h and became my new hero. (I love WWDC for just this reason... the guy saved me an unbelievable amount of work).

/* Return a set of key paths for properties whose values affect the value of the keyed property. When an observer for the key is registered with an instance of the receiving class, KVO itself automatically observes all of the key paths for the same instance, and sends change notifications for the key to the observer when the value for any of those key paths changes. The default implementation of this method searches the receiving class for a method whose name matches the pattern +keyPathsForValuesAffecting, and returns the result of invoking that method if it is found. So, any such method must return an NSSet too. If no such method is found, an NSSet that is computed from information provided by previous invocations of the now-deprecated +setKeys:triggerChangeNotificationsForDependentKey: method is returned, for backward binary compatibility.

This method and KVO's automatic use of it comprise a dependency mechanism that you can use instead of sending -willChangeValueForKey:/-didChangeValueForKey: messages for dependent, computed, properties.

You can override this method when the getter method of one of your properties computes a value to return using the values of other properties, including those that are located by key paths. Your override should typically invoke super and return a set that includes any members in the set that result from doing that (so as not to interfere with overrides of this method in superclasses).

You can't really override this method when you add a computed property to an existing class using a category, because you're not supposed to override methods in categories. In that case, implement a matching +keyPathsForValuesAffecting to take advantage of this mechanism.

*/

In a nut shell, all you have to do is add a class method and return the key paths for the value that affect your derived accessor....

+ (NSSet *)keyPathsForValuesAffectingFullName{

return [NSSet setWithObjects:@"firstName",@"lastName"];

}

So the implementation can be simplified to this...

#import "Person.h"

@implementation Person

@synthesize firstName, lastName;

- (void)dealloc{

[firstName release], firstName = nil;

[lastName release], lastName = nil;

[super dealloc];

}

- (NSString *)fullName{

return [NSString stringWithFormat:@"%@ %@",self.firstName,self.lastName];

}

+ (NSSet *)keyPathsForValuesAffectingFullName{

return [NSSet setWithObjects:@"firstName",@"lastName"];

}

@end

And the header this....

#import

@interface Person : NSObject {

NSString *firstName;

NSString *lastName;

}

@property (retain) NSString *firstName;

@property (retain) NSString *lastName;

@property (readonly) NSString *fullName;

@end

The moral:

- Much less code

- Can do it in a class category

Only downside is 10.5+ only, but you shouldn't be worried about 10.4 by now right :-)

Wheels for the Mind

Mathieu Tozer (from Plasq) and I were interviewed for Wheels for the Mind magazine about being Australian Mac developers. Both of us received Scholarships from the AUC to attend WWDC in 2006.

Check it out here: http://www.auc.edu.au/tiki-download_file.php?fileId=144