Paul Kafasis from Rogue Amoeba made some interesting observations about the possible impact virtualization could have on Mac developers.

Virtualization is technology, rumored to be present in the forthcoming 10.5 release of Mac OS X, that would allow Windows applications to run natively and transparently in the Mac environment. Paul’s thoughtful analysis reveals that Mac users will benefit because of the increased flexibility, and Windows developers will benefit because of the new potential market. Where does that leave Mac developers? I definitely think Apple should spend at least a few hundred thousand dollars researching this on our behalf. Protect us, Apple! Still, the threat of Windows developers suddenly having access to our customers doesn’t scare me too much.

Such an outcome wouldn’t increase the competition so much as the noise. Look at the situation today on the Mac. It’s relatively easy (in my not-so-humble, unproven opinion) to identify products on the market that can be vastly improved upon, put in the hours to build a better solution, and market it directly to the customers. The problem even today is not “being better than the competition,” but reaching the customers who give a damn about your being better. This basic rule won’t change with an influx of new developers.

Take some popular class of application as an example: the 2D vector art editor application. There are at least 10, probably 100 of these apps available on the Mac, and they range in quality from developer examples like Sketch to expensive commercial apps like Illustrator.

Of these 10 or 100 existing apps on the Mac today, I’m guessing from my experiments that only about 2 or 3 are actually really useful. Therefore the competition pool is only 2 or 3 products, regardless of how much noise there is.

Now with virtualization we’d probably get 1 or 2 additional “really useful” apps, although their usefulness would probably be diminished by their Windows-esque UI. Anyway we’d also get probably 10-times as many “non-competitors.” More noise. These products attract users’ attentions but don’t ultimately satisfiy them. So they make it harder for the user to identify your working product.

On a side-note, one could consider the opening up of Mac OS X to linux/unix as a test-run of such a strategy. Essentially for the past 5 years, Linux developers have had open access to the vast installed base of Mac users, but they haven’t made much headway in driving Mac developers out of business. I think it’s reasonable to assume that if Mac users are not interested in free alternatives that don’t cut muster, then they will be even harder to woo with paid ones.

Bottom line? Optimistically I think that better products will win. The problem is cutting through the noise, and technology seems to be on our side. The growing popularity of blogs and “peer editorializing” seems like a natural match for promoting quality products and thereby elevating them from among the noisy ineffective ones. To the Mac developer’s advantage, there are already complex systems in place for distributing Mac propaganda. The online news sites and download trackers that many Mac users frequent are going to be hesitant to embrace and recommend lackluster Windows software – because they themselves are Mac users who know the benefits of native software.

Even if we assumed that the best Windows developers could acquire Mac style, and truly understood what Mac users want, their Windows apps will always be at a disadvantage on the Mac platform. The trend from Apple is increasingly to differentiate Mac OS X by adding technologies with a system-wide impact. Spotlight integration, for instance, will likely not come for free with a “virtualized” Windows app. Furthermore, the development tools and APIs from Apple are getting more and more powerful all the time, in ways that are precisely tuned to work well with differentiating features of Mac OS X. It wouldn’t just be difficult for Windows developers to try to compete with this, it would be a colossal waste of their time!

It’s easy for me to be cavalier about this because I don’t yet make my living from direct software sales, but I’m inclined to think that Windows developers, with their platform-inappropriate styles and habits, will have a hard time competing against Mac developers – even the worst of us.

Bring on the crappy software! It can only make ours shine brighter.

John Siracusa recently wrote about Apple’s almost universally condemned strategy of distributing recorded conference materials after the show is over. He asks “Why does Apple jealously guard the content presented at WWDC?”

It’s a good question, and it probably has to do with compelling future attendance at conferences. After all, Apple is probably thinking, if you can get the milk for free, why … uhm, go to the cow? By “jealously guarding” the content that makes up the “intellectual reward” for conference attendees, they’re making it clear that the best way to stay on top of Mac OS X technical issues is by attending the conference.

This rationale makes sense on paper, but there are major problems with it.

Being In The Room

The first mistake is in assuming that reproduced content will approximate the value of “being in the room.” I’ve watched a fair number of the WWDC 2005 videos through the (painful) streaming ADC Select interface. Aside from the benefits of being able to pause, rewind, and skip the boring parts, let me tell you, it’s no conference. I am roughly able to absorb all the data that my peers who attended did, but they benefitted from a much richer experience.

Watching the WWDC sessions from home is like watching the New York New Years Eve party on television. You are a passive recipient of the information, but you don’t get to participate. You know when the new year arrives at very close to the same moment as all the thousands of people in the crowd, but you don’t get the satisfaction of washing the champagne stains out the next morning.

Even though the information (the passing of the year) from this great event is free and widely spread, the event is hugely successful. Why do those thousands of people travel to downtown NYC to participate in an event they could watch at home? It’s about being in the room.

The value of being in the room at WWDC is about 10 bajillion times greater than being in the room at new years. At WWDC, you can ask questions. If the line was too long and you missed your chance, you can recognize the speaker in the halls and track her down for clarification. At WWDC, you can participate in hands-on sessions, working through the new technology as you learn about it. At WWDC you can visit the labs and work in an environment where smart people are hovering about, waiting to answer your questions. Unless you’ve found a particularly well-stocked IRC room, these benefits are not available to you at home.

Being Outside The Room

The other major motivation for attending WWDC has nothing to do with the conference itself, but with the milieu surrounding it. There is quite simply no other time of year that such a concentration of like-minded Mac software developers exists in any one point on the globe. The closest thing you’ll find to this amazing congregation of Mac nerds, is the sizable number of them that reside permanently during working hours in Cupertino, California. The rest of us are lucky if we’ve found a half-dozen similarly inspired people within a 50 mile radius of where we live or work.

Apple takes this benefit to the ultimate level by opening its own doors for one evening during the conference, inviting attendees to relax, have a beer, and mingle with conference attendees and Apple employees on the Apple campus. This degree of access is totally incomparable to anything a developer can hope for via the web, email lists, chat rooms, or forums. The Apple campus on one summer Thursday becomes an absolutely sizzling hotbed of Mac nerdiness for 3 hours every year.

And Apple’s party is only the tip of the iceberg. Events like the Buzz Andersen’s annual party are gaining momentum with each passing year. The number of extra-cirricular activities is so great that groups of developers with niche interests find it difficult to find a spare lunch or evening in which to meet. In summary? WWDC produces a week of nearly non-stop hot developer-on-developer action. You can’t buy that at home (ahem – nor, with that particularly risque choice of words, would you want to!).

To top it all off, WWDC has for the past several years been held in San Francisco, one of the most attractive tourist destinations in the world. The conference is epic, the scenery is epic, the attendees are epic. Attendance is an almost irresistible proposition for companies and developers alike. Apple has nothing to fear from making the information free.

Ask For What You Want

The value of WWDC is about 5% information and 95% being in the room and being with your peers. If New Years were celebrated like WWDC, only a few thousand people would be running around on January 1 knowing whether it had truly come to pass. I agree with John Siracusa – it’s time to free the WWDC content. We want high quality, downloadable archive versions of all WWDC sessions. These should be available to any ADC member at any level of membership under the terms of their NDA.

If you also agree, let’s stop talking about it and start telling about it. Telling Apple, that is. Use the ADC contact form to let Apple know how you feel. You want this information freed! This is not just for whiny non-attendees, either. Those of you who attend every year have also bemoaned the loss of DVD archives of the sessions, for instance. Take this opportunity to make yourself heard. We’re all in this together!

I encourage you to write whatever you feel in your feedback to Apple, but this is what I am writing and it might spark some motivation in you to “make the call”:

Cocoa contains an awesome but sort of half-baked infrastructure for “autosaving” UI configurations for the user. Many of the common UI elements, such as windows, table views, and toolbars possess the ability to write out their configuration to the app’s preferences so they can be automatically restored the next time the app is launched.

When this works, it works. And it is, as I said, awesome. But for such a cool idea there is a great lack of consistency in its implementation. NSWindow lets you autosave the frame by setting a unique name under which it will be saved. The API is rather extensive:

+ removeFrameUsingName:  
– saveFrameUsingName:  
– setFrameUsingName:  
– setFrameUsingName:force:  
– setFrameAutosaveName:  
– frameAutosaveName  
– setFrameFromString:  
– stringWithSavedFrame 

Notice that there is no BOOL “autosavesFrame” method – it just figures if you set a name, you want it to be saved. This name can even be set from Interface Builder. The number of methods is a bit large for what seems like a simple operation, but what’s really nice is it exposes the “magic format” to developers so we can override the default behavior or make different use of the autosave information.

For example, let’s say you wanted to implement a funky little “Exposé” feature for just your application, something that tiles all the windows so that they fit neatly into the available screen real estate. That’s fine, but you should be prepared to put all the windows back the way the user had them before. Using “stringWithSavedFrame,” this is trivial. Just iterate over your open windows and collect the screen position information in a format that NSWindow itself guarantees to be usable for resetting it. It’s not like we couldn’t figure it out ourselves, but AppKit already figuerd it out! Thanks for sharing.

NSToolbar takes a different approach. Instead of allowing developers to participate in the complicated question of “naming” the autosaved information, it offers a simpler API, implying it will come up with a way of saving the information itself:

– autosavesConfiguration  
– setAutosavesConfiguration:  
– configurationDictionary  
– setConfigurationFromDictionary: 

This is a great compromise. We’ve lost the ability to influence naming conventions, but who cares? They still give us access to the magic format! So if we don’t like the way it’s handling autosave, we just turn it off and implement our own with the help of “configurationDictionary.”

But NSTableView, oh NSTableView. You had to go your own way:

– autosaveName  
– setAutosaveName:  
– autosaveTableColumns  
– setAutosaveTableColumns:  

NSTableView lets us alter the autosave name, but unlike NSWindow, merely setting the name doesn’t imply that the feature is active. We have to set that BOOL separately. Notice how NSToolbar’s technique uses the same number of methods, but provides a lot more flexibility. The worst part about NSTableView’s approach is it hides the magic data so we can’t even override the default mechanism.

If only NSTableView exposed its magic data!

I really wanted this functionality, because in developing FlexTime, I decided to offer a feature to “save window layout” to the document itself. The other autosaving mechanisms work well with this approach – just grab the magic data and archive it. NSTableView stymies me, though! Perhaps I could set an autosaveName, then do something to provoke it being saved, then look it up manually. Nah! It’s all too fragile.

NSTableView+RSAutosaving is my solution. Yours too, under MIT License. It’s a category on NSTableView that adds the missing (IMHO) methods:

- dictionaryForAutosavingLayout
- adjustLayoutForAutosavedDictionary:

The “magic data” in this case consists of the widths of every column and their ordering in the table. There are a few subtle gotchas to doing this right, and I think I did it right. So you’ll be glad if you end up not writing it yourself.

Anybody who packages software (or other files) for distribution on the Mac is probably familiar with the tedious process of setting up the icons “just right” in the Finder so that when your customer opens the folder for your app, they see things neatly organized the way you left them.

I don’t know how many times I’ve longed for a “nudge” keyboard shortcut in the Finder. If I could just move that icon one pixel to the left, it would be perfect. Inevitably I click and drag just a little bit too far. It’s hard to get right on the first try!

But today my worries came to an end. My NudgeFinderSelection scripts simply ask the Finder to move all the selected icons in a given direction. Since the behavior is is 99% identical for whichever direction the nudge should be, I just wrote a single script and copied it 3 times. The script examines its own name and determines its functionality accordingly.

Note: Because of this “self-determination,” you can customize your own version to go above and beyond the current behavior. Try making a copy and naming it “NudgeDownRight” for instance, and you’ve got yourself a nice little diagonal nudger.

I hooked up all four of these as Finder-specific shortcuts with FastScripts. Now when I’m tweaking icon layout in the Finder, a nudge is just a short cmd-opt-arrow-key away.

Note: my “clever hack” here begs the question, why doesn’t FastScripts respect symbolic links? It would be much cleaner to have a single copy of the file with multiple references to it. Yes, it’s a grievous shortcoming, and hopefully situations like this will inspire me to remedy it soon.

And since you’ve read this far, I think you deserve a little treat. Ever thought that the icons in a window would look best arranged in sine wave formation? Well, you were probably wrong, but SinusInfection will guide you to forming a permanent opinion. Unfortunately, there’s no undo, so don’t run this with an important Finder window front-most!

It’s not a very polished script, and may take some tweaking to work right on your system. C’est la vie! In particular make sure you have an open window with a substantial number of items in it. And turn off any automatic “keep organized” settings in the Finder view options. I’ve also noticed that Finder can sort of freak out while you’re doing this, apparently because so much is changing out from under it. The sine wave tends to get broken and re-originates at a slightly different window offset.