Solipsism Gradient

This appeared on xkcd a a few weeks ago: (click to embiggen)

many other developers will sympathize.

So, I’ve been developing a system to pass you, gentle app user, arbitrary applications. Since, as I said before, a group of Mac utilities is in the works – with the first four even having icons and all – of course I thought to “save time in the long run”.

It’s been more than 20 minutes though, for which I apologize. Things have been unusually complex for me this year, not to mention a couple of recent health scares (all solved, I hasten to mention).

Returning to the condiments apps. My intention is, of course, to write an ever-expanding suite of small utilities, though Apple still hasn’t published details on how to pass info from between apps in such a suite if they are on the Mac App Store. (And there’s the upcoming app sandboxing deadline to consider – an added complication.)

Anyway, all apps will work in a similar manner: file(s) are dropped onto the app’s icon, or selected from the standard Open Panel. Then something will be done to those files – information summarized, files counted, permissions checked and optionally changed, whatnot; all expected functions should be reasonably obvious from the UI.

So we have a host of common functions, namely, implementing the App Store receipt checking, sandboxing considerations, receiving dropped and opened files, scanning over them (and perhaps over their contents, if they’re folders), showing the About Box and some help, and doing all that in a consistent manner.

I’m happy to report that everything along those lines is now working perfectly, and with the new workspace facility in Xcode 4, expanding from one to several apps will be a piece of cake. Let’s leave the culinary metaphors aside for the moment and ponder how I’ll can deliver – considering that my record regarding past deadlines has been not so good. (OK, abysmal.)

The answer is obvious: take a cruise. In recent years, everything significant I’ve released had been mostly written and polished on a cruise ship. No distractions, no phones, almost no Internet, no relatives (haha)… and I can impress my fellow passengers by saying “well, I’m making money for the next cruise here on board!”.

So, for over a year we’ve been planning a major cruise – it might be our last long cruise for the foreseeable future, even. And I’m very happy that we leave early tomorrow to return in the last days of January 2012. (Should give us time to prepare for the Mayacalypse, anyway.)

I’ll be posting from underway without saying too much about destinations, to add to the suspense. We should have occasional – though expensive – Internet onship, so email etc. should work. Our next stop should be Santiago del Chile. Stay tuned!

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…

Yesterday, Steve Jobs announced that in a few months, Apple will open an App Store for Mac OS X, following much the same model as the previous – and hugely successful – App Store for iOS.

Two things are immediately obvious: first, the Mac OS X App Store won’t be the only way for users to purchase, download and install applications on their Macs; the previous, time-tested ways will continue to be allowed. Second, the App Store (as the name states), is for applications only – and only for applications of a certain kind.

The long list of prohibitions and cautions exclude, often by definition, system preference panels (like my own Quay), kernel extensions or apps that use them, complex application suites that install background processes, and in fact, anything but a plain old-fashioned self-contained application would be hard-pressed to observe all the guidelines. In fact, as others have observed, most of Apple’s own applications are non-compliant.

The huge difference from the iOS App Store is that developers are perfectly free to write software outside the guidelines, and users are perfectly free to install them. What the new App Store is promising to be is, in effect, a fenced-in garden where a certain type of user can download and install a certain kind of application while getting the warm fuzzy feeling they know from the iOS app store.

In fact, my hunch is that Mac OS 10.7 (Lion) will have an interesting change to the “Accounts” panel in System Preferences. Today, you have four types of user accounts: Administrator, Standard, Managed with Parental Controls, and Sharing Only (aka Guest). I think that all but “Administrator” accounts will allow the user to install applications only via the App Store, and that the Managed and Guest accounts will have an option restricting that user to only run applications from the App Store.

Which may not be such a bad idea after all.

For the developer, it seems that it won’t be allowed to have the same application sold over the App Store and outside it; perhaps not even different versions of the same app. That also makes sense to me. In other respects, the same old arguments apply to both the old and new App Stores: price erosion must be avoided, marketing your app in the long term can’t be left in Apple’s hands, and so forth.

As for myself, I still haven’t had an idea for an iOS app compelling enough that hasn’t been done already, and so far that same argument applies to Mac OS X apps that would fit into the guidelines; my interests lie, still, in doing utilities that enhance the system – not allowed on iOS, still very interesting on Mac OS X.

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?

So, to start things going again… I was looking at my RSS feeds for the first time in almost 5 months, and read Dan Wood of Karelia fame explaining about Converting Rich Text to TEXT/styl resources for an SLA on a Disk Image.

My own workflow for building a release disk image uses a small tool I’ve written for that. You can download it here. Here’s the help text it prints out if you run it without arguments:

   Add one license at a time to a (unflattened) disk image.
   Usage: AddLicense /path/to/TheUnflattened.dmg Language /path/to/TheLicense.rtf
   Languages supported: da nl ko ja fr it fi pt sv en es de nb
   You can also use long equivalents like English, French etc.
   The first language added will be the default language (usually English).

Here's an actual usage example from a build script:

   hdiutil unflatten "$SOURCE_ROOT/My.dmg"
   "$BUILT_PRODUCTS_DIR/AddLicense" "$SOURCE_ROOT/My.dmg" English "$SOURCE_ROOT/EnglishLicense.rtf"
   "$BUILT_PRODUCTS_DIR/AddLicense" "$SOURCE_ROOT/My.dmg" French "$SOURCE_ROOT/FrenchLicense.rtf"
   hdiutil flatten "$SOURCE_ROOT/My.dmg"

and I use the “flatten” and “unflatten” arguments to hdiutil to massage the disk image.

The trick (as Dan points out in his post update) is that you can use ‘RTF ‘ resources instead of TEXT/styl. I received this interesting tidbit through oral tradition; I’m not a 100% certain, but I think it was through some code that Marko Karppinen showed me a few years ago. Pass it on.

If there’s interest, I may clean up and publish the source sometime, though it uses all sort of gronky old APIs (Resource Manager etc.).

Update: the link above now downloads the complete Xcode project. I also included it on my source code page.