kickingbear

Apple announced its Push Notification system during the 2008 WWDC Keynote, pitching it as a more efficient alternative to allowing third-party apps to run in the background. It was scheduled to ship in September of that year but didn’t actually reach customers until iPhone OS 3.0 was released in July, 2009. The delay was attributed to taking an additional six months to re-architect the system to make sure it was scalable.

Recently, at WWDC 2011, Apple said that it has delivered over 100 Billion push notifications to iOS devices. Of all the numbers they tossed out during that presentation that was the one that surprised me the most. 100 Billion is an order of magnitude greater than what I’d have guessed if I’d been asked to aim high in my estimation. It would appear that taking their time and doing it right has paid off for them again.

The interesting thing about Push Notifications is an implementation detail. Third party applications are, through a combination of operating system and App Store policy, prohibited from keeping a persistent connection to a server. iOS maintains just one persistent connection in order to reduce battery drain by using the CPU and radios as efficiently as possible. Ostensibly this connection is for the timely delivery of Push Notifications to all iOS devices. In reality this connection serves as a communication channel to every iOS device with a network connection. The Push Notification infrastructure allows any iOS user to be addressed individually, across all their registered devices, with a remarkably minimal latency.

Let’s consider a few magical features and think about how we’d implement them if we were Apple.

(NB: This is an extrapolation from publicly available information, I’ve not tested, reverse-engineered nor do I have any direct insight or knowledge about how this stuff works. If I did this entry would just be a photo of a kitten.)

The “Push Notification” persistent connection enables:

• Push Notifications. In badge, sound and text flavours.
• Find My iPhone. Asks the device for its position and provides for sending a message, locking or remote wiping a device.
• FaceTime calls. Works with iPhones, iPods (let’s drop the ‘touch’, iPod Classic is dead) and iPads. Oh, and now Macs.
• iBooks bookmark syncing. Transparent and works across all iOS devices.
• Enterprise Wireless Configuration. iOS provides a mechanism through which enterprise customers can remotely reconfigure the devices they have in the field. It’s all very boring until you think about how that might work.

So there’s a fair amount of functionality we take for granted in iOS devices that’s already being provided over this one persistent connection. Not all of these features are likely to run entirely over the persistent push connection, but it is the control line that kicks things into action. iOS 5, and the set of services branded as iCloud, seem set to blow this pipeline wide open.

Whenever I type iCloud I’m sorely tempted to place it within quotes. I don’t believe iCloud is any more of a definable thing than OS X or iOS — I believe it’s collection of services that are well suited to work together and, more importantly, will be presented under one technical and marketing umbrella. That may seem like an odd take but, really, iOS and OS X are complex stacks of technologies that come together largely through the application of an editorial, or at least cultural, voice. From what I can tell iCloud is similar in that regard. There is no singular aspect to iCloud — it’s a collection of services, nicely abstracted, upon which third parties can build. From what I can tell the system that was set up to enable low latency Push Notifications is to iCloud as the Mach microkernel is to iOS and OS X. It is the enabling base for the greater system built atop.

There are three major new components atop this infrastructure that have been introduced under the new iCloud branding: ubiquitous short-form state (similar to iBook bookmarks), ubiquitous document sharing and coordination (long-form state) and iMessage. Each of these new features tickle the persistent “push” connection and trigger some action on the device. The short-form state may be transmitted immediately and set on any connected device within moments. Document syncing is likely to trigger a negotiation process to compare the state on any one device with The Truth stored on Apple servers and replace the document on the device with the latest revision — this has the advantage of limiting the window between syncing where conflicts are most likely to occur. iMessage piggy-backs on the persistent connection, and I’d wager on some of the infrastructure set up to service FaceTime, to provide a very low-latency text-chat-with-in-line-attachments environment. I’d bet that Mail could pick up a few new tricks like updating Read Counts that the standard IMAP protocol doesn’t support well.

Of all the announcements at WWDC 2011 iMessage struck me as the most immediately important. It is obviously a swing at RIM’s BBM (BlackBerry Messenger) which I’ve previously argued is one of the last true core attractions to RIM devices. BBM was never mentioned on stage but the comparison is obvious to everyone. If iMessage works as advertised, and I believe it will, then the network-effect will start to play against RIM and they’ll have lost their last leg — BBM was never about BBM it was about a chat network between friends that was secure, free, more immediate and gave better feedback than simple SMS messages. iMessage looks set to deliver upon all of that, even covering arguably annoying cases like providing read receipts.

I find iMessage so intriguing because it builds upon an existing infrastructure, it duplicates or betters a competitors approach and it’s not something I’d have expected from Apple. Now that it’s here it feels like an obvious move, but I’d not have predicted it. There are major ramifications for Apple, and their users, with iMessage.

First, and the one most talked about, is that iMessage is an obvious thumb in the eye of carriers. There’s a certain glee to sticking it to the carriers, no one likes their carrier — they are suffered. But iMessage makes each iPhone on a carrier’s network less valuable. No longer do iPhones in the field represent potential income from SMS charges. Furthermore springing iMessage on the carriers telegraphs that Apple will, at a time it chooses, ditch tradition and move to a purely Internet driven solution. If you’re a carrier then this has to be unsettling. I’d expect some tougher negotiations for Apple ahead and more love for Android devices as a play to offset Apple’s advantage.

The second major ramification I can see with iMessage is that it places Apple, for the first time, squarely in the sites of politics. No longer are iOS devices just end-points for communication, with iMessage Apple will become a major carrier of information. Recently Apple was called out by the United States Senate over location logging, one has to wonder what sort of political kerfuffle will arise once Apple starts distributing a non-inconsequential amount of chatter. We’ve seen RIM be called upon by foreign governments to either censor or allow access to their messaging systems. For the first time I can think of Apple is placing itself in a position, intentionally, to which there are very few good outcomes. Internet driven companies, like Google or Facebook, have had to deal with this sort of thing and have done so with varying degrees of success. This is something new for Apple though and I’ll bet it’ll be a bigger story than the hissy fit the carriers are going to throw.

All of that said, that’s just the side-show. The interesting thing, to me, is how this is being built. As far as we can tell all of this sits atop the operating system managed communication channel. Updating short-form data (iBooks syncing), triggering more complex actions (FaceTime), negotiating document changes, all of this is driven by one central service which the OS can manage efficiently. And that’s the real trick, iCloud isn’t a bunch of processes running on your phone that sync up with a server and each other, it’s a system level service that benefits from being that low level. The differentiator between “iCloud” and competing platforms plays exactly upon the strengths of the iOS platform: Apple runs the show and third-party developers do as they’re told.

iCloud builds on a single, high capacity, short message distribution system. Apple has called it “Push Notifications” before but, really, there’s a lot more to it than that. The advantage Apple gains from this isn’t apparent if you’re looking at software checklists — I’d bet there’s an Android announcement in a week or so that claims all the features iOS 5 promises. The thing is this, and it’s an important thing — always bet on the technologies that scale. When OS X launched Apple bet on improved GPUs and the ability for graphics hardware to back each window. That was a great bet, Microsoft took a few years to catch up with that move. Apple is now betting that multiple applications maintaining their own connections to disparate servers will end up performing poorly on mobile devices. I believe they’re right. Betting on batteries improving by orders of magnitude is a poor bet. Betting that radios will somehow cost less power to broadcast and receive is also a poor bet. Apple has bet on consolidating these costs into a single, well defined, and manageable system. An “open ecosystem” can’t possibly match the efficiency of such a set up. We’d need to see battery life become a non-issue and some incredibly compelling applications before alternative platforms could become a threat.

The truth is that there are cold, hard limits to what can be done with portable devices. We’re too often tempted to think of them as little computers, but they’re not. The fact that they don’t plug into the wall should be a giant hint. Apple has made an interesting play with iCloud, one that will push them further into public and political discourse, and one that will set them further apart, in technical terms, from what their competitors can deploy.

This is my pre-WWDC post.

“Copland 2010” refers to a series of articles, written in 2005, and a recent episode of Hypercritical, in which John Siracusa argues that at some point down the line Objective-C and the Cocoa APIs are going to have to be replaced with more modern technologies. Failing to address this sooner rather than later, as was the case with the Classic Mac OS, will leave Apple in a vulnerable, perhaps insurmountable, position relative to their competitors who have adopted “modernized” development technologies. Apple’s last-ditch attempt to bring modern technologies to the Classic Mac OS was codenamed Copland. Siracusa hints at the severity of the situation, if his argument turns out to be sound, by calling his projected development platform nadir “Copland 2010″.

In broad strokes: Siracusa is right and Siracusa is wrong. There are two parts to the Copland 2010 argument — a statement of the problem and a call to action with some suggestions. In the broadest sense it’s basically impossible to seriously debate the merits of the problem as he lays it out. Undoubtedly, at some point, Objective-C and the Cocoa APIs will be in the dust-bin of history. At issue, however, is the time scale. It’s unfair to hold Siracusa to 2010, in Avoiding Copland 2010, part 2 he writes, “I actually think the year 2010 is a bit too early, but I didn’t want to use a date that was too far in the future”. We’ll be fair and take 2010 to mean “near future”, in computer industry terms. Let’s call it between five to fifteen years.

I don’t think it’s at all likely that we’ll see the utility of Objective-C and the Cocoa APIs become totally eroded over the next ten years (the argument was first made in 2005, so we’ve used up five years of the near future). I do think it’s likely that during that period it will become more and more apparent what the next big thing is — where the industry is going. I don’t, however, think that any of the popular “modern” languages fit any better with the future of computing than Objective-C does. We’ll revisit this point.

Siracusa, during his Dark Age Of Objective-C episode of Hypercritical lays out the following criteria for a modern language:

• Automatic memory management
• Native strings
• Regular Expressions native (but a library is acceptable)
• Native object system
• Named parameters
• Succinct syntax for common operations
• Acknowledgement of concurrency
• Single vendor driving the development

I agree with most of these, as I think many developers would. We could quibble over the weights we assign to each but, by and large, that’s a decent list. Let’s use it as a score-card for modern Objective-C.

✓ Automatic memory management
Objective-C 2.0 can be garbage collected.

✓ Native strings
Objective-C has @”" strings which are mapped, via a compiler option, to NSString instances. If the requirement is for special operators to work on strings then I’d argue that’s actually an issue of not having a “succinct syntax”.

½✓ Regular Expressions native (but a library is acceptable)
Regular expressions are not native to Objective-C. There are libraries available and, as of iOS 4.0, Foundation includes a regular expression facility.

✓ Native object system
Objective-C has a native object system. Note well that Siracusa was not saying that everything had to be an object, he was referring to prototype based languages like Lua or JavaScript where developers roll their own inheritance systems.

½✓ Named parameters
The Objective-C message sending syntax provides half a solution to this feature. Ideally, one would want to simply name their parameters, omit any that aren’t required in the call, and have it all just work. While Objective-C doesn’t go this far it does go far enough to significantly increase the readability of any given message send.

𐌢 Succinct syntax for common operations
This is a nice feature that has the potential for utter ruin. Too far down this road and one re-creates the C++ operator overloading insanity. Not far enough and we’re stuck typing an awful lot of code. Objective-C has many merits but being succinct is not among them. I would be happy to see some syntactic sugar added in future versions so that boxing basic types and creating arrays and dictionaries required less code. While verbose code makes it far more clear what is happening too much verbosity can distract from the intention by flooding the page with needless detail.

✓ Acknowledgement of concurrency
With the addition of blocks and Grand Central Dispatch Objective-C Cocoa not only acknowledges concurrency but is ahead of most of the pack on this one. Yes, it’s true — GCD and blocks are not actually Objective-C additions, they are built into the C layer. One could argue that Objective-C itself doesn’t address concurrency directly. I’d point to @synchronized and then tell you that being able to pick up on improvements to the C level is one of the great strengths of Objective-C.

✓ Single vendor driving the development
For all intents and purposes the only entity that matters in the Objective-C / OpenStep / Cocoa world is Apple. They are the tastemakers, the architects and the largest consumer.

So, modern Objective-C scores 6 points on a possible 8. Not too shabby. The only area it totally missed scoring on was in being succinct and the fix there isn’t one of doom and gloom, it’s one of implementing some relatively simple syntactic sugar. Without knowing for a fact I’m quite sure this sugar doesn’t exist because Apple largely tries to keep Objective-C distinct from the Cocoa frameworks. There’s not a lot added to Objective-C that’s specifically Cocoa flavoured — @properties with retain / copy semantics are the only thing that comes to mind.

Since Copland 2010 was originally written Objective-C has gained, by adding concurrency and regular expression support, 1½ points on the Siracusa Scale and I believe it is well positioned to pick up another half, or even full, point by adding some syntactic sugar that wouldn’t invalidate older code. Scoring 6 out of 8 now with a good clean shot at 6½ to 7 within a few years is hardly a disaster in slow-motion.

Consider the troubles the Classic Mac OS had. It had no memory protection so any process had, and in many cases relied upon, the ability to read and write to other process’ memory spaces. It had no pre-emptive multitasking which meant that any process could refuse, either intentionally or via a bug, to relinquish control of the computer back to the operating system and other applications. These are two fundamental underpinnings of modern computing and Classic Mac OS didn’t have them and, worse, had made, explicitly or implicitly, promises that developers could depend on the traits and symptoms exposed under such a model.

Objective-C is not so similarly hemmed in on such vital ground. For the most part Objective-C has managed to take on-board what I would argue are the two key technologies for the next few years: garbage collection and concurrency. Now, one can argue how usable Garbage Collection is right now with relation to the frameworks and existing code and one could argue that GCD isn’t a first class concurrency abstraction. And, sure, perhaps there are some points to be scored in either of those arguments. But it’s possible to sit down and write an Objective-C application today that is garbage collected and is highly concurrent by leveraging blocks and GCD. With the controversial dot-notation one could argue that even the succinct syntax deficit is being addressed. Certainly @property and @synthesized and the new ability to not even declare instance variables are all indicative of a direction to reduce the amount of boilerplate a developer is required to write.

Five years in from the near future of 2005 and we find Objective-C fairing quite well, and it’s become more apparent where further improvements can come from. Given all of this do I predict a crisis within the decade? No, I don’t. A decade is a long, long time in computer industry terms and I’ve no doubt I’ll be surprised by many of the changes to come — I just don’t believe that Objective-C has any obvious handicap that will prevent it from taking advantage of them. Indeed it’s possible, as with the iPhone, that Objective-C may find itself being able to cover enough of the sweet spot between lower-level pedantry and higher-level abstraction that it remains suitable for use in surprising ways.

Let’s set the argument that Objective-C is still viable aside for now. Let’s take the Siracusa position and accept that, eventually, we will need to transition off Objective-C. Because one day we will. The question then becomes — what do we do now?

Siracusa argues for a move to a more “dynamic” language. Probably something interpreted, something that scores an 8 out of 8 on the Siracusa Scale, something that is not bridged to Cocoa APIs but is the basis of those APIs. I don’t disagree, I think such a thing could be nice. Where we disagree is that I see Objective-C providing much of that right now and seeing potential in the future while he sees a need for a re-write.

When Windows 1995 was introduced it was, despite the ads Apple ran, the end of the road for the Mac OS. Windows 95 had many, many problems. I wrote a lot of lower level code that had to run under Windows 95, believe me, it had problems and would crash and burn and reboot and be a bitch. At home I preferred OS/2 and then Windows NT 4. Classic Mac OS had serious fundamental problems that were insurmountable fifteen years after the launch of the Macintosh. While there’s a lot of nail biting about this I see it as a real achievement — the Classic Mac OS, designed in 1984 as a cheaper, faster and more nimble version of the Lisa and the Xerox stuff, managed to last until 2002. A feat so impressive that I’ll go out on a limb and say it was the only piece of software that ever got a coffin and a funeral service.

By the late 90′s is was abundantly clear where computers where going: memory protection between processes, pre-emptive multitasking, advanced graphics capabilities and the Internet as a constant. Classic Mac OS was poorly positioned to provide any of these things. Many popular applications, and indeed the way the operating system switched tasks, relied upon there being no memory protection. There were applications that could be made to be fantastically responsive, such as audio apps, because they could deny any other process access to the CPU while they were busy. Despite having been the early leader in graphics by the late 90′s it had become apparent that the QuickDraw model was up against its limits and would require a reboot. With regard to 3D graphics the Macintosh, of that era, was woefully unprepared to deal with the revolution in GPU acceleration and rendering. The Classic Mac OS was hitting the wall on almost every front all at once.

This was apparent to Apple at the time. They’d started a number of projects but Copland is the most famous among the Mac crowd.

Copland was an attempt to fix the sins of the Classic Mac OS while retaining as much backwards compatibility as possible. Copland had a form of protected memory, preemptive multitasking, a new QuickDraw GX, and on and on. It was a full frontal assault on each and every bullet point that could be counted against Classic Mac OS.

It was a total failure and a largely unmitigated disaster. Its failure was so bad that at one point Apple looked into licensing Windows NT, then looked at buying BeOS and, finally, bought NeXT and that’s where we are today.

Siracusa worries that Objective-C is the weak link in today’s Apple technology stack. One day I suppose he may well be right. Here’s the thing though, and it’s the second part of the Copland 2010 argument — Siracusa suggests a complete, from the language-ground-up, re-write of the frameworks, and by implication the entire user level of the operating system and all third-party applications. If anything screams “Copland” to me it’s the suggestion that we all engage in a ground up reboot without really knowing where we’re going.

The Siracusa Scale is decent but, as I mentioned previously, I believe the weighting of each factor is up for debate. If one can write code that is asynchronous across dozens of cores yet requires you to write less succinctly which factor is to be favoured? I have an opinion on that and, as you may’ve guessed by how much typing I’ve done to make this point — I value the ease of leveraging multicore assets over the brevity of my code, especially when such brevity may simply make my code more obtuse.

Given what I’ve seen I’d predict that computers are going to move to be more heavily multi-core and distributed. Like betting on Quartz in 1999 because it could eventually be backed by GPU textures seemed like a given (see CoreAnimation for a re-do once the realities became apparent) betting on many cores seems obvious now. I don’t believe that the Siracusa Scale weighs this probability correctly. Simple, accessible, multi-core code will, I believe, be the most important facet of language and API design in the near future — starting now, give me fifteen years. It is my belief that Objective-C, with garbage collection, sitting atop a blocks and GCD enabled C substrate is in a terrific position to make the most of what is to come.

The Copland 2010 argument presupposes that the problem space is going to change drastically below the technology developed to service it. By that I mean that the Classic Mac OS was developed to service the requirements of a single user working in a single application at a time. Computers evolved and the assumptions behind the Classic Mac OS changed drastically. Eventually there was enough change that, by 2002 according to Apple, it was dead.

Here’s the thing with Objective-C and the Cocoa APIs — I believe that UIKit and AppKit (well, mostly) are well enough abstracted that they can serve their purpose for many more years. Ultimately, when dealing with an an interface API the permutations are limited to what can be expected from a given user control. Making fancier and more syntactically efficient ways of expressing the same behaviours encounters the problem of diminishing returns. Back in the Win32 / Classic Mac OS / PresentationManager days this might have mattered. The Cocoa APIs basically simply ask the developer to fill out a form when they’re asked to do so. I’m not sure how much more higher level and abstracted one can get without relinquishing control of how the data is displayed. I think Cocoa has largely nailed a sweet spot between the en-vogue 4GL languages of years gone by and the explicit configuration of other methods.

So, in the end, while I appreciate the thinking behind Copland 2010 I don’t believe it’s quite the issue Siracusa believes it is. Objective-C continues to evolve, and in directions I believe will be increasingly important in the future. I don’t believe we’re anywhere near the level of crisis that Apple hit with Classic Mac OS and I don’t believe that a total second-system re-write without a clear goal is the best prescription for the platform.

Ultimately, I believe the future of languages, APIs and computing is likely to move towards massive parallelism. I’d even predict that parallelism by task is the ultimate future — compute tasks will be routed to the component best suited to handle the request. Massive parallel computations might be handed to a GPU style device, simple math and branching handled by a CPU core and location refinement handled by something entirely different. Siracusa argues that abstraction is the all consuming beast of computer science, I think he’s mostly correct but I can’t help but feel he’s more worried about abstracting yesterday’s issues than tomorrow’s.

My money is on “asynchronous encapsulation of independent computation”. Now that is an abstraction — but it’s a more refined guess as to what the future might hold, and it’s one that I believe leaves Objective-C and Cocoa in good shape for the near future.

Don’t worry. Be happy.

It’s one word with an exclamation mark followed by a list of dated quotations from various sources running back through the past seven years. It’s the most on-point, refined, minimalistic yet communicative piece of writing I’ve seen. You don’t need to read it, you absorb the point by how long it takes to scroll through it to get to the punchline at the end. There isn’t one. Using even one more word to explain or expand upon the joke is uneconomical. “Wolf!” is concision enabled by a common understanding. It’s the eye-roll between friends where the friends are everyone who can read. Brilliant stuff. The fewer words that writer uses the better the reading gets. This has to be the sweet spot.

Here’s the thing about the story of The Boy That Cried Wolf though. We all know the story, it’s been handed down as a parable for countless generations. It goes like this: a boy is tasked with tending a flock of sheep for a village. Lonely, he cries “Wolf!” for attention. After a few times of doing this the villagers stop responding. Eventually a real wolf arrives and eats the boy and all the sheep. Moral of the story: don’t tell lies because when it’s real nobody will believe you.

Here’s an alternate perspective on that story: bored by false positives the villagers stopped investigating possible failures and as a result lost a young boy and all their sheep. If you’re a developer think of this as letting a bunch of warnings get past you in your code. One day one of those warnings will kill your application dead and you’ll say to yourself, “I really should’ve paid more attention to all that screaming”.

With regards to the security issues at hand: I’m with Gruber and believe the current issue is overblown and, yes, there’s been a constant refrain of fear mongering about this kind of thing. That said, every new potential threat should be taken seriously and steps should be devised to counter it. There was a new kit released recently that’ll make creating Mac mall-ware easier than ever. The holes it exploits should be considered grave and addressed as quickly as possible. In the story of the Boy That Cried Wolf the village ultimately paid the price for not being vigilant. The interpretation has always been to take it as a parable to improve personal behaviour but what I enjoy most about that tale is that it works both ways — there are two parties at fault: the attention seeker and those who took the cognitive shortcut of disregarding what the attention seeker was saying because they’d been wrong in the past.

As a whole, despite not being very communicative or responsive, I don’t believe Apple disregards this kind of thing. It’s my belief that one is able to write a piece titled “Wolf!” because we’re still at the stage were this kind of report gets a response. Slower, perhaps, than many would prefer, but still, it is eventually addressed.

I really liked this piece at Daring Fireball but the ambiguity of the statement troubled me. Yes, these people are likely calling “Wolf!” without it really being a threat — but how much have the previous threats been diminished by the townsfolk showing up with torches when called upon?

My argument, in a nut, is this: as a customer you’re more than likely ok to ignore these dire prognostications, as one of the people who is tending the sheep this kind of thing should be on your mind and be something you aim to address quickly.

Crying “Wolf!” too much bites both ways — the crier ends up looking like an idiot until they’re right and then the whole village loses out.

Something, something, broken clock, huzzah.

You’ve heard of the kerfuffle surrounding a log file on iOS 4 devices whose entries contain, troublingly, time and position data. I know you have because I have. Ever the good son, I enjoyed a coffee with my mother this afternoon and she asked me if I’d heard about it. There’s been an awful lot of opinion pieces written about this mis-feature but I’m with Dan Moren and his Don’t Panic argument.

I’d chalked up these revelations as a Molehill-cum-Montain issue. Looking at the data involved I had a high degree of confidence that this was either a bug or an oversight. I could envision technical reasons for this caching and engineering reasons for why it might be accumulating either longer than expected or even why just not caring how much backlog was kept might be a valid trade off in terms of engineering time spent on the problem.

I had opinions on the matter but none that wouldn’t be ably covered elsewhere and so had no plans to comment. Then I came across a piece at Talking Points Memo, an American political news blog, that said Senator Al Franken had written a letter to Steve Jobs asking for the specifics of the situation.

My initial impression, as I wrote to a friend privately, was, “Man … someone is going to be working this weekend!” The letter read as sincere, concerned and to the point. Naïve from a technical perspective perhaps but, ultimately, on point and crystallized the sort of questions the public was asking either through the media or through citizen soapboxeries like Twitter. By “someone” I meant the segment of Apple that comprised the engineers who’d written this code and the public relations and management people who would no doubt be rushing to understand its details and the decision making process behind them. All these people were probably already at red alert due to coverage of the issue in the New York Times and on CNN. A concerned letter from a US Senator would’ve moved them all to the even more serious state of Redder Alert. The morning of Good Friday will see a bunch of people locked up in a cave who won’t re-emerge until Easter Monday with a fix in hand and some great messaging.

Still, I had nothing to say about the subject because, really, what’s there to debate?

And then, a very smart fella called another very smart fella an idiot on Twitter. “Kontra” (@counternotions) took issue with the tone of Senator Franken’s letter. You should read our conversation here. I don’t know Kontra personally but he seems like a sharp guy with a good understanding and an ability to communicate it. Arguing with someone you don’t know personally on the Internet is almost always a bad idea so I dove in.

The debate here appears to centre upon the role of a government in society. Should a government move to quickly and publicly secure answers from a business when there’s a possible danger to the rights of its citizens, or should the government defer until they’ve secured more data and inquire discreetly in order to engender a social environment less tumultuous for businesses?

I’d err on the side of a government calling out business shenanigans where it may see them. There is an argument to be made that uninformed media or government intervention and inquisition into a business may hinder it’s ability to innovate or even unfairly punish it for small oversights that are blown out of proportion. My position is that Franken’s questions don’t create a sufficient “chilling effect” that the damage done to the citizenry via the potential damage to Apple, Inc via lost sales outweighs the potential damage to the privacy rights of the citizenry that the Senator is concerned about. What if he is wrong and Apple loses a few sales? We won’t care once it’s time to bash on the next thing in the news cycle. If there is a privacy issue here concerning millions of iOS 4 customers then there’s some serious potential damage to the privacy rights of millions of citizens.

I’ll bet Senator Franken will have a set of answers to his questions by next week. His concern is, I believe, misplaced. On that point I believe Kontra and I are in agreement. But is worrying that untrusted code executing on a Mac or iOS device being able to steal a time-stamped log of where you’ve been “idiocy”? No, not at all. That is a genuine concern. Is it more of a concern than nefarious code reading your text messages or email? No, probably not. The thing is that just as people will download a movie and excuse themselves for not stealing anything “real” they perceive a breach of email accounts as awful but less horrific than some third party knowing where they are, physically, in the real world.

At the end of the day this location data may not be as important or as telling as some other personal data but people relate to it far more intimately. There’s a reason beyond it simply being related to Apple that this story gained traction. The idea of being tracked, as a human, is very scary stuff. The ancient sort of scary. The sort of scary that wiggles down subconsciously to the fight or flight level of reasoning.

So, though I’m an Apple fan, I think that Senator Franken asking Apple a few questions about why there’s an obviously overly long location log on their phones trumps the extra thousand or so units of iOS 4 devices Apple might’ve moved without this bad publicity.

That said and done, no one has yet asked the really interesting question — if this had happened once Apple was shipping an iOS device that backed up automatically to an Apple server how much more of a shit storm would this have been? A very shittier shit storm is the answer. I’ll bet there’s more than a few managers who’re thinking very carefully about how to make damn sure they don’t have to spend an Easter weekend working to prove to Stuart Smalley that they’re good enough, and smart enough, doggone it.

Well, let’s just call it. We’ll do it with The Globe And Mail, RIM home-turf, running this piece: RIM’s PlayBook gets rough early reviews opening with this line, “The initial verdict for Research in Motion’s PlayBook is in — and it’s generally not good.”

That’s just embarrassing. For me. Here I was thinking they were getting something to market to get back in the game. Here I was thinking they were picking up a great base OS in QNX and leveraging AIR to get a decent, or at least better, application development layer than they’d have been able to field otherwise. Here I was thinking ditching essentials like a mail client and a calendar was because they didn’t think they’d get them to their quality levels in time and they were happy with just getting something decent out there that they could iterate on. Here I was thinking RIM was trying to do what Jack Gruber explains Apple does: roll.

From the reviews it seems they’ve spent some time rolling around in it all right.

If you’re going to cut back on features and be late — make sure you’re good for what you are. The fallacy is that competitors need to ship a product that beats iPad in it’s first iteration. They don’t. They need to create a device that addresses a few problems better than iPad can. RIM had a clear niche there — integrating a tablet into the corporate infrastructure they’ve spent a decade dominating. Cut corners, hell, assume a BlackBerry companion if you need to, but know what your product is. Make it well and ship it with confidence that it’ll address the needs of the customers you’re targeting, even if that’s a smaller subset than you’d ultimately like to reach. Shipping a product that helps ten people is better than shipping a product that gives one thousand people a hassle.

RIM was in a position to do that. A nice custom OS with AIR atop it. Integrate it with corporate backends and BBM. Tell “Enterprises” they can let their “Web Guys” build custom AIR apps that don’t need to jump through any hoops to be deployed — there’s some traction there. Maybe not much, but what do you expect when you’re years late to the race? Pick the sure footing. Sprinters use a starting block for a reason, it’s a good solid launching point that can be leveraged to gain an initial thrust. Muddying your position, and product definition, won’t get you anywhere quickly.

You know who actually did that bit well? Microsoft. Windows Phone 7 was well received, competent, reasonably polished and missing a lot of functionality iOS had already had time to grow. That was more or less forgivable though. People asked where Copy and Paste was but it didn’t sink the product out of the gate. For what it was — it was good, and that still engenders some respect. Where Microsoft dropped the ball was in updating it. The whole key to starting with the essentials and rolling with it is in the momentum. The Windows Phone 7 team, for whatever reason, never developed momentum and I’d guess they never will.

Anyway, I stuck my neck out for RIM there thinking they’d ship something small but competent. Early evidence is proving me wrong.

Nice job, RIM, you’ve made me look like an asshole.

Too much time is spent talking about attention to detail in user interface design. Forget that. Or at least let’s all agree to take it as a given, a prerequisite.

I’ll lay this out simply: when things are static our brain will pick out the details, when things are in motion we’re in tracking mode and the details escape us. This is the order of things and it’ll likely be a very long time before that changes.

This is one of the truisms baked into the earliest GUIs. On the oldest Macs you’d double click to open a document and a zoom rect would appear to illustrate that an action was in progress. If you dragged a window, on Mac OS or Windows, you’d drag a simple outline. The developer-designers (that’s how it was back then) understood that the immediacy of dragging an outline was more valuable than slowly dragging the object itself. Given the trade offs of the time they were correct.

If you think this is a quaint notion, read this piece in mobile Safari and double tap this column of text to zoom it to fit the screen. Did you see what happened? The lower resolution rendering of the page zoomed to fill your screen and was then replaced by a higher resolution rendering once the transition was completed. This is the modern zoom rect and is enabled by leveraging the extremely fast graphics hardware we enjoy today. What started as a way to quickly render brown wall textures in a 3D shooter is now being used to make interacting with an obnoxiously binary device feel like a more natural, analog affair.

There’s a long litany of effects I’m tempted to dive into here. From the old NeXT window server full-window drag, to OS X fully buffered windows and the Minimize to Dock effect and to Core Animation and iOS in which all content is backed by a texture. I’ll dodge that for now because it’s too rich a history.

If you write interactive software know this: fluidity of motion is more important than accurate rendering, once a scene is static fidelity is paramount.

To boil it down, your take away is: drop fancy rendering effects to achieve the most fluid interaction possible.

If you’re using iOS or Core Animation you’re doing this already in more places than you’d guess. Keep this technique in mind when dealing with your own interaction issues. You can labour endlessly to make accurate rendering as fast as possible or you can appreciate how people perceive things and end up with the best possible interaction.

Always implement the simplest possible solution that fits your understanding of the problem space modulated by your anticipation of the inputs you’ll be dealing with.

This may sound like a re-statement of the K.I.S.S. principle but it’s not — it’s more robust than Keep It Simple, Stupid and is self justifying in the following way: The added complexity of parsing this rule is worth the sacrifice in communicability in order to more accurately express the argument behind it.

The “KISS Principle” is often rejected by those who know better. Their experience in a field has taught them that the simplest possible solution is likely unsuited to any amount of serious usage in the real world. They then abandon this principal and resort to implementing along lines that too often show signs of Second System Syndrome. The resulting code being heavily influenced by what they’ve done before only, this time, improved upon by the lessons they’ve learnt the first time they wrote something similar.

These people are smart and are learning from the mistakes they’ve made in the past. Anyone worth their salt should be at this self correcting level. But there is, as always, another level beyond that.

I call this next level the “Fuck It” level, though that may be too technical a term for some.

Achieving the Fuck It level entails knowing the problem space well enough and understanding the limits of your inputs well enough that you can gauge how complex an implementation will be required to match the requirements you’ve been given. Many nerds come to believe that their task is to come to the most optimal solution given the input and the hardware. That’s cool, they’re nerds, they do that. The actual task is to come to the best solution that suits the requirements in the shortest amount of time. That’s what your manager wants and that’s what the company wants. Where you shine, as a fancy pants and experienced engineer, is in doing exactly that while leaving yourself wiggle room to get more performance and more features out of what you’ve written once they come back to you for more. The trick is never in building the best possible implementation — the trick is in building the implementation that will provide the best possible future. The best possible implementation changes from year to year according to hardware trends or the software you’ve build upon. The implementation that will provide you with the best possible future changes far less frequently. When you understand the problem space well enough you’ll be able to define the implementation accordingly. When you do, implement the simplest possible solution you can and leverage the abstractions you’ve built from your experience to give you as much wiggle room to change things the next time out.

Details change quickly, patterns change slowly, your code base is glacial. Make it broad and adaptive and don’t overly tax yourself fitting into the cracks.

Every year I mean to take the time to note how the leaves grow on the trees around me and how the plants spring back to life. This year I’ll be making a real effort. I’ll be using Everyday to remind myself to go outside and take a photograph of the tree behind my place from my balcony. It will ask me to align my nose and mouth and I will laugh at it as I choose to align my photos with the branches of the tree.

And that’s what you’ll be doing too. We are all going to agree to take a photograph every day of our favourite plant or tree as it starts to recover from being depressed about just how stupidly cold the world can be at times. We will then share these with each other and the collection will be a wonderful crowd-sourcing of spring time happiness.

So, download Everyday and get to work. When you upload your series of photographs email the link to me at spring at kickingbear dot com. I will collect them and we’ll work out a great way to share them. No, I’m not sweating the details. It’s spring, have some fun.

For myself this is a deeply personal project. Each year my favourite tree grows slowly, its foliage gradually fills out and, in doing so, robs me of enjoying the sun as I relax on my deck. My photographs will be documenting how much of an asshole this thing is so that when I chop it down the judge will understand. Some of you may have more positive and happier motivations though. And I suppose that’s ok too.

As you’ve no doubt heard by now Google has been making moves behind the scenes recently to constrain Android development to changes that it approves. This is no doubt in reaction to the threat that competitors such as Amazon and Facebook may come along and effectively hijack the platform out from under Google. From Google’s perspective this decision makes sense. From the perspective of the hardware makers and others who have bought into the “Android is Open” meme this is terrible news.

With that as a background let’s do an asset check on the players in the field:

Apple. They’re laughing. Honestly, probably literally laughing at this news. They own their own hardware stack and they own their own software stack and as Matt Drance pointed out in his brilliant inaugural Apple Outsider piece — Apple loves to control its own destiny.

Google. They’re feeling defensive. They set out to make an open platform and I’d bet they’re feeling the sting of all that rhetoric coming back to bite them in the ass. Of Google executives John Gruber writes, “Andy Rubin, Vic Gundotra, Eric Schmidt: shameless, lying hypocrites, all of them.”. I think that’s too harsh. It implies a premeditation I’m not sure is obvious from the facts. I think they’ve ended up throwing out their (they claim) principled stand on being open once it was apparent it wasn’t going to be totally in their benefit. It certainly calls into question their trustworthiness but I don’t think, in this case, that malice trumps stupidity or self-preservation.

HTC, Samsung, LG, et al. They’re pissed. They own their own hardware stack but do not control their software stacks. This turns them into commodity vendors that will be played against each other in order to gain the favour of their software platform provider. They’ve become the Dell, HP and friends of the smart-phone space. Google now wants to make each of them its bitch. If they’ve got any sense tonight their execs are having a stiff drink and re-watching Oz.

Microsoft. They’re laughing. They’re probably actually quite giddy right now because this means that Windows Phone 7 will be on a more even footing with Android in terms of licensing. If Microsoft can manage their relationships with hardware suppliers better than Google can then they stand to gain some real traction. This plays in Microsoft’s favour — they’ve been managing relationships with hardware vendors for decades, albeit often abusively. Still, experience counts for something.

Nokia. I don’t think anyone at Nokia laughs much anymore. I’d guess they likely feel relieved. They took a lot of heat for electing to go with Windows Phone 7 just a few months ago and now that decision doesn’t appear quite so suspect. Perhaps they are still a commodity hardware vendor for Microsoft but you can bet they’re the preferred commodity hardware vendor. If, say, Facebook cut a deal with Microsoft for Windows Phone 7 customization then Nokia is in a good place to be the hardware partner there.

RIM. Despite being laughed at constantly today, RIM laughs too. They own their own hardware stack and they own their own software stack and as I pointed out previously — they are maintaining control over their own destiny. Which they’re doing like a drunken sailor on three day shore-leave but, still, that “2 CEOs & 4 Eva” tattoo is their choice.

It seems I’ve adopted RIM as the player I’m going to stick up for. Whether that’s because I’m Canadian or because I’m a contrarian I’m unsure but I do feel more positive about them than pretty much anyone else I see commenting on the situation. When I first expressed my thoughts on RIM my argument was essentially the following: they were caught flatfooted by iPhone and they know it; they are talking to remain relevant in the eyes of their major purchasers; they are buying or adopting technologies they believe will give them a better footing in the future; they are doing so without ceding control over their own destiny through adopting a third party software stack. I predicted their end game would be a controlled exit from the smart-phone and tablet space and I suggested that they were looking for ways to gracefully cede that space to Apple while squeezing a few more bucks out of it.

Since I wrote that piece in early January there have been more changes. First, the news came out that it appears that RIM is turning away from the smart-phone market. Also, RIM has said even more dumb things. The latest news is that they’ll be throwing in a Java runtime atop their PlayBook OS in order to support running Android apps. Their waffling, obvious lack of a vision for the PlayBook product and the fact that they’ve got two CEOs and three COOs are all indicative of a company truly in trouble. Yet today we’ve seen these poorly communicated and arbitrary seeming decisions leave them unaffected directly by news that has changed the fortunes of everyone in the industry other than Apple.

Hey, I hear Facebook and Amazon are looking for platforms to customize. I hear that QNX has (I’ll say this as politely as possible)had a few partners. I hear that RIM makes some pretty good hardware and knows their way around the telecom industry. Oh, and Exchange. And I hear Facebook knows Facebook pretty well. Maybe integrating with Exchange and having their own device and doing Facebook chat over BBM would be something Facebook would be interested in? Who knows?

Obviously, that’s speculative but it’s the sort of thing that you get to walk up to the negotiating table with when you control your own destiny. These other clowns that are taken seriously for a month or so at a time, the “hardware partners” that ship a slightly higher resolution screen with an advance copy of an OS that’ll be available everywhere (though won’t install on most hardware) a few weeks later — they’re of little interest. They have no potential to invent anything and after today that’s just even more obviously true.

I hate to keep referencing the same few articles over and over but Matt Drance points out:

Here are some big takeaways for your next slide deck. RIM has:

Very little cash

Weak Q1 guidance

No clear management structure

No clear product strategy

Drance is not wrong that RIM is in very bad shape and it’s not clear where they’re going. I don’t think they’re clear where they’re going. I do think they’re doing what they can to seize upon whatever opportunities come their way. I believe they’re in a better position than most to do so. I don’t think they need to be rescued, I think they’re up a creek without a paddle but they’re splashing their own way to shore and not taking any help from that creepy looking dude with the camera wearing a Google TV t-shirt.