⇥ Mac, oh Back to the Mac

Every time Apple announces a media event, pundits left and right launch themselves headfirst into that most pundit-like of games: offering opinions. Some throw themselves unabashedly into the “pony and rainbow” camp, happily hacking away at their wish list because they know that eyeballs are all that matters.

Some others genuinely try to analyze Apple’s next moves, but they have learned better than to hang their professional reputation on what has traditionally been a very difficult game to win. Thus, they cover their backside by wrapping their predictions in carefully crafted disclaimers, and then present them as if they were their own musings rather than predictions. This gives them the advantage of plausible deniability in the inevitable case of defeat (“well, I never said that Apple was going to do such and such”) without detracting from the gloating of the statistical victory. It’s a game we all like to play.

Now, where was I? Ah, yes, predictions for the October 20 press event. Now, I have no idea what Apple is going to do (see how I carefully covered my backend right there?), but there are a few areas that I hope they will address (and here come the wild-ass predictions masqueraded as personal musings!).

Air refresh

Almost everybody seems convinced that the MacBook Air is due for a refresh, which is only logical given how long it’s sat untouched on Cupertino’s design shelf. The Air is truly a remarkable machine—my wife owns one, and I’ve been regretting not getting one of my own. Some people have called it underpowered, but I think that the real problem is that it’s missing some important elements that would make it the ideal machine for business travel.

My friend Lex Friedman cites built-in 3G data, which obviously works well for iPad owners, and would be a godsend for those of us who have to contend with airport and hotel Internet access (and I use the word “access” generously here). To this, I would add some sort of truly portable cloud storage that we can use not just as an offsite backup and file-exhange system, but as a true filesystem replacement that follows us wherever we go and automatically synchronizes all our devices. Imagine working on a document on your desktop, then driving to the airport and continuing work on that same document on your Air or iPad without a second thought.

The benefits of a truly virtual filesystems are almost too many to list, but, unfortunately, so are the difficulties connected to a foolproof implementation. It’ll be interesting to see if Apple does anything there.

OS X Lion

The focus of the event will, of course, be on the next iteration of OS X, which everybody expects to be called Lion (because Apple said so).

Here, Apple is going to have to make some major announcement to justify the introduction of a new version of the OS. Leopard and Snow Leopard have served well as bridges to a full-on Intel implementation, but I think that everyone expects big changes with Lion. What these will be is anyone’s guess (well, except Apple’s, presumably), but I expect that we will begin to see more and more convergence with the iOS product line.

By this, I don’t mean to see that we’ll see an App Store for Mac, or a touch interface for OS X. That’s possible, but it seems unrealistic: by introducing iOS, Apple has made it clear that touch interfaces require a completely different paradigm. By the same token, if iPad and iPhone are the walled garden in which all the kids can play safely, OS X remains the amusement park where the cooler kids hang out for the thrills brought on by risk.

There will be, undoubtedly, plenty of customer-facing changes in Lion that I look forward to seeing and won’t even try to guess. I do think however, that we will see more convergence in the philosophies between these two operating systems—in other words, Apple could apply some of the lessons that it has learned from the introduction of the iPhone SDK back to its flagship desktop operating system.

Despite the similarities between the two platforms, writing iOS apps is much simpler than writing software for OS X. The SDK is, in one case, simple and elegant and, in the other, about five times more complicated than it needs to be, even for simple tasks¹. Meanwhile, the introduction of features like garbage collection and closures (or “blocks,” as Apple insists on calling them) has signalled the fact that the fine folks from Cupertino are clearly aware that Objective-C needs to evolve in order to remain competitive.

Apple’s initial intent with the iOS SDK was to create an environment that existing Mac developers could easily pick up and build upon; but they are now facing a reality in which a lot of people have started working with Cocoa and Objective-C because of iOS, and it only makes sense to try and bring them into the Mac fold by easing their transition from Touch to plain-old Cocoa.

⇥ iOS odds and ends

Over the past few weeks, I’ve started open-sourcing a number of libraries that I have, at one time or other, built for my iOS projects. Most of these projects concern themselves with simplifying tasks that pretty much every app has to deal with at one point or another, and that every iOS developer finds themselves rebuilding (or refactoring) over and over across all their products.

Some of these libraries have served me well for a number of projects and have already made their way into the App Store one way or another. A couple I have built just recently because I needed them for products that haven’t quite made it to prime time.

The reason why I chose to open-source the code is that having to write these libraries kept me from actually building cool apps—which I absolutely hated. For all its simplicity and beauty, the iOS SDK has some glaring limitations that make a developer feel like he has to build the road in front of his car in order to get where he wants to go. Thus, rather than focusing on the journey, you have to deal with such mundane tasks as parsing XML data, downloading information from the web without locking up the entire app and performing trivial 3-D animations that end up taking ridiculous amounts of code¹.

In any case, I have put the following projects on GitHub in the hopes that they will be useful to someone:

• AFKGlassyButton · Imitates Apple’s built-in glassy buttons (in arbitrary colours) without using the “officially unofficial” UIGlassButton. I built it because if my app has to be rejected, at least it ought to be my fault.
• AFKXMLReader · A document-oriented XML reader to supersede the antiquated SAX-like, event-driven NSXMLParser. With a little modification (which I plan on eventually adding, but it would really be nice if someone just happened to send me a patch), it can write XML data as well.
• AFKLoadManager · a queue-based class that manages an arbitrary number of concurrent downloads asynchronously and without overloading a device’s connection.
• AFKPageFlipper · A container that displays an arbitrary number of subviews, allowing the user to switch between them using a 3-D page-flipping mechanism (somewhat similar to the one used by FlipBook). Unlike some similar projects I’ve found, AFKPageFlipper supports the inclusion of “live” UIView subclasses, and not just of static images.

There are a couple more libraries I intend to open-source—I haven’t quite had a chance to rip them out of the projects they currently reside in and make them look pretty.