These apps have since been rejected three times by the App Store reviewers, and at least part of the problem was the permissions I was requesting for these apps in the sandbox environment. Specifically, the sandboxing environment won’t let me call a system command-line tool to launch Safari (to view my product’s web page) or Mail (so the user can contact me with questions).
This may be a small thing, but to me it’s the proverbial straw that breaks the camel’s back. I’ve used this functionality in my apps for years, I regard it as basic—the ability to contact me via an item in the help menu is simple customer service—and I am unwilling to remove it. Restricting such basic system access is simply ridiculous.
My guess is that he could get this particular functionality working in the sandbox by rewriting his apps to use a different API. However, one of the problems with the sandbox is that adopting it is an open-ended process. You can get one thing working and find that something else doesn’t work—either due to the sandbox’s design or a bug—or that it behaves differently on a different version of Mac OS X. Little of this behavior is documented.
This is also going to mean a change in my development processes. For the past couple of years I have had a cramped and limited view of what my apps could do; I wanted to make sure they did not run [afoul] of App Store guidelines. No more. I will go back to developing the way I prefer: taking full advantage of the Mac’s powerful resources.
Update (2012-11-03): Kevin Walzer:
None of my deep frustrations with the Mac App Store have changed—its slow review time, the technical limitations that sandboxing imposes, and more. But a rational assessment of where my sales comes from says that I can’t ignore the Mac App Store—it truly does enable sales that I couldn’t achieve elsewhere.