Mobile Engineering Quality

Android vs iOS.  Plenty of debates about this topic and plenty of opinions.  So here's mine...

I can't help but consider which platform has the most solid engineering.  Which platform is more refined for its purpose.  Good engineering is evident in attention to detail.  The virtues of consistently exceptional engineering are very difficult to instill and maintain in an organisation.

I've been to WWDC (many times) and to Google I/O (even spoke there) and my firm impression is that from an engineering perspective iOS is far more refined.  I've had conversations with very smart engineers in both camps.  I've attended and watched more WWDC and Google I/O video sessions than anyone should.  There are loads of small points I've picked up from these discussions and sessions that make iOS the platform I have the most faith in - the one I believe is better engineered.  I'm going to call out 2 of them...


1 - Battery life: It's like everyone at Apple who has ever written code for iOS has been brutally beaten with a "must preserve battery life" stick several times a day until they understood.  It's almost impossible to have a conversation with an Apple engineer without them bringing up battery performance as a reason for some design decision or coding practice in iOS.  It's like a nervous tick, but executed with confidence.

I recall speaking to Apple engineers at WWDC in 2008 who went into some considerable detail on how managing retain / release / autorelease for objects could have a positive effect on battery life.  I recall the first WWDC session on how to use the accelerometer and the comparison of starting / stopping the accelerometer hardware compared to short and long term use.  I recall sessions on why you shouldn't override drawRect: in a UIView subclass because it had some nominal yet demonstrable drain on battery.

It's really hard to instill this kind of attention to detail across an organisation - to get everyone thinking about the stuff that matters.  Battery life matters.  Android battery life sucks.  Apple engineering has an incredible attention to detail that makes things like battery life not suck.  Battery life is just an example of one area where Apple's superior engineering practices are evident to everyday users.  It's really easy to screw up, it's really easy to cut corners and make devices that only last 19 hours on the best day you've ever had.  Apple engineers don't screw up battery life and they work hard to make sure 3rd party engineers don't either.


2 - IDE: Xcode wins.

It's rare to be able to make such a forthright statement without need for justification, but I doubt anyone's going to argue.  Xcode wins.  From a third party developer perspective the richness of the system API's are pretty important, but it's not just what's in the technology stack and what API's one has available to them - it's how easily one can makes software that utilize them.  Xcode makes it easy to create software for iOS.  Documentation, static analysis, provisioning, instruments, etc.  Xcode wins.  It takes engineering discipline to make a product that rocks as well as Xcode.



Android and iOS both appear to be in "adding features mode".  There's a big difference between adding features and adding features well.  Adding features well requires an attention to detail for things like error handling, network latency and dealing with corner cases that few people ever considered.

In my experience engineering quality is consistent across an organization (at least at the macro level).  It's rare to have a group of engineers turning out exceptional quality in the same organization as a group of engineers turning out crap.  They are mutually opposing forces and one will destroy the other.  So when I find a couple of areas where iOS has been engineered so well, I have considerable faith that all areas are developed almost as well or even better.

Tablet Bloodbath

I bought an Android Tablet (the Motorola XOOM) on Friday.


During the process at Best Buy it struck me the upcoming 'Tablet War' will bear an uncanny resemblance to the PC market.  Motorola won't compete with Apple in the Tablet market any more than Acer competes with Apple in the PC market.


When consumers go to Best Buy to get a Tablet they'll ask themselves 2 questions:

Q1: "Do I want an iPad or an Android?"

Q2: "If I want an Android then which one do I want? Motorola, Samsung, Asus, Dell...."

Motorola's biggest competition will be Samsung, Acer, Dell and anyone else who releases an Android tablet (and boy there's a lot of them). Competition with Apple is a secondary problem for these guys at best.


In theory, it's Google vs Apple.  The tech tabloids and industry boffins are eating that stuff up because it's interesting for industry people to analyze, debate and pontificate over.


In practice, it's comes down to manufacturing, distribution and the showroom - where Google is a logo on a box at best.  You'll soon be able to see Apple standing tall in one corner of Best Buy and every other tablet manufacturer fighting a brutal battle against each other in another corner.  When it comes down to it - Motorola and Samsung will soon be busy one upping each other on hardware features and under cutting each other on price.  Apple will have the best seat in the house during the upcoming tablet bloodbath.


Sure, there might be cheeky ad campaigns that try to pitch Apple against Manufacturer X and plenty of industry analysts comparing Google vs Apple, but when it comes to the showroom floor it will be Motorola, Samsung, Acer and Dell sucker punching each other until the weak ones get out of the ring.


I don't see Apple doing much other than continuing on their own merry way while the bevy of Android Tablet manufacturers beat each other up.  An uncanny resemblance to the PC market where Apple is extremely profitable and the 'competition' has either been eaten up (Compaq, DEC, IBM) or is surviving on ridiculously thin margins (Dell, HP,  Acer).


The technology might be new, but the story of Apple vs Android is neither new or even very interesting.  Apple vs HP on the other hand is behemoth vs underdog and one should never ignore an underdog.

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?