Solipsism Gradient

This is a follow-up to my post about Apple’s new Lightning mobile connector. Thanks to all who linked or commented.

Apple has since published mechanical drawings of the iPhone 5, iPod nano 7th gen, and iPod touch 5th gen. The nano’s drawing has the best illustration of the connector side:

Applying the known width of 10.02mm to the connector photos, it would seem that the projecting part of the plug is about 1.6mm thick and 6.9mm wide. It so happens that this matches closely the standard printed circuit board thickness of 63 mils (1.57mm). The conclusion is clear: the plug consists of a PCB with 8 contacts on each side in a protective metal cladding. The PCB inside the plug’s body will have components on each side; remember the Thunderbolt cable teardown?

The actual interface specifications are still not available to the public – in fact, I think the old 30-pin connector specs never were officially available. What information we have is reverse-engineered or leaked from companies that are in Apple’s MFi program. But connector trends are clear. Some of you may remember the old SCSI 50-pin and Centronics 36-pin connectors; both interface were comparatively low-speed parallel and were substituted by higher-speed USB and FireWire serial interfaces. Thunderbolt, for instance, despite its relatively numerous 20 pins, is a serial interface. It has two full-duplex, differential, 10Gbps data paths (meaning 2 pin for each of 4 transmit/receive pair) as well as two low-speed transmit/receive pins, a connector sensing pin, a power pin, and several ground/shield pins. This is still overkill for the new generation of mobile devices, hence Lightning, which has only 8 pins (plus the outer ground/shield) and, no doubt, lower speeds.

So what are the technical reasons to go with Yet Another Proprietary Connector? Apple has, of course, gone down that road so often that their engineers are well-aware of the tradeoffs involved. We’ve seen the same happen a year or two ago: instead of going to USB3 or eSATA for external devices, they developed Thunderbolt (together with Intel), which is both faster and much more flexible.

Many people complain that Apple should have chosen micro-USB instead of a proprietary connector. The micro-B connector is almost exactly the same size as the Lightning, though it has only 5 pins and is not reversible. The USB3 version of micro-B has 5 extra pins in a separate section and twice the width of the USB2 version. USB3 has actually two different pin groups: one implements the USB2 standard while 2 extra signal pairs handle the new specification. As I mentioned before, usually the USB2 version has limited current carrying capability which would make it unsuitable for the upcoming Lightning iPad; the USB3 version has enough capability but is larger. Non-standard variations are already on the market, and yes, some connector manufacturers are now specifying higher current capacity on the two power pins. True, there are standards being implemented that expand these limits even more, but they’re not quite on the market yet.

Designing an interface means balancing many technical and design trade-offs, especially for a mobile device where device volume, battery capacity, thermal limitations, available PCB area, charging parameters and statistics of intended use all impose serious constraints. Let’s for the moment posit Apple had gone the micro-USB3 route. This would mean a dedicated USB3 host controller/transceiver chip like the TI TUSB1310A as well as several added passive components. This representative chip actually contains a secondary USB2 controller/transceiver for compatibility, has a peak power comsumption of nearly 0.5W while operational and requires 3 different power supplies. The chip alone is over 12x12mm square. More important, Apple’s SoC (system-on-a-chip) design means that their main chip has to implement the transceivers’ dual data interface and various control signals; several dozen of the chip’s 175 pins would connect to the SoC, needing additional PCB space.

In contrast, support for Lightning will probably need no extra chips and less than a dozen extra pins on the SoC; 8 of these will go straight to the connector. One or two of the pins will probably sense which kind of adapter or charger/cable is connected and the others will go, in parallel, to the power controller – switching them will allow enough current for charging without overloading any particular pin. Any current-hungry drivers, signal converters and so forth wouldn’t on the motherboard at all but inside the plug itself, further reducing cost and power consumption for the bare device. The interface may even be self-clocking, with a clock signal routed to the connector whenever necessary, so future system could implement higher speeds.

All this flexibility means that, probably, the Lightning-to-USB2 cable included with the current devices has a driver/signal conditioner chip embedded inside the plug. Any standard charger may be used but Apple’s charger already has a way of signaling its capabilities to the device. The Lightning-to-30pin adapters have, in addition, at least a stereo D/A converter for line audio out and. Upcoming HDMI and VGA adapters will receive audio/video signals in serial form and convert them to the appropriate formats. Third parties can, should Apple’s software allow it, build audio inputs, digital samplers, video-in or medical instrumentation adapters. All this without impacting users who need none of these adapters, but just want to charge their device.

Could all this also be done with USB2 or 3? Well, in principle, yes, but at a cost. Other manufacturers are using, for instance, MHL, which passes audio/video over the USB connector. However, this simply repurposes the connector itself – you need a separate controller chip to generate the MHL signals while the USB controller is turned off, unless you make yet another non-standard plug. (Note that MHL adapters are in the same price range as Apple’s adapter, so nothing gained there either.)

Update: forgot to mention that, with the assumptions above, nothing but SoC speed restrictions preclude Apple from releasing a Lightning-to-USB3 cable in the future.

Update#2: my comments on the physical details of the connector.

Update#3: my final summary. Please comment there, comments here are now closed.

In keeping with recent meteorological themes – iCloud, Thunderbolt – yesterday Apple introduced the new “Lightning” connector for its mobile hardware. This will be the replacement for the venerable 30-pin dock connector introduced 9 years ago. I haven’t seen it in person yet, but here’s some speculation on how it may work.

First, here’s a composite image of the plug and of the new connector (which is, apparently, codenamed “hero”):

You can see that there are 8 pins and that the plug has a metallic tip which, from all accounts, serves as the neutral/return/ground. Since the plug is described as “reversible”, the same 8 pins are present on the other side and, internally to the shell, connected to the same wires. However inside the connector you can clearly see that the mating pins exists on one side only – presumably to reduce the internal height of the connector by a millimeter or two, at the expense of slightly better reliability and a doubled current capacity.

There are locking springs on the side of the connector that mate with the cavities on the plug, hold it in place, and serve as the ground terminal. The ground is connected before the signal pins to protect against static and the rounded metal at the tip (from the photos it seems to be slightly roughened) wipes against the mating pins to remove any dirt or oxide buildup. At the same, the pins on the connector (not on the plug!) are briefly shorted to ground when the plug is inserted or removed, alerting the sensing circuitry to that.

People keep asking why Apple didn’t opt for the micro-USB connector. The answer is simple: that connector isn’t smart enough. It has only 5 pins: +5V, Ground, 2 digital data pins, and a sense pin, so most of the dock connector functions wouldn’t work – only charging and syncing would. Also, the pins are so small that no current plug/connector manufacturer allows the 2A needed for iPad charging. Note that this refers to individual pins; I’ve been told that several devices manage to get around this by some trick or other, but I couldn’t find any standard for doing so.

This takes us back to the sensing circuitry referred to. If one of the pins is reserved for sensing – even if it is the “dumb” sensing type that Apple has used in the previous generation, using resistors to ground – and two pins are mapped directly to the 2 USB data pins [update: I now think such direct support is unlikely] whether the USB side is plugged to a charger or to a computer’s USB port, and the other 5 pins can be used for charging current without overloading any single pin.

This also explains the size (and price) of the Lightning-to-30 pin adapter. It has to demultiplex the new digital signals and generate most of the old 30-pin signals, including audio and serial transmit and receive. The adapter does say “video and iPod Out not supported”; I’m not sure if the latter refers to audio out, though I’m now informed that the latter exports the iPod interface to certain car dashboards.

It’s as yet unknown whether Lightning will, in the future, support the new USB 3.0 spec – the current Lightning to USB cable supports only USB 2.0. This would require 6 (instead of 2) data pins, which is well within the connector’s capabilities. But would the mobile device’s memory, CPU and system bus support the high transfer rate? My guess is, not currently. Time will tell.

Update: deleted the reference to “hero” (I didn’t know it’s designer’s jargon). Also, for completion, I just saw there’s a Lightning to micro-USB adapter for European users, where micro-USB is the standard.

Update#2: good article at Macworld about Lightning. Also, Dan Frakes confirms that Apple says audio input is not included in the 30-pin adapter.

Update#3: found out what “iPod out” means, and fixed the reference.

Update#4: I added to the micro-USB paragraph, above. Thanks to several high-profile references (The Loop, Business Insider, Ars Technica – who also credited my composite picture – and dozens of others), I saw a neat traffic spike here. WP Super Cache held up well. The comments on all those sites are – interesting. 🙂 Of course whoever is convinced that everything is a sinister conspiracy by Apple won’t convinced by any technical argument, and I want to restrict myself to the engineering aspects.

Update#5: more thoughts (and some corrections) in the follow-up post. Please read that first and then comment over there.

…while Apple catches up with sent-in FAXes. Yes, you read that right.

In the meantime, RB App Checker Lite is momentarily off the Mac App Store. (It’s still normally available from the product page, of course.)

With very few interruptions, I’ve been a registered Apple Developer since mid-1984, when I bought the original loose-leaf edition of “Inside Macintosh”. From a reasonably early date onwards, I always paid by credit card. At some point – I think it was the late 1990’s – most developers were switched to paying over the iTunes store – quite practical in the US and Europe, since that was already tied to the Apple ID.

However, Brazil was very late in getting the iTunes store and from then on developers here had to send in an annual FAX stating their identification, credit card number, and so forth. A few years ago, the the iOS app store, the iTunes store, and the Mac app store (in that order, I think) became available and every time we heaved a collective sigh of relief, thinking that easy payment would be again possible.

Unfortunately, it’s now late 2012. All the stores are available but we still have to send in a FAX to Cupertino to renew our developer programs! No shipping Mac even has a built-in FAX-Modem anymore, which was what I used in the early years. Twice, I’ve asked developer relations at WWDC to send in the FAX for me – which they did, to their credit; and for the last few years I’ve asked their counterparts at Apple Brazil to do so, as they’re the only place I know of which still has a FAX machine stashed away somewhere. Still, the renewal was effected in a few days.

When I renewed my iOS membership a few months ago it took an unprecedented 7 days to be effected after sending the FAX, so when my Mac membership renewal came up, I thought it prudent to send in the FAX 20 days (!) before to ensure a timely response.

Unfortunately, the 20 days have come and gone, my renewal application still hasn’t been processed, and I’ve been cut off from the developer sites. Moreover, my app is no longer visible in the Mac App Store. I’ve already complained twice to Developer Relations and re-sent the FAX (both by machine and by email) 3 times; at first they admitted that it should have taken at least two weeks (!) to process, but haven’t replied since.

In the meantime, the new version of RB App Checker Lite had been in the review queue for 15 days and was finally rejected this week; first because of the pending renewal, second because of a temporary entitlement that had been accepted in the first version. I’m working on that. More soon (hopefully).

Update: just got email from Apple, stating that they put in a temporary extension while my renewal is being processed. The app isn’t back on the store yet, but at least it gives me breathing time to submit a new version; perhaps as soon as tomorrow.

Update #2: the app is back on the store. Stay tuned…

Update #3: my renewal has been processed, and we’re back to normal. Now working on the app again.

I had just published my previous post about Mountain Lion and Gatekeeper when Apple announced the third postponement of the sandboxing deadline for the Mac App Store, this time until June.

This was expected; given the announcements and the changes in the sandbox details (including some unannounced ones which I can’t comment on), a postponement was inevitable. In fact, my hunch is that at WWDC 2012 a final postponement will be announced, to coincide with the golden master of 10.8; or, at the very least, 10.7.4 will be back-fitted with the same Gatekeeper and sandboxing capabilities. This latter option has a potential pitfall; Xcode doesn’t like applications setting their minimum system version to a point release.

A brief recap of the sandbox is in order. If the developer turns on sandboxing, the application will run inside a protected environment. The user’s home folder is substituted by a per-application container where parts of the original home are reflected by symbolic links. Certain folders, such as ~/Library and ~/Documents, are not reflected. A sandboxed application’s system calls are closely monitored and restricted. The intention is that the application cannot interact with other applications, or with other app’s documents – not even with their preferences. However, some parts of the file system can always be read, basically to allow the application to use system resources.

These restrictions can be selectively eased either by a signaled user intention or by a list of so-called “entitlements” set into the application signature. Entitlements can allow access to iCloud, to selected hardware such as networks, cameras or printers, to user databases such as calendar or address book, or to parts of the file system outside of the application container such as music, picture or movie folders. Access to files can be granted as read-only or read-write.

User intentions can be signaled by actions such as dragging & dropping icons from the Finder onto the application’s icon or windows, or by selecting files/folders from the standard open or save panels (and there are entitlements for that option). This opens a temporary breach in the sandbox for that run; starting with 10.7.3, this access permission can be stored into a bookmark file for later use by the application.

Temporary exemptions can be granted to allow the application permanent access to any part of the file system, however Apple advises that such exemptions may not be allowed for apps in the Mac App Store.

Many other actions are restricted by design, and there are no entitlements to allow sandboxed apps to send AppleEvents to other apps, to use the Accessibility APIs for controlling other applications, and so forth. Add that to other restrictions already in place for the Mac App Store – such as not allowing privilege escalation by asking for an administrator password, system preference panels, etc. – and it’s understandable that developers are viewing the forthcoming sandbox requirement with trepidation and even anger.

On the other hand, for the user, sandboxing has its advantages. Losing data by program bugs or malicious code is restricted to the few places where read-write access is granted. Applications that “phone home” won’t be able to do so unless network access is allowed by an entitlement. If the entitlements are carefully chosen and restricted to the exact functionality of the app, everything should be well.

Unfortunately, the current entitlements are relatively few and more related to Apple’s initial ideas about what type of app should be on the Mac App Store – a game or relatively simple document-based application, perhaps. Now that Gatekeeper will be allowing “identified developers” to sign applications, Apple should also encourage these developers to use the sandbox. Well-known developer Daniel Jalkut says that the sandbox should be expanded:

Apple should embrace the utility of sandboxing by shifting their focus away from sandboxing only Mac App Store titles, to a strategy that would sandbox virtually every Mac app, inside the store or out…

To increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps…

Finally, Apple should take a cue from its own Gatekeeper approach. By incorporating sandbox information about apps into the forthcoming app security preference pane, they will empower users to understand application intentions.

I agree fully with Daniel but would like to expand his proposal even more. We need more fine-grained entitlements that also encompass things that are currently done by older methods. For instance, to interact with other apps over the Accessibility APIs, application’s binaries need to be blessed with the old Unix setgid bit – or the user has to be oriented to allow all and any applications to do this. This would be easily solved by a specific entitlement. No doubt some entitlements might be restricted to administrator-level users. All in all, expanded entitlements will be in the general interest.

All that’s missing is an easy way of communicating to the user what entitlements the sandboxed application has set into its signature. Rather than do this in the security preference pane, I’d like to renew the idea I mentioned in my previous post: an information panel that’s shown on the first run for a signed application (and easily found by the user for re-checking thereafter). Besides showing information about the code signature and the authoring developer, this panel should also show a concise explanation of the entitlements requested by the application; with that information, the user can fully decide whether running that app will be worthwhile. Hm, why does this game want access to my Address Book, to the Internet, and read/write access to my entire hard drive? Looks suspicious…

This would take care of applications signed by identified developers. Unsigned applications that run without a sandbox should rightly be viewed with some suspicion. I don’t see many arguments in favor of anonymously-authored applications, but in any case, with the upcoming model, the user always has the option to make exceptions.

There remains great controversy about what was, until a few days ago, the main use for the sandbox: in Mac App Store applications. There was no incentive for non-MAS apps to be sandboxed, and Apple seemed to be unyielding in expanding the available entitlements – the gist on the developer forums seemed to be “either fit in the sandbox as it is or don’t sell over the MAS”. There are temporary exceptions and some (very few) developers got personal workarounds, but it all feels very constraining. In my opinion, it’s extremely worthwhile for developers to file feature requests for the sandbox outside the MAS. After all, it’s in Apple’s own interest to see wider sandbox adoption, and the hope is that some of those new entitlements will – after some time – flow back to benefit MAS apps.

Who knows, perhaps Apple will, in time, allow identified developers to sell iOS apps outside the App Store? It all depends on how successful that model is on the Mac. After all, confluence should go both ways!

Update: I just found Uli Kusterer‘s article about the sandbox which makes several of the same points, including one I’d forgotten to mention above: entitlements could easily refer to other applications just by mentioning their bundle ID (and perhaps, distinguishing between sending AppleEvents to that app, accessing their preferences or sandboxed files, and so forth).

In a surprise move by Apple, Mountain Lion (aka Mac OS X 10.8) was announced early and in an unorthodox manner.

Their new infrastructure seems to be working well – I downloaded and installed the beta very soon after the announcement. It’s working well (for a beta) in a VMware virtual machine after following this hint.

Let me comment briefly on the “iOSification of OS X” question. Having consistent app names (and, to some extent, user interfaces) between similar applications on both iOS and OS X is a good thing. Greater integration with iCloud was also pending, and here too users need a consistent interface on both platforms. Beyond that, there seems to be little evidence that the operating systems themselves will suffer anything but a benign cross-pollination of features and APIs.

As a developer, I’m more interested in what code signing, the upcoming Gatekeeper and sandboxing requirements for the Mac App Store mean for future applications.

Code signing has been a feature of Mac OS X for some time now. The details are tricky but, in essence, executable code can be signed using an “identity” backed by a “trusted” chain of certificates. Such a certificate is a variation of the ones deployed for “trusted” websites – those whose addresses start with “https:”. Obtaining a so-called “self-signed” certificate and signing an application on OS X is quite easy, and several of my applications have been signed in that manner.

On the downside, anyone can strip such a signature and substitute another one; and checking for that is not easy for the user. Here’s part of my current Klicko product page:

To check that Klicko’s signature is intact, open Terminal, paste in the following command, and press the Return key:

codesign -dvvv -r- /Library/PreferencePanes/Klicko.prefPane

(assuming that you installed Klicko for all users; otherwise, type a tilde (~) before the /Library part.) You should see several result lines in the Terminal.Authority=Rainer Brockerhoff should be present, and identify the author. The last line should end with …root = H”4cbb97c74336f7ee6aa566122a5e7688e1c725dc” and uniquely identify the author’s signature. Now run the following command:

codesign -vv /Library/PreferencePanes/Klicko.prefPane

If the Klicko bundle is intact, this should display valid on disk; otherwise you’ll see code or signature modified. In the latter case, throw it into the Trash.

Not something that a non-techie user would do; and the system doesn’t (yet) complain if you try to run an unsigned application (or one whose signature or executable has been tampered with). Even so, on current systems there are benefits to running signed code: parental controls and keychain access are example cases.

Code signing has been mandatory on iOS from the very beginning – it won’t run applications not signed by a registered developer, backed by Apple’s own trusted certificates. The whole “jailbreaking” paradigm stems from that feature: normally, only apps from Apple’s App Store may run, and Apple can revoke an application’s certificates if the application misbehaves.

Enter Gatekeeper. As far as is known, it has three levels, selectable by the user in System Preferences, allowing the user to run applications that come from:
1) the Mac App Store only (same as on iOS devices);
2) from the Mac App Store and identified developers;
3) from anywhere (same as on current and previous systems).
It’s of course unknown which of those levels will be default when 10.8 goes golden.

Gatekeeper is triggered by the well-known “quarantine” attribute set on applications and disk images downloaded from the Internet. After the usual dialog alerting you to that fact, if you’ve set Gatekeeper to level 1 or 2, the application’s signature is checked; if it’s not backed by the corresponding trusted Apple certificate, a further dialog advises you not to run that application. There’s no override option unless you opened the application from the contextual menu (instead of double-clicking). Also note that this doesn’t happen with applications copied from external drives.

Parts of Gatekeeper are already available on 10.7.3 but must be turned on with a Terminal command. The most restricted level isn’t available, and for an improperly signed app the complaining dialog curtly advises you to “move [the app] to the Trash”; it even offers a button to do so. Although this dialog doesn’t seem to occur on 10.8, some developers are considering it a bad sign of things to come.

But it is the intermediate Gatekeeper setting which is the most important; hopefully it will be the default. So what is meant by “identified developers”? Currently, this is someone who paid the annual $99 fee to be part of Apple’s Mac developer program. As I am in that position, I’ve already requested and downloaded my code signing certificate, and will use it to sign my future applications – those published outside the Mac App Store.

The benefits to myself are obvious. Anybody who downloads my applications through the usual channel – directly from my website – can be assured that it is signed by myself, that it hasn’t been tampered with by a third party, that I’m a registered developer, and that Apple certifies that all this is true. Still, some additional care needs to be taken, both by Apple and by the user. Specifically, when 10.8 comes out it should have an easily accessible information window containing the following information: (sorry, no time to make a graphic mockup)

<Application name and version> is signed by <developer name> developer ID number.
<Link to developer/application site>
<List of certificates and their expiration dates>
Apple disclaimer (for non-Mac App Store applications).

This information should be shown on first run – perhaps on request from the “quarantine” dialog – and from somewhere in the Finder. Note also that Apple can revoke a developer’s certificate; it’s as yet unknown if that will affect already-downloaded applications (as I think it does on iOS) or not.

As I said, the user can take steps to run the application even if Gatekeeper advises against it. Unless this option is removed when 10.8 goes out of beta – and it would make no sense at all for Apple to remove it – it’s a welcome step for serious developers. And it’s a practical intermediate solution for applications or system plug-ins that don’t fit into the Mac App Store’s restrictions; specifically, regarding the impending MAS requirement for turning sandboxing on. More on that in my next post.

[Updated to fix an error regarding Gatekeeper on 10.7.3.]

A couple of friendly publications have asked me to write about the very recent passing of Apple’s former CEO, Steve Jobs. I refused. While some of the stories published in the past 24 hours are moving, interesting, informative and even funny, some are also inappropriate, self-serving, offensive, vapid, or overly sentimental. (And few people agree as to which are which!)

I also have, in the past, refrained from writing about personal stuff here. There are people (both living and deceased) who I admire for certain personal qualities, but it would be unseemly for me to publish a “fanboi” list of these people, much less directly address the departed ones or their families. What I can mention about Steve Jobs is:

• I’ve been a few feet away from him twice at trade shows, but that’s it. No conversations.
• I’ve been an Apple customer, almost exclusively, since 1977, a Mac developer since 1984, and a (very modest!) Apple stockholder since the beginning of the millennium.

As often happens with such public figures, a good part of the public’s perception is shaped through anecdotes and legends which may not closely correspond to what really happened. While I’m as happy to repeat such tidbits in personal conversation as anybody else, there’s only one that I feel completely comfortable to express here: all agree that Steve Jobs really cared about building better things – hardware, software, but mostly better systems.

Which happens to agree with my personal philosophy here – if you’ve looked at my products page, the header says “finely crafted software for the Macintosh”. So, the best way to do something that Steve Jobs would agree with is to go on building better stuff.

I have been remiss in mentioning my current work here, and I decided it’s time to give at least a hint. So, here are the icons for four forthcoming Mac utilities:

The top two should come out first. They’ll all be on the Mac App Store, if all goes well. Details, prices and so forth are still in flux but should be available soon. Some of their functions are intended to replace parts of my defunct XRay application, but Quay will also be updated afterwards to work in concert with the new apps. Current customers of both applications will get free updates within the (unfortunately) narrow conditions imposed by the Mac App Store.

More details will be published as things develop (hehe). Stay tuned. I’m working hard on better stuff.

By the way, the icons are by Sergio Bergocce.

If you missed it, here’s part 1.

Now, as I said, hardware details are becoming interesting only to developers – and even we don’t need to care overly about what CPU we’re developing for, now that we’re used to both 32-bit and 64-bit, big-endian and little-endian machines. (Game developers and players, of course, are a different demographic.)

As Steve Jobs said, it’s all about the software now. Here, too, too much emphasis on feature details can be misleading. I don’t really care whether Apple copied the notification graphic from Android, or whether it was the other way around. What’s important is that user interfaces are evolving by cross-pollination from many sources, and this is particularly interesting regarding iOS and OS X (note that the “Mac” prefix seems to be on its way out).

The two operating systems have always have had the same underpinnings in BSD Unix/Darwin and in several higher layers like Cocoa and many of the various Core managers. In their new versions, APIs from one are appearing in the other, and UI aspects are similarly being interchanged; compare, for instance, the Lion LaunchPad against the iOS SpringBoard (informally known to iOS users as “the app screen”).

Apple is not “converging” OS X and iOS just for convergence’s sake. Although desktops, laptops, tablets, phones and music players are all just “devices” now, the usage and form factor differences must be taken into account. Remember Apple’s 2×2 product matrix some years ago: desktops and laptops, consumer and pro machines? It hasn’t shown up lately, and we really need a new matrix; the new one should probably mobile and fixed, keyboard and touchscreen.

Don’t be misled by appearances! Yes, the LaunchPad looks like SpringBoard, but that doesn’t mean that we’ll have touchscreen desktops soon – rather, both interfaces are, in fact, a consequence of the respective App Store, being an easy way to show downloaded apps to the lay user. Apple is, however, exploring gesture-based interfaces and no doubt we’ll see the current gestures evolving into a universal set employed on all devices, the same way common keyboard shortcuts have becoming engrained. A common thread here is that hardware advances like touchpads, denser and thinner screens, better batteries and faster connections are becoming the main innovation drivers technologies, like processor speed and storage size used to be.

A subtle and very Apple-like aspect of this sort of convergence has become visible when the iPad came out. While some scoffed that the iPad was “just a larger iPod Touch”, in fact the iPod Touch had been, all the time, just a baby, trial-size version of the iPad! The Touch, the iPhone, and even the older iPods were an admirable way of getting the public used to keyboard less interfaces, and the iTunes Store was a similar precursor to the App Store. This means that when the iPad came out there was a legion of users already trained to its concepts and interface; an excellent trick, and one that only Apple could pull off.

Now we see that, in a similar way, the iPad and its smaller siblings are preparing the general public to migrating to larger, more powerful, devices which look comfortingly similar in many ways. Few consumers think of their iPhones or iPods as computers, even though they’re as capable as the supercomputers of 15 or 20 years. Now that desktops and laptops are just devices – and you won’t need a so-called computer anymore to set up your smaller devices – very soon this new class of “devices with keyboards” won’t be thought of as computers either, and the term will be used only for servers and mainframes, as it was in the old days.

I, for one, welcome our new post-PC overlords… 🙂

Whew. It’s over. This year’s WWDC was certainly one of the most intense – and one of the most promising – that I can remember.

It started on a somewhat sad note: Steve Jobs was clearly unwell, moving slowly and his voice was unusually weak. He was onstage for only a few minutes before turning things over to his VPs. Then, towards the end, when he talked about iCloud (which is obviously something he put a lot of energy into) he got better. Still, I have a feeling that this might have been Jobs’ last keynote; he’s clearly not going to be around for many more years. However, the general impression I had was that everybody feels that Apple is now synchronized enough with his mindset to go on indefinitely without him.

This WWDC was clearly about pointing out future directions. And it was all about software. Many commenters are pointing out this or that added feature in (say) Mail, or in the Finder, or in iOS 5. Others are bemoaning the lack of hardware announcements. Of course there have been the usual comments about Apple copying this or that from Windows. Still others are gleefully pointing out how the iPhone 5 (for instance) has been delayed – this when it hasn’t even been announced, but they apparently believe in each other’s rumors!

Let’s put the hardware issue away first. As I’ve been saying for a couple of years now, Apple’s heavy investment into Clang, LLVM and connected technologies like LLDB is now paying off. This trio will very soon be Apple’s main developer tools backend. They’ll be free from overweight, ancient, license-encumbered stuff like gcc and gdb and the results are very encouraging. Without going into details (NDA ahem), suffice it to say that fellow developers have seriously agreed with me that the new tools are better – this or that detail notwithstanding – than anything else on the mobile or desktop market today.

Also Apple is now free to make hardware details irrelevant. When Apple switched to Intel six years ago, I wrote:

Winners:

• Apple, of course. As I commented below, they’re free (or will be, in a year) of the CPU-architecture-as-a-religion meme. They get a literally cool CPU/chipset for their PowerBooks; although I suppose they won’t use that name in the future; how about IBook ? They get dual-core CPUs right now, and a 64-bit version in the future.

And this is still true. At that time, too, some people saw Apple “imitating” the Wintel machines by adopting Intel CPUs as a negative thing (or even as positive, depending on their bias). Now with Clang/LLVM becoming Apple’s mainstream tools, they could switch CPUs anytime without users noticing; the new Intel-based Macs were still normal Macs, and normal users didn’t care which architecture the ran on. And indeed, lately rumors have abounded about ARM-based MacBooks. But, as I wrote at WWDC 2005:

…it’s a new type of freedom. Freedom of architecture. IBM underperformed, they’re out; at least for now. Intel works better now, they’re in; at least for now. Next year, some other chip may be hot, Mac OS X will be on it, and recompiling will be even easier. We’re free!

For the normal user, hardware specs aren’t that important anymore beyond a certain threshold – if they’re sufficient for the job, the details are unimportant. As the old joke goes:

A lady stands in front of an enclosure in the London zoo and gestures towards one of the hippopotami, asking a passing zookeeper:

“Please, can you tell me if that hippopotamus is male or female”?

“I’m sorry to say that this information would be of interest only to another hippopotamus…”

As Jobs said in the keynote, now it’s all about “devices”. Desktops, laptops, iPads, iPhones – all are equal devices in the iCloud. Few people think of their iPad/iPhone as a computer; the innards are of interest only to those of us who have to develop software or hardware to (ahem) “mate” with those devices. Will the next iPhone or laptop use Apple’s A5 chip, or will there be an A6? My mom doesn’t care, and yours shouldn’t – unless she’s a fellow developer. Not even if she’s a stock analyst!

Next: software directions.