Solipsism Gradient

With the new apartment mostly ready (though the external/common areas are still unfinished), a return to blogging and coding may now be possible.

While I’ve pondered about the general direction that I wish to take my software, details are still a little unclear. Yes, the Mac App Store does figure in my plans for updating/replacing XRay, but System Preference panels are not accepted – so Quay and Klicko will continue being distributed over this website.

The developer preview release of Mac OS X 10.7 “Lion” was a surprise to me. My expectation was that it would be released at (or just after) next June’s WWDC, which I hadn’t planned to attend. I’ve just installed the Lion preview and had a fast look; it’s farther along than such previews usually are, and there are sufficient new UI details and API changes that I decided to study those first, before commiting to design details on my own software.

A surprising amount of detail about Lion has already been published, NDAs notwithstanding, with only token sallies from Apple Legal. I’ve been somewhat out of touch with the developer community, so I can only speculate. Reducing the price of developer access to $99 – 20% of what it cost the last time around – may be a factor.

One aspect which will impact me immediately is that PowerPC support over Rosetta will no longer be available. There are some PowerPC apps I still use a lot: among them are Resorcerer, DMG Maker, Plain Clip, my own XRay, and – the one that’s open all the time – Eudora; as well as a bunch of utilities and games that I open very rarely. I suppose I’ll have to relegate them to my old Mac mini Core Solo, which – being a 32-bit machine – will also not be supported by Lion.

The exception is Eudora; I’ve used it since 1.0b5 or thereabouts. I suppose I’ll finally have to try out the Eudora OSE version; some fellow oldsters tell me it’s not too bad. None of the other email clients seem attractive, especially Apple’s Mail, which I actually tried out last year and didn’t like.

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.

I just found out that an errant script is messing up the automatic version checker in Quay and Klicko – a consequence of the server migration which happened several days ago. Please hold on while our trained server gnomes return from their burrows and fix it (it might be one or two more days, I’m really stretched thin here). My apologies.

Update: fixed. Again, sorry about the delay.

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?

Interesting piece by Sean Heber aka BigZaphod.  Remember my post about the significance of Clang/LLVM on the iPad?

I think there’s a chance that Apple is slowly building Objective-C into a managed environment similar to Java/.NET. At some point in the future they could define an Objective-C HD (or whatever ) that no longer maintains total compatibility with C. Since they use LLVM a lot now, they can even use that to analyze your code to make sure that pointer accesses are safe and controlled. Anything that isn’t safely confined to your own app would be an error. Access to the Objective-C runtime functions could possibly even be revoked. After which point, Objective-C HD no longer compiles to machine code but instead to an intermediate representation.

By doing something like this, they can abstract the actual underlying CPU hardware and architecture out of the applications themselves as well as maintain a truly safe sandbox where private and undocumented APIs simply will not be allowed to work. Apps on the App Store would be submitted in this intermediate format which they can translate into the machine code that’s native to whatever CPU happens to be in the device you’re downloading the app for or they could simply put a JIT in iPhoneOS (although there’s no reason to waste the CPU cycles on the device if they can translate them once on the backend – at least for mobile stuff).

Pretty much complementary to my reasoning.