I generally don't like releasing apps for direct customers and then waiting for the App Store review process to complete before MAS purchasers get the update. It's feels a whole lot better to say "hey, it's out for everyone, go get it now!", and there's also the support you have to deal with when people write in to ask where it is, and why their version isn't updating. (For the record- 4.2 has been submitted and is "Waiting for Review" at Apple right now).
However, for this update there were a number of factors that lead to me deciding to release direct first, the foremost being the the lag time between submitting an app and when it actually gets released.
What if there was a critical bug that I missed during beta testing, and I had to wait another 10 days for that to get through? Acorn already burned an expedited review this year with the 4.0 release, and you generally need to tiptoe around the review process so you don't give them any reason to hold a grudge against you. I didn't want to take that chance.
Even worse - what if there was a critical bug, but I found out about it during the annual holiday shutdown? That's another seven days where nobody is reviewing apps and the bug stays out in customer hands. Double ungood. (I'm actually kind of taking this chance as it is, assuming Acorn is reviewed and out before the shutdown and I then encounter a critical bug).
So those are the obvious reasons. But why would I be worrying about a critical bug this time around when I normally wouldn't? This was just a 4.x update after all.
After years of coding and shipping, you begin to develop a bit of a spidey sense about your products and the state that they are in. Acorn 4.2 was solid as far as myself and the beta testers were concerned, and there were no known bugs that would keep it from shipping. But… well, sometimes you just need to trust your instincts on these things. Two major changes were were sitting there in the back of my mind that I knew were going to cause issues.
The first one I've already written about previously- which are the changes for rendering through OpenGL. So I won't go into that.
The second worrying change seems minor, but I knew it was going to be the source of some sort of major bug even if I didn't know what it was yet. Known unknowns if you will.
The SDK that Acorn links against for 4.2 changed from 10.8 to 10.9 (Acorn 4.2 still runs on 10.8 though, we're just linking against 10.9).
No big deal, right?
Technical Cocoa coding stuff from here on out.
Here's something you might not be aware about as a Cocoa developer- but it's essential that you do. Runtime behavior of the frameworks will change based on the SDK that you link against. So I knew that when I changed to 10.9, AppKit would take different code paths.
For instance, drawing sped up a bit when linking against 10.9. This is something I very much wanted.
However I knew that by doing this other code paths would probably be changing as well. Some things might be faster and some things might be "different". I found one of those changes yesterday. Here's some very simple code that Acorn uses when opening up a PDF:
NSData *data = … // path to a PDF with a width of 512 at 72 dpi. NSPDFImageRep *r = [[NSPDFImageRep alloc] initWithData:data]; NSInteger width = [r pixelsWide];
Linking against 10.8, the width variable is now equal to 512. Linking against 10.9, the width variable is now equal to 0.
Whoops. So this meant that Acorn could no longer open up PDFs correctly. Apparently nobody including myself noticed that, or at least someone found it but didn't let me know (this happens every once in a while - somebody finds a bug that's so obvious, I must know about it. So they don't bother to report it. And then it ships and then they let me know about it. Bad times for everyone involved).
The workaround was to call
Known unknowns. Spidey sense. I just knew there was going to be a silly bug like this. And since I can update the direct builds in a matter of minutes, it was easy to get a fix out for everyone. With the App Store - well, it's not so easy.
I want Acorn to be as solid as it can be, but sometimes a soft rollout like this is the best course of action even though you want to get it in everyone's hands as fast as you can.
Bonus Cocoa Pro Tip:
Here's something that might help you out in the future, as Ken Ferry let us know on Twitter: "You can set -NSLogUnusualAppConfig YES to see at least some places AppKit is doing linked-on-after checks that affect you". Which can be pretty handy.