Before Share, I had a rather standard rule when it comes to releasing applications: I used disk images. Specifically, my rule was to use disk images for releases and zip files for betas and the like. It worked fairly well for a while. I was happy with the results but I didn’t realize how much using disk images was holding me back.

I’ll explain more in the extended entry.

Having a good looking disk image is a chore. There’s the expectation that you have a background image, a symbolic link to the /Applications/ folder, and stuff like that. Not to mention that you have to create a disk image to hold all of your information, set it up, and then convert that disk image into a compressed disk image. This was a big barrier to releasing anything.

Oh, sure, there are ways around this. I have a script that will build my front Xcode project and make an appropriately sized disk image. Once I set the background image and position the elements, I click a button and the script continues, compressing it and uploading using my FTP client (Transmit).

Unfortunately, having to set up the disk image is still annoying and I have often calculated whether or not I want to issue a release or wait until I do something else just so I can avoid doing it. It’s just that annoying.

Then I wised up and realized that it just wasn’t worth it. In general, users don’t care if you have a pretty disk image (unless it looks like the background for Delicious Library, that one probably sold a few copies). Also, disk images introduced a unique problem. Some computer users did not understand that you had to drag your application off of the disk image. It sure isn’t obvious or intuitive. So developers like me added the /Applications/ symbolic link and altered the background image to explain how to install.

Here’s a bit of the beauty with zip images: There is no installation. Really, it’s nice to keep all of your applications in /Applications/ but you don’t have to. If you wanted to run everything off of your Desktop, it’d be fine for most applications. If an application needs special placement, it really should have an installer of some kind to avoid any potential problems. Using zip files cut down on user error.

I also didn’t have to worry about pretty backgrounds or whatnot. Instead, my apps have to sell themselves. It cuts down on one level of potential marketing and I think that benefits everyone involved.

I also found that I could update files whenever I pleased. With disk images, I felt like I had to wait for something special. Now, if I find a bug and squash it, I can simply zip up my app and upload it. Current users will be notified that the bug has been fixed in the next update and the next downloaders won’t have to worry about it.

The only problem I’ve had is from people who insist on using StuffIt. I’ve had a couple of complaints that the zip archive couldn’t be decompressed properly when using StuffIt. When this happens, I recommend using the Finder or Compress. Other than that, I’ve convinced myself to use zip files rather exclusively.

Of course, I made a few changes to facilitate this. Share has two version numbers. The first is the normal “x.y.x” and the second is a “build” number. The build number is actually the version number in the subversion repository. Now when I get bug reports and whatnot, I know exactly where the problem popped up or if it’s already been fixed.