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!

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.

Well, Xcode 4.1 is out of beta. Please note that the “GM” build previously posted on the developer site was NOT the released version, which is now available for free on the Mac App Store. (Open the “Welcome to Xcode” window, it should say “Version 4.1 (4B110)”.)

I’d promised to several people at WWDC to investigate how Xcode 4.1’s lack of support for IB plugins would work out for RBSplitView, and now I can finally post the results here. Unfortunately the news is not good.

Compiling RBSplitView’s “Sample App” target works well under Xcode 4.1 with just a few changes to modernize build settings sand avoid new warnings. The problem comes when trying to open the .nib file. First, the release notes say you should do this in Terminal:

	defaults write com.apple.InterfaceBuilder3 "IBKnownPluginPaths.3.2.7"
		-dict-add "net.brockerhoff.RBSplitView.IBPlugin"
		"/Users/<username>/<path-to-RBSplitView.ibplugin>"

which I did.

Opening the nib file then offers to remove the dependency on the plug-in:

and going ahead lists several warnings and issues.

The way this works is interesting. All RBSplitViews and RBSplitSubviews are converted to NSCustomViews – meaning that they’re stored as plain NSViews in the nib file, -initWithFrame: is called on unarchiving (instead of -initWithCoder:); the view’s class is reset to RBSplitView or RBSplitSubview, as the case may be, and all custom attributes are then set through key-value coding.

I suppose this would work quite well for less complex views, but it didn’t work out of the box for RBSplitView. First of all, this KVC stuff was quite new-fangled when I wrote it, and I didn’t see any need to use it until I had to update the RBSplitView.ibplugin for Xcode 3.1. At the time, I simply wrote some KVC methods for the ibplugin additions, mainly to simplify setting all those attributes from inside Interface Builder… it all worked fine.

Converting the nib file generates a lot of exceptions as the KVC methods just aren’t there in the framework code. I tried a quick fix, copying and pasting them from the plugin code, but that didn’t work out too well: RBSplitView doesn’t like being reincarnated from the nib file piecewise like that, and it seems that the attributes get set too late or in the wrong order.

I suppose some fiddling with the copied methods will fix that, but it’ll be at best a stop-gap measure. The converted nib file no longer adjusts the RBSplitSubviews properly and it’d be too easy to make a big mess of it, should you try to change anything in there. Even so, I’ll try to make some time available to get this working.

Apple says Xcode 3.2.6 is “unsupported” under Lion. If you already have it installed in a separate folder when you upgrade it will mostly continue to work, but I found that running Interface Builder 3 crashes when you have the RBSplitView plugin open. Probably the best bet, for now, is running Snow Leopard Server in a virtual machine and installing Xcode 3.2.6 in there.

…at the usual download page. Please post support questions and bug reports on the support page, not here.

It’s essential to update to this version before upgrading your system to Mac OS X 10.7 (Lion).

A couple of users have been reporting that they get a message when clicking on a Dock folder, saying “QuayMenu cannot open files in the QuayMenu Document format”. If this is your case, please go to the folder /Library/Logs/DiagnosticReports; inside that there should be a crash report with a name like “QuayMenu_2011-07-18-220419_localhost.crash”. Please email it to me (rainer AT brockerhoff DOT net) as an attachment. (If there are several, send them all!)

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

My flight to San Francisco and WWDC 2011 leaves tomorrow night and I should arrive early in the afternoon on June 2nd.

Friday and Saturday are mostly reserved for taking care of some private business, but if anybody wishes to meet with me before WWDC, please drop me an email (rainerbrockerhoff.net), Twitter direct message (I’m @rbrockerhoff) or AIM:rainerbrockerhoffmac.com.

Early Sunday I’ll switch hotels and soon after lunch I’ll be at Moscone to get my badge. There was supposed to be a meet-up of Brazilian developers in the early afternoon, but apparently not everybody will be able to show up; at any rate, I’ll hang out at registration for a couple of hours. Later on, and all week, things will be quite hectic and I’ve no idea yet which parties I’ll be able to attend.

After the conference I’ll have a couple of days for resting and reading, and I should be back home on June 15th.

Things are looking up development-wise. I’m well along implementing my ideas of transitioning most of my products to the Mac Apple Store. While this means that all the new stuff will only run on Mac OS X 10.6.6 and up, the old versions will continue to be available, though mostly unsupported. No time to post details yet, and some of those are bound to change depending on information gathered at WWDC – but I’m optimistic that everything will work out.

More as it happens!

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.