Conflicts

The Talk Show is one of my favorite podcasts. It is hosted by Dan Benjamin and John Gruber on the 5by5 network. On Episode 47, Gruber talked a bit about his thoughts on iCloud and one item has garnered a lot of attention around the web. Thankfully, the folks at Mac Stories typed up a transcript:

Gruber: The new way does not involve merging and conflicts. […] It doesn’t mean that Apple has magically solved the tech difficulties of syncing. […]

You’ve got 3 devices let’s say. Server-side data stored somewhere on a server, and you’ve got an iPhone and you’ve got a Mac. All data is up to date, say Address Book. You have an entry for Dan Benjamin and all it has is an email address. In all three places it’s the same and I sit down at my Mac, I add your home phone # to your contact and then I sit down with my iPhone at the same time (say everything’s offline) and enter Dan’s home # manually, but I enter it wrong. What happens when you sync? You’ve entered two phone numbers in two places, and at the server there’s no phone number. As it stands now MobileMe often will offer you a dialog box telling you that there is a conflict. It presents it to you and you have to pick which one is right. […]

In iCloud I believe you will never be presented with such a dialog, no matter how much has changed in one of the instances while it was “offline”. The server-side iCloud, when there seemingly is a conflict, will make a decision and it will decide which one is the best (in Apple’s terms the “truth”). That is what Steve Jobs means when he says “The Truth is in the Cloud.” iTunes will decide which one is right and that’s it. iCloud will push that right one to any device that has this account that has a different version. But, here’s the trick – what happens if it’s not the right one? On the server side, it will remember all of the other ones, almost like versioning. There will be some sort of interface like “go and look at your contacts.” There will be some sort of way to say “show me previous versions and let me pick the one that is right”. You pick it and push it back up into the cloud and tell it “that’s the truth” and Apple will push it out.

Dan Benjamin: Whatever is the most recent change will propagate but here are previous versions to pick from if you want.

Gruber: Apple won’t reveal it but iCloud, on the server, will determine the truth when it detects a conflict that will never be published. It will act like a “black box”. Most cases it will go by the most recently implemented change — it will be undefined. The key is that if there is a conflict, they will remember the different conflicting versions. If it picks the “wrong truth” it will be able to go back and get the right one. That’s what I mean when I say no more merging or conflicts. iCloud will make its best guess at merging & conflicts other than having you pick it.

Dan Benjamin: Do you know this or is it just a theory?

Gruber: I know this. What I don’t know but I believe, again, is that I think iBooks is an example of this in action. If you have the same iBook on the iPhone and iPad and take them both offline and flip a couple of pages on the iPhone then flip a different number of pages on the iPad, and them put them both online and they go to sync their “read state” or “current page state” to iTunes servers, iBooks never presents you a dialog. […]

iBooks is and has been one of the testbeds for what Apple is now calling iCloud.

I don't know about you, but I think data conflicts are aggravating and disruptive. Thankfully, I rarely see them, but I hate it when I see them, mainly because conflicts rarely affect just one file.

That said, I am curious if iCloud's conflict resolver will work well. At least when the user is prompted, they can do a little legwork to determine which info is correct, and then be done with it. I almost think it would be more frustrating to have iCloud pick the "wrong truth" and then have to rely on that when you are out and about.

Of course, the versioning support sounds like a great compromise, but how exactly do you access that? Through a Mac or PC? That isn't helpful when you are out with friends. If there is a way to access those versions in iOS, that could make things easier.

One thing that does make sense is that iBooks has likely been a large-scale test for iCloud. And it is very good, in my opinion. I haven't once noticed any anomalies between the last-read state on my iPhone or iPad. Even more so, all my highlights and notes seem to work just fine, too, despite sometimes reading my on my iPad while offline.

In the end, I can see why Apple doesn't want to burden users with conflict resolution. It doesn't exactly inspire confidence in a system when it throws up errors. If iCloud can make the right choice 99% of the time, that's pretty awesome. And for most types of data, like iBooks and bookmarks, an wrong choice every once in while isn't particularly devastating. Where iCloud will have very little allowance for error will be calendars and contacts.

Thoughts on iMessage

One of the upcoming features in iOS 5 that I am downright nearly giddy about is iMessage. I am stingy with text messages because, frankly, they are expensive for what they are. I have had the 200 messages per month plan at $5 since day one with AT&T, which, unfortunately, is no longer an option. If I ever change my texting plan, I lose my preferred option forever. The next one up is $10 plan, which includes 1000 messages. Now, the message per dollar ratio is better with the new low-end plan, but that is an extra $60 per year.

Now, a fair amount of the people I interact with use iPhones (even more with iPads and iPods touch). With iMessage, I will get all the benefits of texting with none of the costs. The best part is the experience looks to be seamless. iOS will check the contact to see if they have iOS 5, and if so, will use iMessage. If not, it will fall back to your carrier texting plan.

I think one of the larger benefits of iMessage will be interacting with several friends in the UK quickly and easily. There have been many times where I have a question for one of these friends, and a text message would be a fantastic medium. Sadly, I've had to resort to twitter or email. Twitter is great, but not everyone is constantly checking it, and email — well, no one wants more email.

iMessage is one of those features that will change things a lot. And I love that it is practically a giant "screw you" to carriers and their insane texting fees.

¶ Lofty Promises

Apple has a habit of changing our lives. They did it in the 70's with the Apple I & II, by aiming to make computing available to everyday people. That same focus leaped forward in 1984 with the advent of the Macintosh. The original iMac mitigated the intimidating aesthetic of computers, breaking up some of the presumptions of everyday folks that computers were beyond them.

Then Apple started creating a bond between our computers and ourselves. They truly started to become personal when Apple heralded the idea of the digital hub. Your computer suddenly became the keeper of things most precious to you: your photos, your music. The video of your child's elementary school play.

The iPod came, giving you a medium to carry a copy of your digital hub everywhere. First, it started with music, something that can move the passion within our souls. Then it added photos, so we could show our friends and family a favorite picture. Then videos were integrated. Iteration after iteration brought more and more of our personal lives with us everywhere.

Then another leap — the iPhone. The ability to remove an abstract interaction with these precious digital memories — no more keyboard and mouse, no more click wheel. You simply touch, swipe, pinch, tap. A natural interaction that a two year old can learn, and also the elderly who were too afraid of the complexity of computers.

The iPad expounded that dream even more, and whether you like the catchphrase or not, something magical did indeed happen. To quote John Gruber:

It’s a shame, almost, that we squandered the term “personal computer” 30 years ago.

How true.

A Digital Divide

Somewhere along the line, amongst the magic, some of the smoke and mirrors that the audience is never supposed to see became apparent. It became too difficult to maintain the illusion of these multiple devices working simply and with little maintenance. The digital hub became the digital burden.

It became too much for a person with multiple devices to remember which device had synced back to their digital hub on their computer at what time and with which content. Complexity tainted the promise of simplicity.

A Lofty Solution

Monday, Apple changed the game. Where the computer served as the digital hub for the last decade and, for a time, worked well, the new hub belonged somewhere else. Technology finally allowed for the rest of us to have something special. A hub that exists in the lofty domain of the "cloud".

Apple's forthcoming iCloud serves as the new hub, and your computer is just another device among your iPhone and iPad in this new vision.

The promise of iCloud takes something that happens on your iPhone — a new photograph, for instance — and effortlessly transmits it to iCloud, which then pushes it to your other devices. The same goes for a new music or book purchase, a bookmark, a freshly composed document. It all happens in seconds, and the user never has to think about what is stored where.

A lofty promise, indeed.

Commitment to the Promise

This isn't the first time Apple has attempted cloud services. I vaguely remember iTools in Mac OS 9. I was young and didn't care enough at the time. I also remember .Mac throughout the better part of my life as a serious Mac user, though I never had a need to subscribe. MobileMe is the most current release of iTools/.Mac, and it was this iteration that finally lured me into Apple $99/year subscription.

The promise of MobileMe was push email, contacts, calendars, and bookmarks. It also provided access to iDisk. For me, MobileMe has been a solid investment. It accomplishes the email, contacts, calendars, and bookmarks syncing between my mac, iPhone, & iPad. That is what I bought it for, and it lives up to the promise for me. iDisk, however, is a disaster. I don't use it for much, and Dropbox is what I turn to for that functionality instead.

Many other folks I know or follow think differently of MobileMe. They hate it. It doesn't live up to the promise in their eyes. Apple itself thinks of it as a failure. Steve Jobs even poked fun at it in the keynote.

It was this juncture in Jobs' keynote that we see that where MobileMe was a bolt-on product that Apple put just enough effort into, iCloud will be a first-rate service that Apple will put everything it has behind.

The commitment was revealed in iCloud's availability and pricing. Where MobileMe was adopted by a small percentage of Apple's user base due to its $99/year cost, iCloud is intended for all users to adopt with the low price of free. This fact alone shows that Apple must be committed to iCloud's success. Apple can't afford to have it fail. Apple's reputation with all its customers will be tarnished if iCloud doesn't live up to its promise.

---

I, for one, look forward to iCloud with great anticipation. I had a very good run with MobileMe, and if it worked that well without Apple truly focusing on the service, then iCloud should be astounding.

¶ In Memoriam

I don't get very personal on this site too often, but today is one of those days.

Today is Memorial Day here in the States, a day which we set aside to remember the soldiers that have paid the ultimate price for the freedoms we enjoy. Many of us celebrate by enjoying those very freedoms, knowing that we are safe from threat.

This Memorial Day I find myself thinking not only of fallen soldiers, but also those who currently serve. Even more specifically, I find myself thinking of those serving in South Dakota.

See, my hometown of Pierre, South Dakota is expecting to endure a flood for the first time in 59 years. A flood that will likely be worse than the one in 1952. The most shocking part is that a flood was never supposed to happen again, as Pierre is home to the world's second-largest rolled-earth dam. I guess this just goes to show that mankind cannot control the forces of nature.

I have many friends who will be affected by this flood. My parents are affected by this flood. Thankfully, my parents will have their home — which resides a hundred yards from the river — evacuated by the end of the day. The Army National Guard is building a levee in front of their house. I hope it holds.

It is a very real possibility that the home I grew up in will be greatly damaged, perhaps irrevocably.

So yes, I find myself thinking today of those who selflessly defend our country and serve our citizens. And I thank them from the bottom of my heart.

¶ The Writing on the Wall

I love Twitter. The service itself has connected and reconnected me with more people than I could have imagined. I have made lasting friendship with a couple folks on another continent. I have been able to candidly chat and bounce ideas off fellow writers who inspire my own writing. I have been able to help with the development of some of my favorite apps on iOS and Mac OS. I have met many of my local friends through Twitter, and a few of those friendships have developed into bonds similar to family.

To say that Twitter has become a new communication medium that has changed and will continue to change lives is an understatement. But some of the fun of Twitter is fading. And that's because the folks in charge of Twitter¹ don't seem to be fostering a community and ecosystem anymore.

Tweetie — The Harbinger of Doom

Those who have joined Twitter in the past six months or so likely don't realize that Twitter hasn't always had its own official app. In the old days, Twitter's official ways to access the service were via the website, the mobile website, or text message. Much of Twitter's popularity was garnered by third-party apps such as Twitterrific and Tweetie. Twitterrific was the first on the scene, and Tweetie was a late-comer, but quickly became the darling of many users.

In April 2010, Twitter acquired Tweetie and rebranded it as Twitter for iPhone, making it the official Twitter client. Over the next year official clients popped up for Blackberry and Android. The iPhone app became universal with the addition of an iPad interface, and the Mac version of Tweetie was updated and rebranded as Twitter for Mac.

This foray into official apps was the first blip on the radar.

A Shot Across the Bow

Back in March, Twitter's Platform/API Leader Ryan Sarver posted a note to third-party developers about the future of fully featured third-party clients.

Twitter will provide the 
primary mainstream consumer client experience on phones, computers, and 
other devices by which millions of people access Twitter content (tweets, 
trends, profiles, etc.), and send tweets. If there are too many ways to use 
Twitter that are inconsistent with one another, we risk diffusing the user 
experience.

and

Developers have told us that they’d like more guidance from us about the 
best opportunities to build on Twitter. More specifically, developers ask 
us if they should build client apps that mimic or reproduce the mainstream 
Twitter consumer client experience. The answer is no.

The day that was posted was not a good day to be a developer of a third-party Twitter client.

The x & O of Auth

A year ago Twitter made a change in how third-party apps access the Twitter service. Instead of Basic Auth, where a user supplies their username and password and an app stores both of those credentials, the service moved to OAuth, where a client receives and stores an access token linked to the user's account. This token can be revoked at any time from a user's settings page on the Twitter website. So OAuth is nice in that revoking access from a client is much easier if needed.

The problem a year ago was that OAuth requires a web view for the user to give permission for the client to access the Twitter service. It's janky and ugly and doesn't work very well on a smartphone, in my opinion.

Third-party developers voiced these same concerns, so Twitter adopted xAuth, which allows a developer to make a beautiful interface that asks for the user's username and password, and uses that momentarily to request the OAuth token. The token is then stored, and the user's credentials are not. This is fantastic for third-party clients. All the security benefits of OAuth with the ease of Basic Auth. It's a win-win-win for Twitter, developers, & users.

Well, one week ago Twitter announced (developer oriented version here)that they were removing direct message access from xAuth, and all full-featured clients would have to switch to the problematic OAuth web interface if they wanted to continue giving their customers direct messages.

John Gruber comments:

That’s good news on the surface — it means you can use services and apps that require your Twitter credentials without granting those services/apps access to your private direct messages. For services/apps that are entirely public, this makes sense. But there’s a big shit sandwich attached: Twitter is implementing this change by requiring all third-party clients that want or need access to direct messages to use the cumbersome OAuth login flow for authentication.

[…]

Thanks to OAuth, you never need to give these sites your Twitter password, let alone allow them to store your password. Instead, they forward you to twitter.com, you grant them access to your account there, and then twitter.com forwards you back to the website where you started. It’s common sense: a web-based authentication flow works naturally from within a web browser. But the same web-based authentication flow is jarring for native apps. When you open a native app — Mac, Windows, iOS, Android, WebOS — you don’t expect to be forwarded out of the app and into your web browser. Developers can alleviate some of the context switching by using an embedded web view inside their native app for the OAuth authentication handshake, but at that point, why not just use xAuth and simply allow the user to enter their username and password in a native dialog box? So long as you remain within the app, there’s no security advantage for OAuth in an embedded web view over xAuth — but there’s a huge decrease in usability, simplicity, and clarity to the user.

[…]

And OAuth is even worse for setting up multiple accounts in a native client (and good multiple account support is surely one of the leading reasons to use a native Twitter client instead of the twitter.com web site). Because then, not only do you need to go through the cumbersome OAuth login process for each additional account, but you must first sign out of the Twitter account you’re already signed into in the web browser. The twitter.com web interface is inherently single-account. To use a different Twitter account in the same web browser, you have to first sign out, then sign back in using the other account. With xAuth, to add an additional account you merely enter another username and password. With OAuth, you have to start by signing out of whatever account you previously signed into. You only have to do this when first creating each new account in the client app — the app can save the OAuth credentials for multiple accounts — but it’s still far more complicated and annoying than simply entering a username and password.

The whole article is worth your time. There's a lot of gold in there.

To me, this move is solely to make life difficult for third-party developers. Even though I don't think Twitter would be nearly as successful today if the third-party clients hadn't made Twitter such an attractive medium, I also don't think Twitter owes developers in the long-run. It is their platform, after all. Same goes for Apple and Android, etc.

I do however, think Twitter has been rather duplicitous. Why have the annual Chirp developer conference when the company obviously does not want to foster an ecosystem? It doesn't make much sense.

Sadly, I don't think we will see fully featured third-party Twitter clients by this time next year. I think Twitter will cut them out. Which, in my opinion, will also cut out innovation on the Twitter service as a whole.

A Symbiotic Relationship

Throughout the past few years that I have been a Twitter user, I have always used a third-party client as my primary access to the service. I started out back in the day with Twitterrific, which was only available for the Mac (the iPhone didn't exist yet). My usage exponentially took off after I got an iPhone 3G on day one and Twitterrific for iPhone was available that day on the App Store, which also debuted that day. I had a brief affair with Tweetie on my iPhone for a couple months until Twitterrific updated with a lot of nice new features. And my Mac saw the occasional use of Tweetie for Mac, though I used my iPhone more because I love Twitterrific. And now Twitterrific is available using the same experience on iPhone, iPad, & Mac. So that is where I am happy.

Tweetie, however, was very great on both the iPhone and Mac. But the quality of both apps seems to have degraded since the developer sold out to Twitter. They may be the official apps, but they were both more stable and a better overall experience when Loren Brichter worked alone on them.

Now that I have established ad nauseum my preference for a third-party app, let me tell you why: that's where all the innovation has come from.

I'll start with a few that Craig Hockenberry, lead developer of Twitterrific, came up with regarding his app:

1. First use of “tweet” to describe an update (see page 86 of Dom Sagolla’s book.)
2. First use of a bird icon.
3. First native client on Macintosh.
4. First character counter as you type.
5. First to support replies and conversations (in collaboration with Twitter engineering.)
6. First native client on iPhone.

There are a number of the central themes of Twitter that came from one third-party app. Not to mention that @-replies and Retweets² were innovated outside of Twitter itself as well.

---

My point is that third-party clients have been an important part of the Twitter experience. For many third-party clients were and are their main experience with Twitter.

Twitter gave developers a service to build upon, and developers in turn gave Twitter a user base and ideas on how to make the service even better. Many of these ideas I don't think Twitter would have implemented on their own. And now it just comes off that Twitter is stabbing developers in the back.

If you've seen the first Iron Man movie, Twitter sure seems a lot like Obadiah Stane, and developers seem like Tony Stark. And Obi is trying to kill off the golden goose that churns out invention after invention.

¹ At least in charge this year. The captain's chair has a high turnover rate at Twitter.

² Crudely implemented in clients first. Twitter came up with a better solution later, but they likely would not have implemented official retweets with the classic style becoming popular.

¶ Full-Screen, Scotty

One of the features of the upcoming Mac OS X Lion I am looking forward to is full-screen apps. There are some apps that offer this mode on Snow Leopard now, but they rest on top of all your other apps. This is one of the reasons I don't care for Windows, and rarely use any OS X apps with full-screen mode currently. I'm just not a big fan of the idea of full-screen apps being "stacked."

But Apple rethought the idea for Lion, by merging Leopard's & Snow Leopard's Spaces feature with full-screen apps. The shift in perception of full-screen apps residing side-by-side rather than stacked works for me. Even more so with the ability to move between with trackpad gestures, which I have a bit of an addiction to. [Check out the video.]

I am very glad to see the current iteration of Spaces move from a grid layout to a side-by-side layout. And filling a space with a full-screen app jives with my workflow now. I have always used Spaces as a way to segregate apps that I want to take up the fullscreen from apps with intentionally smaller UIs. For example, iCal and iTunes get their own space, whereas Twitterrific, Reeder, etc reside in my primary space.

I figure I'll have iCal, iTunes (presuming an update to support full-screen), the redesigned Mail, and maybe even Safari in full-screen mode nearly all the time, leaving the "Desktop" space for smaller apps.

It's odd that a reorganization of how full-screen apps behave does the trick for me, but I look forward to the focus I hope the feature brings.

¶ Now is the Time for FaceTime

I've been thinking a little more about Microsoft's acquisition of Skype and how it will affect users. I made a quip earlier about how I'd hate to be a podcaster who depends on Skype for their business. Honestly, pretty much every podcast I listen to relies on Skype. Now would be a great time for someone else to jump into the game with a first-class conferencing app.

But podcasting is a little bit of a niche market for Skype. The majority of Skype's use is regular people keeping in touch — especially overseas. My folks use Skype almost daily to communicate with a friend stationed in Iraq.

Now, I don't use Skype often. And I have never used it on Windows. But the Mac version actually took several steps backwards from the previous v2.8 to the rehashed v5. The UI is a mess. A few weeks ago, I did actually have to use Skype to video chat with one of my few PC-using relatives. It. Was. Awful. The video didn't start right away so I had to figure out how to get that going, then my uncle couldn't hear me, so he had to figure out what was wrong on his end with that. It took ten minutes of fiddling before we could even talk.

Compare this with Apple's FaceTime. For regular video chat, it is fantastic. You select the person you want to talk to, and the call connects. Every. Time. Instant audio and video. Drop dead simple.

FaceTime has one major downfall though: it only works between iPods touch, iPhones, iPads, & Macs. When FaceTime was introduced, it was billed as being an open spec that anyone could build upon. Unfortunately that hasn't happened yet.

Apple, now is the time to make your play. Get FaceTime for Windows out. Heck, get FaceTime on Android devices. Act soon, and FaceTime could be the next de facto video communication app for the rest of us.

¶ PIN for iOS

Yesterday evening, I saw an interesting tweet from Kevin Rose:

If a four digit pin is good enough for the ATM it should be sufficient for an iTunes purchase on my phone, putting in passwords sucks

Now, I really believe in having strong passwords that are different for the various services I use. To do this, I employ the use of 1Password on my Mac, iPhone, iPad, and my Windows 7 virtual machine. And it all stays in sync via the wonderful Dropbox. Using this, not even I know the various passwords for the different sites and services I use. But 1Password does, and I know how to get at that information.

However, I am forced to either remember my password for iTunes/App Store purchases/updates on my iPhone and iPad, or delve into 1Password each and every time I need to do anything.

I can see why Kevin seeks a PIN for iOS. And I am nearly inclined to agree. Apple provides the free Find My iPhone service, which gives an extra security to lock someone out of your data or erase that data entirely if your iDevice falls into the wrong hands. I think for most people a PIN would be sufficient. Much like an ATM, you need to have two things: something you have (the card) and something you know (the PIN). The situation is very similar with Kevin's idea. You have your iPhone and you know your PIN. And just like if you lost your card and report it missing, you can lock down or erase your iPhone if necessary.

I think the PIN system could work. It should at least be an option for those willing to take a little greater risk.

¶ My Theory on Why iOS Logs Your Location

Media coverage is sensationalizing an open source tool, iPhoneTracker, which maps out location data points collected by a 3G-capable iOS device. Be sure to read their FAQ, which isn't so sensational.

Using this app to look at my data, it definitely pings off cell towers, not GPS. With this in mind, I posit that Apple may have the iPhone (and 3G iPad) keep track of cell towers to aid in speeding up its Assisted-GPS, which uses cell towers to triangulate a smaller search area for the GPS satellite. The device would be able to provide location results to the user much more quickly if it had an index of nearby towers.

This would also explain why this data is included in the iPhone backup. It would be inefficient to rebuild the database from scratch if you had to restore your phone.

And to pre-empt the argument of why doesn't Apple include a pre-made database:

• Databases take up drive space. The method of logging towers near you makes the data relevant to you, and excludes a lot data that would be largely useless to you.

  Addendum: Of course this still results in a database that takes up space, but it wouldn't be nearly as large. The point is that you have a database of relevant data.

• Also, Apple doesn't have to maintain updates to carrier databases when new towers are added. Instead, your iPhone just maps a new nearby tower itself.

Lastly, I haven't seen anyone provide any evidence that this data is transmitted back to Apple. So if this data only exists on your device and its backup file, what's the big deal? Especially since it is probably saving you time when you willingly tell the world where you are via geo-tagged tweets, Foursquare check-ins, and Instagram updates. Never mind that the Camera app geo-tags every photo you take in an instant.

¶ The Fast Pace of Getting Left Behind

In hardware and software, fragmentation is inevitable. Eventually newer software will demand too much of older hardware, and the older hardware will need to enter the realm of being unsupported. Sure, this can be caused artificially by the software or hardware maker not wanting to put forth the effort to support the past. The decision can also be made for the sake of not impacting the experience of a device. No one wants to run software that performs poorly because the hardware can't keep up.

Normally this retirement process takes years. But as technology moves forward at an ever increasing pace, the span between hardware debut and retirement is closing faster than ever. Sometimes it is done out of necessity, and other times artificially.

Let's take the Mac. Apple tends to support hardware with software on the Mac for about five years. This day and age, that is plenty reasonable in my book. Apple's approach is to support the hardware until it becomes a technological burden to the advancement of the software. The chief exhibit is the current version of Mac OS X — Snow Leopard. Snow Leopard cut off support for the old PowerPC architecture. Folks with PowerPC Macs are cut off using Leopard until they buy a modern Mac.

Why did Apple need to do this? Because supporting older hardware was eating up too many development resources for newer software. Eventually you have to stop supporting things you no longer make. When Apple cut off PowerPC support, Mac OS X went from an installed hard drive footprint of around 13 GBs to 6 or 7 GBs. The result was a faster, leaner operating system.

In the upcoming Mac OS X revision — Lion — Apple will be dropping support for 32-bit Intel processors, which were the first Intel Macs. Again, these Macs are 5 years old. And the reason this time is to cut out supporting 32-bit and 64-bit processors, especially at the kernel level. The goal is to be faster and leaner.

Now, let's look at iOS. This is a whole different ballgame, as mobile development is moving so much faster than desktop and notebook development. There have been 4 iPhone and iPod touch generations. The current generation of these devices are leaps and bounds faster and more efficient than the first generation models. Yet Apple supported first-generation devices through the third OS revision. With iOS 4, Apple finally pulled the plug on those first-generation devices, because the software had truly outstripped the hardware.

Here is where Apple made a bit of a mis-step though. They were still selling the second-generation devices as discount, entry-level prices just before iOS 4 shipped. So they felt obligated to support them. And that didn't work out so well because the second-generation of handheld iOS devices shared much of the same hardware as the first-generation. This caused these devices to perform poorly, and Apple scurried to optimize iOS 4 for performance on these older devices in 4.1 and 4.2. But it really wasn't enough. So with iOS 4.3, Apple pulled the plug on support for second-generation hardware, which I am sure they didn't want to do until iOS 5.

What I've described above for iOS is only one side of the coin. Those were necessary hardware retirements. That isn't to say that Apple hasn't artificially retired features improvements along the way. For instance, iOS 4 brought along Game Center integration. This was included in the second-generation iPod touch, but not the second-generation iPhone. I can't imagine that was truly a hardware limitation. Or how about this: iOS 4.3 brought Personal Hotspot to the iPhone 4's tethering ability, but not to the iPhone 3GS, despite the fact that jailbreakers can do Personal Hotspot on the iPhone 3GS. Are artificial limitations a jerk move? Yeah, they are. And everyone can be a jerk at times.

Finally, let's look at Android. Android has been the prime target of the fragmentation blame game. And it often seems like it has been earned. But who is really to blame? Google? Or the carriers? I say a little of both. Vlad Savov wrote on Engadget over the weekend:

Where the trouble arises is in the fact that not all Androids are born equal. The quality of user experience on Android fluctuates wildly from device to device, sometimes even within a single phone manufacturer's product portfolio, resulting in a frustratingly inconsistent landscape for the willing consumer. […]

The point is not that carrier or manufacturer customizations should be abandoned entirely (we know how much those guys hate standardization), it's that some of them are so poor that they actually detract from the Android experience. Going forward, it's entirely in Google's best interest to nix the pernicious effects of these contaminant devices and software builds. The average smartphone buyer is, ironically enough, quickly becoming a less savvy and geeky individual and he (or she) is not going to tolerate an inconsistent delivery on the promise contained in the word "Android."

And this is exactly how things are in the Android world. There isn't a uniform experience standard. Perhaps this is why, according to Bloomberg Businessweek, Google has started handpicking partners to showcase Android, and delaying the source code to everyone else:

Over the past few months, according to several people familiar with the matter, Google has been demanding that Android licensees abide by "non-fragmentation clauses" that give Google the final say on how they can tweak the Android code—to make new interfaces and add services—and in some cases whom they can partner with. […]

Google has also started delaying the release of Android code to the public, putting smaller device makers and developers at a disadvantage. On Mar. 24, Bloomberg Businessweek reported Google won't widely release Honeycomb's source code for the foreseeable future.

The company's moves are hardly unprecedented in such a fast-moving industry. Google owes it to its partners and consumers to prevent Android from running amok.

Android has been running amok. It is saddening when I hear some friends — who are normal, non-geeky people — lament about how the phone they bought three months ago isn't getting the new features of so-and-so's phone from last week.

As I stated at the beginning, every platform will experience fragmentation. Apple does a pretty good job at mitigating that effect because they control the platform from top to bottom. Google let the main Android experience get out of hand because they have been controlling very little in the grand scheme of things. Why have they been controlling so little? Marco Arment writes:

Nobody “opens” the parts of their business that make them money, maintain barriers to competitive entry, or otherwise provides significant competitive advantages. That’s why Android’s basic infrastructure is “open”, but all of Google’s important applications and services for it aren’t — Google doesn’t care about the platform and doesn’t want it to matter. Google’s effectively asserting that the basic parts of a modern OS — the parts that are open in Android — are all good enough, relatively similar, and no longer competitively meaningful. Nobody’s going to steal marketshare from Google by making a better kernel or windowing API on their competing smartphone platform, regardless of whether they borrowed any of Android’s “open” components or ideas derived from them. But Google’s applications and services are locked down, because those are vulnerable to competition, do provide competitive advantages, and are nowhere near being commoditized.

Unfortunately, Google spent the last few years letting Android's core experience go unchecked, allowing the carriers to decide whether or not to use Google's applications and services, and whether a certain phone gets an update or not. Google hasn't been giving Android a chief place in their bottom line, they've let carriers use Android to pump up their bottom line, and have been sticking it to customers.

It all comes down to this: let the end-user be your customer, and use the carrier as the channel; or let the carrier be your customer, and the end-user is the channel.