Apple Bug Reporting: An Illustration Of (some of) The Problem(s)
June 13, 2012

Last November I encountered an issue in Xcode whilst attempting a submission.

I was getting an error due to the fact that some embedded bundles in the application that I was submitting were signed with the wrong identifiers.

Xcode, rather unhelpfully, reported this:

“the nested app bundle ECFoundation ( is not signed, the signature is invalid, or it is not signed with an Apple submission certificate. Refer to the Code Signing and Application Sandboxing Guide for more information.”

I submitted a Radar report, pointing out that whilst having an error message is helpful, it would be even better if it narrowed down the actual cause, rather than suggesting three possibilities and leaving you hanging.

Last week, I got the first response to this report:

“We believe that this issue has been resolved through changes on our side.

Please let us know whether the issue is resolved for you.”

Now first of all, let me say that I appreciate getting the response.

The first sentence is really helpful, as it sets my expectations - if I use the latest Xcode, it’s probably fixed.

The second sentence is a little irksome. If they’d just said “Please let us know if you notice any problems”, I’d be fine with it.

Even as it is, I do realise that it’s probably just a stock response, and I shouldn’t read too much into it, but it does slightly irritate me.

Think about it for a minute. I had an issue seven and a half months ago. It was an issue with submission. Am I really likely to still have something that exhibits that issue?

“What about source control?” I hear you cry (that was you, wasn’t it?). And yes, you’re right, I could wind back in git and get the project into the state it was in then. But hang on, it was a problem with submission. So I’d need to do a submission again. Now forgive me for being a wuss, but I’m not in a great hurry to submit a new version with seven-and-a-half-month-old code. I could probably do it - add a fake new version, hack around the old code to have the right version numbers, perform the submission, cancel it if it worked, and so on.

We’re starting to talk about a bit of an investment in time now though. Maybe only an hour or two, but it’s funny how these sorts of things have a habit of taking longer than you expect. Now I don’t fall into the trap of immediately equating any time spent doing anything in my life with the hourly rate I charge in my working life, but…

And thus we see some of the problems with the bug reporting dance:

All of this leads to the feeling of futility / apathy that I’ve mentioned in previous posts.

I’m sure I could make a test case and satisfy myself that the problem is fixed. Maybe offer further feedback on the solution they’ve come up with. If I happen to encounter it again in passing, I will. If I’d had a personal email from someone on the Xcode team, I’m sure I’d do it right now, no matter how long it took (despite the fact that I wouldn’t be doing anything that they couldn’t do themselves), just because it’s nice to feel involved in the future of the tools that I use.

In the absence of that email though, going out of my way just feels, frankly, like it wouldn’t be worth the effort.

« Ambientweet 1.1 now in the store Mac Pro Update? Think Different... »
Got a comment on this post? Let us know at @elegantchaoscom.