Solipsism Gradient

No, not that VersionTracker…

As regular readers might recall, my last versions of Zingg! feature an improved update query that allows me to tabulate which Mac OS X version the client is running. Preliminary results show that roughly 3 out of 4 Zingg! users are running Mac OS X 10.3 (Panther). Nearly all Panther users are running 10.3.2… but curiously, about 15% of the Jaguar users have not yet updated to 10.2.8, the last Jaguar release. These figures may be distorted by the fact that most users who check regularly for new versions will of course also upgrade to the latest Mac OS X as soon as possible.

There are no figures for 10.1.x users, as there’s no way to distinguish them from users of XRay, which doesn’t yet have the new version-tracking code. In any event, other surveys have found that they number under 10% (some say 5%) of active Mac OS X users. I don’t plan to support 10.1.x for any new version of my products, and indeed no longer have a Mac that runs it available for testing.

Starting with Jaguar, Mac OS X has facilities for weak-linking system calls and for easily checking if certain calls are available or not. This makes writing software that runs on both older and newer systems much easier. Hopefully Panther adoption rates will be such that I’ll soon be able to release Panther-only software.

Positive feedback on Nudge is mounting. There’ve been over 3000 downloads so far in 3 days, beating XRay‘s 2800 and Zingg!‘s 2000+ downloads over the whole month!

c.k. over at 3650 and a 12-inch links to Nudge and suggests:

Apple should send him a rather large donation for providing a solution to one of their major Finder bugs…

Not that I would mind… 😆

I’m sure that the Apple folks are working hard at this. However, from the rumor sites, it seems they’re stretched rather thin at the moment, working on Mac OS X 10.3.3. Also, Nudge is more of a stop-gap solution; I certainly wouldn’t want it made permanent.

The links and referrals stemming from John Gruber’s article are becoming too numerous to list. This shows, once again, how word of mouth is important for Mac developers. I also found a flattering side-effect at Ryan Wilcox’s h4ck3r+=boi:

Brent Simmons has created a Mac Software Business mailing list on Yahoo Groups.

The description: “This group is for small, independent Macintosh developers who want to talk with other developers about the business of Mac development. Questions on pricing, packaging, advertising, e-commerce providers, and so on are on-topic. Note that this list isn’t a vehicle for promotion: announcements and press releases are off-topic.”

The members of the group include some heavy hitters in the Mac Software industry, in addition to Brent: Rainer Brockerhoff, Michael Tsai, along with a cast of additional others.

Brent’s mailing list seems to have great potential; if you’re a shareware/indieware developer, I recommend it highly.

I was tabulating the income from XRay registrations and thought the graph might be interesting for other shareware authors:

The initial peak is probably due to the fact that I had a relatively long public beta period – about 6 months, if I recall correctly – so the product was already well-known when 1.0 came out. I suppose that software released without a public beta would have a registration peak some weeks after release. After such a peak, if the product is left alone, registrations fall exponentially, approaching but never quite reaching zero.

The 1.0.5 release seems to have been well-timed; the curve had already stopped falling steeply and there was demand for new functionality, so the new version attracted a number of new clients. Publicity was favorable and XRay had been included on several CDROMs (some of which published the previous version), so there was a new, shallower peak.

For various reasons I then stepped on the ball, as they say here, and essentially left the product alone for nearly a year, except of course for user support. I should have begun working on 1.0.6 (or even 1.1) immediately, aiming for a release date around November 2002, to jack the curve up again. When I finally went back to the old drawing board a couple of months ago, the initial buzz about the product had long died down, and some of the functions which made it attractive when Mac OS X 10.1.x was new had been gradually added to later releases over time.

So the slight peak for the recent string of releases is due solely to some new users attracted by the release notices; there’ve been no reviews for some time, though I believe a couple will come out now. So part of the lukewarm reception is probably due to a lack of proper publicity; the bulk of downloads, from what I gather from my e-mail statistics, was from already registered users.

So the correct strategy now seems to be, release 1.1 with sufficient additional functionality to attract a substantial number of new users, and generate sufficient publicity around it. I’m working on that…

Well, it turned out that I had skipped step 16 on my long list of “just to make sure”, or rather, I’d neglected to do that after uploading a corrected image. For the second time.

No idea why it went wrong two times, but on the third everything seems OK. Meanwhile, new XRay users should download 1.0.9 again if they see a message “…Sorry, but to set everything up properly you must first run XRay once from an Administrator account.”

I woke up about 3AM to get a glass of water and on the way back from the kitchen I somehow felt I had to check my e-mail… I know that’s a symptom of something-or-other, but anyway it allowed me to see one user’s alert about my error several hours sooner than usual, and do damage control.

I posted the bug-fixed XRay today as 1.0.9. Bumping the version number was the best way to alert people that something had changed, and sites like VersionTracker (XRay@VT) and MacUpdate (XRay@MU) are geared to changing version numbers too.

Here’s the usual routine which I follow for publishing XRay, in case someone’s interested.

1- Check and rewrite the internal log I keep of all changes. Also check and rewrite all the help files, including the many screen shots.

2- In Xcode, “Clean all Targets” (which will delete the application and subsidiary things like the XRay Contextual Menu and the Developer Plugin).

3- Remove the old copies of XRay, preferences and whatnot, to simulate XRay being installed on a pristine machine.

4- Build in “Development” mode and run under the debugger. Should anything untoward happen the debugger should show me where.

5- Quit and run again. Everything should be OK.

6- Quit, remove preferences and so forth, mount the disk image of the previous version and run XRay once from there to generate old preferences. Quit. Unmount the old image.

7- Run the new version under the debugger to simulate XRay being upgraded on a user’s machine. Quit again.

8- Copy XRay into /Applications, switch to a non-admin user account, and repeat most of the steps above again.

9- If some bug appeared at any step, rinse and repeat; if not, “Clean all Targets” again and build in “Deployment” mode. This mode builds a smaller, faster program without debugging symbols and other encumbrances.

9a- Currently, a bug in Xcode also builds a program without several essential components, which have to be copied in by hand. Curse and repeat until OK.

10- Copy the built program into /Applications, run just to make sure.

11- Run again from a non-user admin, just to make sure.

12- Fire up the trusty ol’ iMac DV/400, with its Mac OS X 10.2.8, and check if everything works there too, JTMS.

13- On the iMac, copy & paste texts from the help files into the text files that I put on the finished disk image. This has to be done under Jaguar because if I do it under Panther the resulting texts will contain URLs that won’t be readable by Jaguar users.

14- Build a disk image with all the requisite items on it. I use a mixture of tools to do that and I’m still not quite satisfied with the process.

15- Upload the disk image to my site via FTP.

16- Download it again, mount it and try to run from there, JTMS.

17- Edit all HTML files on my site that mention XRay, change the version number and the link to the new disk image, copy the release notes and other text that has changed with the requisite format changes.

18- Upload the HTML files to my site with FTP and check all in the browser, JTMS.

19- Go to the XRay support forum, close out the topic on the old version and open a topic for the new one. Check that all links point at the correct disk image etc., JTMS.

20- Go to the VersionTracker site, post an interim message that the new version is being published, remove obsolete messages referring to the old version.

21- Log in at the VersionTracker site (yes, a different login) and post the changes that will appear in the header and main text. (This time I was extremely surprised that someone at VT already had seen the update on my site and done most of my work for me! Thanks!)

22- Do same steps on the MacUpdate site.

23- Remove the old disk image from my site, at this point downloaders will already get the new image.

24- Loop over the VT and MU sites until the changes are published, then remove the interim messages.

25- Write and send out the press release concerning the new version.

26- Sit back and watch the dough roll in. I wish.

Well, all of this usually takes several hours and is extremely tiring. Unfortunately it’s very easy to forget and skip some of the steps, and of course Murphy is always ready to slip in a bug at that point. The last few releases I always either skipped a step, or inserted one I shouldn’t have: make a last-second change to some source code line or another. Thankfully, if that happens, some kind user always writes in and I get a chance to fix it fast, before too many people download the buggy version…

I also try to experiment with release dates, unless it’s one of those gotta-get-this-out-fast-before-they-notice releases like this last one. It seems that Friday noon (local time) is the best time to release new software; it still makes the news on Mac sites, but very little new software comes out afterwards, so XRay will stay on the front pages over the whole weekend. This also smooths out the first download spike, when most of the registered or regular users get wind of the update and download it; today (a weekday) there were something like 2000 downloads in the first four hours!

Now to get some sleep…

Rainer Brockerhoff wrote:

As Curly (of the Three Stooges) said, “I’m trying to think, but nothing happens!”

Some thinking happened, at least…

A few users sent in crash reports, I poked around various routines that get called when the window is closed, and there was a premature call to free the window’s memory. So I removed that, and it seems to work. I’m still waiting for confirmation for some of the users who complained, but I’m reasonably confident that that might be the correct fix.

The question is, if this is wrong, why does it work in Panther? Go figure…

Anyway, if all goes well, I’ll post a revised build of 1.0.8 sometime tomorrow – unless some other crash report comes in. I’d hate wasting a release number just for a small bug fix – well, I did a few other very small fixes too, but nothing serious. On the other hand, users won’t be alerted by a version change… hmm…

As the German proverb goes, “there’s no rest for the godless”. Just when I thought I could relax a little, several users found a crash in XRay 1.0.8 when running under Mac OS X 10.2.8. So, there we go again…

…let’s hope my Digital IQ will be enough for fixing this. I actually had a similar crash happen a few weeks ago, but I thought I’d fixed it…

Big fat clue just came in: it crashes when closing a window with either the red close button or command-W, but never when using the “Close Window” menu command. This should probably lead me straight to the offending line in the program, but so far, nothing occurs to me.

As Curly (of the Three Stooges) said, “I’m trying to think, but nothing happens!”

Whew. XRay 1.0.8 is out.

Here’s what the finished batch panel looks like, to contrast with the first version mentioned below:

Much better, huh?

Everything was delayed nearly a full day, while I implemented some other stuff based on feedback from beta testers (thank you!). A puzzling crash led me to try to plug some memory leaks, but after messing around for some hours I decided not to tackle this right now; at least that particular crash could be fixed.

Then Xcode decided to go north on me, neglecting to copy parts of my nib files and not executing my copy phases; and this only in deployment mode, in development mode everything worked. After trying the usual things – quitting, cleaning, rebuilding etc. – I copied the @#$%^ things by hand in order not lose any more time…

Then, in the middle of transferring my updated files to my site, my provider goes off the air… after about an hour, it was back. Whew, as I said.

Now for dinner and some sleep… regular blogging may resume soon.