Tuesday, July 12, 2011
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.
Sunday, February 27, 2011
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.
Thursday, June 3, 2010
Friday, April 30, 2010
Cocoa is the development frameworks for Mac OS.
Cocoa Touch is the development frameworks for iPhone OS.
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
Saturday, April 17, 2010
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...
Saturday, November 7, 2009
Tuesday, September 22, 2009
John Gruber of Daring Fireball has a great discussion (as always) on Mac OS X major version use:
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.
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?