Solipsism Gradient

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… 🙂

Looking back over my WWDC predictions here, I was struck by how boring they were. The same sort of expectations every year, only everything was twice as fast, or large, or whatnot, than the year before. And this year, coming into a conference which is almost completely not about my main platform – the Mac – I noticed I didn’t even have enough information or interest to do the obligatory prediction post.

I was told that over 60% of the developers this year were newbies both to WWDC and to developing for Apple. This seemed, even, a low estimate; I did meet friends from years past, some of them real old-timers, but there weren’t as many as I’d expected – and almost none of the people I didn’t know, that I talked with, were doing anything on the Mac, although some said they’d try to do so sometime in the future.

Indeed, the Mac OS was conspicuous by its almost total absence in the session list, and it was mentioned only offhandedly by Steve Jobs during the keynote – only once, I think. Another, more unexpected, absence from the keynote was the iPad: this, too, was mentioned mainly regarding sales figures, and the rest of the keynote was all about the iPhone 4 and the newly christened iOS 4.

On consideration, however, it makes sense not to talk about the iPad in the keynote: Jobs is notorious for presenting exactly what he wants the press to publish, and distracting them with too many topics is counterproductive. The iPad has had its presentation a few months ago and is selling so well that they’re probably scared that more people will want one; the factories are at max, and cases and other accessories are back-ordered for days or weeks.

Also, an upgrade for the iPad might be a little premature at this point. Any new version would raise protests from those zillions of people that just bought one; the Flash RAM industry is barely keeping up; a faster CPU would need to be dual-core. Regarding the new fancy Retina screen technology, an iPad screen at about 300 dpi would be 2400 by 1800 pixels! I don’t think any mobile video chip can handle that today. iOS 4 is about the only upgrade that’s reasonable to expect to come out quickly.

The iPhone 4 looks good indeed. I don’t need a cellphone myself but the dual cameras and other goodies are tempting; I find myself wishing that Apple would go into digital cameras again. Still, to me, the real star of this WWDC is Xcode 4, the existence of which was also released to the public today; it’s a major step forward, and – as I said several times in the past – many of its features seem to have been enabled by LLVM and its various side projects. One of them, the lldb debugger, is the one I’m particularly interested in; I never liked gdb much.

Many people asked me if I, too, am afraid that Apple will drop the Mac and Mac OS X entirely in the future. Well, I certainly am not! After all, what else would you use to develop for iOS? Xcode 4, for one, seems positively need a 27″ screen for best use – I’m glad I bought a 27″ iMac not too long ago. While the iOS devices might eventually be the tool of choice for consumers to do most of what they on laptops today, laptops will still be useful, and powerful desktops will always be necessary for anything that needs more CPU or graphics power. That said, I can see the laptop line compressing to, say, two models next year, and the Mac Pro going away entirely, or at least replaced by a model seriously more powerful than the high-end iMac.

To close for today, it is safe to say that – without violating any NDA in the process – is that, at least during the next 4 days, whenever any demo hits a glitch, the presenter will ask the audience to turn off its WiFi devices. I saw it happen already, in fact. 🙂

While reading the links pertaining to the previous post about a “back” button for the iPad – and, incidentally, for the Mac – it occurred to me that such a capability might be built into a future version of my Klicko utility. Which is Mac-only, of course. For now, Apple doesn’t allow any sort of utilities for the iPhone/iPad, more’s the pity.

I’m rather overloaded at the moment, moving out of my apartment only a few days before going off to WWDC, and I’ve got an iPad app prototype to work on, too; but I’ll definitely look into this as soon as possible. I think that most of the infrastructure, in fact, is already in place inside Klicko.

I did download the Universal Back Button App, but didn’t have time to check out how it works; at any rate, it seems to be quite different in implementation.

Brent Simmons, author of NetNewsWire, writes:

On Macs we have a long-standing culture of apps working together.

…

On the iPad (and iPhone) we can sort-of do the same thing. We don’t have AppleScript or Apple events, but we do have the URL scheme thing for inter-application communication. It’s technically possible to do some of these same things.

But we don’t have an easy way to get back to the calling app.

…

What if the calling app added, as a parameter to the URL, a URL to call when the task is completed?

This way the helper app (NetNewsWire in this case) would know, once the task is complete, how to get the user back to their place in the calling app (Twitterrific in this case).

I was thinking about the same issue, coincidentally, and one idea which occurred to me is to use the equivalent of the http referrer URL (often misspelled as “referer” for historical reasons).

For  a standard http request the referrer is the URL of the document containing the clicked link, so you can get back to that document by clicking on your browser’s “back” button. Now, this isn’t really contained in the URL itself – rather, the browser appends this as one of the fields in the http request headers – but the analogy is interesting.

For this to work locally between applications, the referrer URL would need to be set into the URL targeted at the called application. And indeed, there is a -[NSURL setResourceValue:forKey:error:] method that, in theory could add any key/value pair to the URL. (Currently only the “scheme” property seems to be available, though.)

Update: Mike Abdullah points out in the comments that, in practice, this method applies properties to the file a file URL points at, not to the URL itself. Drat.

On the receiving side, the “referrer” value would have to be pulled out from the NSAppleEventDescriptor that the application gets with the ‘GURL’ event.

All this needs filing enhancement requests and Apple would have to do the required twiddling inside their code base – or rather, bases, as this would be useful to have both on the iPhone/iPad and the Mac side. It would take a long time, if it’s done at all.

The alternative would be to developers to, informally, establish a convention for incorporating this into the URL itself. So we’d have something like:
calledscheme:///the/url/parameters&?REF=callingscheme://some/url/to/return

Probably the second part would have to be suitable encoded/escaped, too. Maybe this would be a good topic for discussion at WWDC?

richardl wrote:

Rainer, it is interesting to note that Adobe built their ActionScript/Flash compiler for iPhone on top of LLVM.

http://cs.illinois.edu/news/2009/Oct8-2

http://www.adobe.com/devnet/logged_in/abansod_iphone.html

Thanks, I wasn’t aware of that. However, I don’t think that this invalidates my original argument, which is more based on Clang than on LLVM. Christopher Lloyd also remarked on this:

…Yet Adobe uses llvm for the compiled Flash, so they don’t like Adobe’s parser? silly. http://bit.ly/MQtRZ

Also thanks to Daveed Vandevoorde, who remarked that the LLVM bytecode isn’t as platform-independent as I thought – things like sizes of variables and ABIs (Application Binary Interfaces) stand in the way. Still, it’s not impossible to see Apple defining a generic target platform, in terms of sizes of pointers, integers and so forth, and a specific endianness and runtime ABI, and then staying within the bytecode for that.

Via John Gruber, I just saw an interesting post by Steve Cheney:

It?s pretty evident that Apple isn?t wed to individual suppliers. Not only are they back to creating their own chips, but they are also one of the only ‘compute’ companies to have used each of the top 3 processor architectures over time – ARM, x86, and Power PC.

…This week Apple confined developers to a specific set of tools (XCode [sic]).

…By telling developers to move to XCode tools, Apple is setting the stage to potentially switch architectures.

…In 2003, Apple advised developers to switch to XCode tools. …2 years later Apple moved to Intel across its entire Mac line.

…perhaps the A4 is NOT an ARM architecture. In fact, it?s highly possible that the A4 is a dual core Power Architecture…

The last sentence is of course false, as Gruber says; the A4 does run ARM code.

While I don’t think that forcing developers to switch to Xcode (which is the correct spelling) means that Apple will soon be switching architectures on their iPad/iPhone line, or on their desktop/laptop line for that matter, Xcode does offer developers a future-proof environment that hasn’t been commented on by other observers: the Clang/LLVM project. Briefly, Clang is a compiler frontend for C-based languages, backed by LLVM – which stands for “Low Level Virtual Machine”. Both projects are heavily backed and staffed by Apple.

Clang has been increasingly supported by Xcode as a substitute for the gcc compiler toolchain. The details are quite esoteric, but one interesting capability is that C-based languages – C, Objective-C and C++ – are compiled to the LLVM bytecode, which is then translated into native machine language by a back-end. The last phase could even happen in a just-in-time fashion, allowing apps to be distributed in LLVM code (therefore running on all current and future Apple machines). Some groups are even working on chips that execute LLVM bytecode directly.

In other words, it’s no coincidence that Apple is now instructing developers to switch to Clang-supported languages and their Clang-wrapping IDE (Xcode). There may not be an architecture switch coming soon, but Apple will have much more freedom in doing their own CPUs for iPad/iPhone, and more ammunition in negotations with Intel and other top-end chip companies.

Just a thought to complement my previous post on the subject. A few days ago, Apple announced iPhone OS 4.0 with “over 1500 new APIs” (not a permanent link, sorry).

It’s a safe bet that most of these APIs have been there in the previous iPhone OS release(s), but in their private form. Some of them were simply published – that is, included in the public headers. Beyond that, some had bugs fixed, or their functionality changed, or even their names and parameters changed; and, no doubt, many other APIs stayed private or were, even, dropped. And the common developer can never be sure which is which.

Only Apple’s in-house developers have all this information and for them it’s a mad scramble to update apps with every OS release. This is also why it’s, generally speaking, not advisable to use any apps that come with Mac OS (Preview, Mail, Address Book and so forth) with any previous or subsequent releases; they’ll crash in interesting ways. And this is why Apple lists new features and bug fixes inside those apps when a new Mac OS release comes out.

(This was a good question asked of me at formspring.)

So far, I haven’t done anything for the iPhone, for three reasons.

First, I don’t own a cellphone, and I find it quite difficult to write an app that I won’t use myself. I do have an iPod Touch, and I carry it with me on trips, but it seems I use it strictly as an alarm clock and as a normal iPod – the only apps I have installed are PCalc Lite and the Flycast internet radio. I look at other apps now and then, without finding any that give me that “wow I need that” thrill. (For the record, I’ve also owned the first Newton, the first Palm Pilot, and the Sony Magic Cap – all with their development SDKs – and I couldn’t think of a single useful app for them either; I suppose it’s a mental deficiency.) Also, recall that where I live there’s very little public WiFi, and 3G charges are ruinous… any app I’d use would need to work offline 99% of the time, which narrows things down considerably.

Second, the current AppStore model is extremely different from what I’m comfortable with – ideally, I want to distribute and support it myself, and be able to post updates immediately, without waiting for approval from anybody else.

Third, my main interest is in writing utilities – applications that extend or change the way “the system” or other applications do things. There’s no space whatsoever for that on the iPhone, and it doesn’t look like there’ll be space for it on the iPad for now.

That said, I do plan to attend WWDC 2010 and it’s possible that until June I think of some mainstream application that I’d like use myself. The larger screen could make all the difference. Send in suggestions!