Apple’s bug reporting system (imaginatively called Apple Bug Reporter to the outside world, but known as Radar internally I believe), is essentially closed.

What this means is that you can’t check up on a bug that you didn’t originate, you can’t share your bug report with other developers for testing, discussion or corroboration, and you can’t search for existing or similar issues.

This really really sucks. Recently I’ve been filing quite a few bugs, mostly on the development tool that I use most often - Xcode.

Previously I’ve been quite bad at reporting bugs. Two of the main reasons for that were lack of time, and lack of feedback.

Lack of time boils down to the fact that in the past I generally didn’t work for myself, and I was usually massively overworked / or at least my time was greatly over-committed by my bosses. This lead to the perpetual feeling that I was running to catch up and had no justification to indulge myself with anything time consuming that wasn’t worth the effort.

Generally I was actually very good at resisting the (mostly illusory) sense that it wasn’t worth doing something that had long-term benefits, because of short-term pressure. However, often I didn’t bother filing bugs to Apple, because of the combination of my lack of time with the second problem - lack of feedback.

Filing bugs in Radar quite often feels like sending text direct to /dev/null, in terms of the sense one gets that the effort spent doing it is worthwhile.

One reason for this is that the interface for doing so is incredibly primitive, and consequently filing bugs feels slow and awkward.

The other reason is that, as a developer, I’m only too aware of the need to not only be precise in the report, but to include lots of information. It’s hard to find the time to do this properly at the best of times (indeed many full-time testers that I’ve worked with seem to find it impossible, despite it being their job, but that’s another story). It’s even harder to find the will to do it if you can’t check first whether you’re wasting your time reporting something that already has 1000 duplicate reports.

Now that I’m indy (yay!), I have been making more of an effort. If I find a bug, or have a feature suggestion, I try to report it.

It still feels painful though. When I do report an issue, I often don’t supply nearly as much information as I’d like if I was the developer on the other end, because I still feel that I haven’t got the time to waste on taking a punt that someone somewhere actually gives a damn about what I’m saying.

Lest anyone should misunderstand, it’s not that I think that the Apple engineers, chained to their desks in their darkened coding dungeons in Cupertino, don’t care. I’m sure that they very much care (well, most of them), but most of the time the bug reporting system is a bloody great big emotion filter that manages to prevent any hint of that caring seeping out across the divide back to us mere mortals.

There are many things that Apple could do to improve this process.

When it comes to the reporting of bugs, the web interface could be better. Standalone Mac/iPhone/iPad applications could be written which can automatically fill in most of the contextual information that one needs to provide. The “Report A Bug” menu command could become standard in Apple applications, and a de-facto standard everywhere, with coding support to make it easy to implement.

Best of all though, the bug reporting system could be partially opened up.

I don’t want some sort of open source anarchic free-for-all where any Tom, Dick or Harry can get into a flame war with the developer responsible for implementing a feature or fixing a bug.

At the very least though I’d like to be able to do some sort of web search on a problem description and be told “45 issues match this problem” - even if I couldn’t see those issues.

Better still, I’d like to be shown the summaries of those bugs, if not the full bug reports.

Of course it would have to be possible to mark bugs as private (if they contain proprietary information), and in any case I’d only expect to be able to do this after logging in with my developer id - so Apple would have full control over what level of access I was given to a particular bug. Perhaps based on some internal concept they had of my level of experience, trustworthiness, the help I’d given tracking down previous bugs, etc.

Ideally I’d also like to be able to explicitly share bugs with colleagues, by attaching them to the bug so that they have full access.

And I’d like the bug reporting system to be integrated with the developer forums so that it was possible to have a forum thread linked to one or more bugs in a way that allowed a discussion surrounding a particular issue to be clearly associated with the bug id.

I’d like to be able to +1 a bug as a very quick indication that I also had it, or +1 a feature request as a way of adding my vote to it.

This stuff isn’t rocket science. I know that Apple has a lot of important stuff to do, but the strength and helpfulness of the developer community is one of it’s hidden assets. It would be great if Apple could show us diligent bug reporters a little bit of love.

A couple of new betas are available from the beta software page.

Neu 1.2b7 includes a couple of minor tweaks to the UI, and a revised manual. I know that there are a few typos to fix in the manual, but I’d definitely appreciate any other feedback on it, or the changes in Neu 1.2. I’m hoping to submit this version to the App store soon.

Ambientweet 1.0.2b1 fixes a stall that has been reportedly happening in Ambientweet - where it simply stops working after an hour or two. Again, all feedback greatly appreciated.

I’m pleased to announce that over this weekend, we’re running a 50% off offer on Neu. For this period it will be available for the bargain price of $5!

We’re also holding Ambientweet at it’s current price (free!) over this period - after which it will actually cost something!

Go get em whilst they’re hot…

Ambientweet 1.0.1 is out!

This version has a whole raft of improvements, including:

• Reduced the frequency of refreshes, to avoid running over the Twitter call limit.
• Post windows now use the same style as the main tweet window.
• The length of posts is now calculated intelligently to account for link shortening. So if you paste in a long link, it won’t use up all of your character count, as the link will be shortened in the actual post.
• Auto-completion list for @users in post window now includes all users that the app has encountered.
• Now correctly restores cached tweets and users when loading.
• Added subtle gradient to window backgrounds.
• Fixed beta Sparkle feed URL (the app was looking at the non-beta feed instead).
• Updated the manual with screenshots of new posting UI.
• Fixed window resizing.
• Improved sorting, refreshing with new items.
• Changed user guide code to be sandbox-friendly (copies guide into the Caches folder and opens it from there).

There are lots more improvements and new features on the way in a future version, please give 1.0.1 a try!

During a recent submission I came across a problem.

I got an automatically generated email back from Apple with this sort of thing in it:

Invalid Signature - the nested app bundle ECFoundation 
(Ambientweet.app/Contents/Frameworks/ECFoundation.framework)
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.

It’s a bit annoying that the email is capable of spotting that I have one of three possible problems, but not narrowing the actual cause down for me. It’s also a bit annoying that this only runs when you’ve submitted, and not when you verify an application with Xcode.

Be that as it may… … the main point is that it looks like Apple are starting to require that all code inside your application bundle is signed. This includes any frameworks or plugins you’ve embedded, even if you didn’t actually build them.

I’m slightly mystified as to why Xcode doesn’t do this for you at the point when you submit - since it asks you for an indentity to use, and presumably does some re-signing with it at this point.

However, as luck would have it, it’s fairly easy to write a script to do what we need.

for f in "${CODESIGNING_FOLDER_PATH}/Contents/PlugIns/"*
do
    BUNDLEID=`/usr/libexec/PlistBuddy -c "Print :CFBundleIdentifier" "$f/Contents/Info.plist"`
    codesign -f -i ${BUNDLEID} -vv -s "${CODE_SIGN_IDENTITY}" "$f"
done
 
for f in "${CODESIGNING_FOLDER_PATH}/Contents/Frameworks/"*
do
    BUNDLEID=`/usr/libexec/PlistBuddy -c "Print :CFBundleIdentifier" "$f/Resources/Info.plist"`
    codesign -f -i ${BUNDLEID} -vv -s "${CODE_SIGN_IDENTITY}" "$f"
done

This script goes through the build app’s PlugIns and Frameworks folders and signs everything it finds. It uses the application bundle id from each framework/plugin when signing. From one reading of the signing instructions, it sounded like everything bundled in with your app has to have the same bundle id, so this might not be quite the right approach - the script might need to take the bundle id from the app, sets the bundle id of each embedded framework to it, and then signs the framework.

However, apps submitted after building with this script don’t seem to generate the warnings, so for now this one seems to do the job.

I’m running the script with a final Run Script build phase in the target for my main application. This means that the bundles and plugins inside the app will always get signed, whatever configuration I choose.

Alternatively, you could probably run it as a post-action script in the Archive part of your build scheme, so that the extra signing only gets done when you’re about to submit. Actually I think that’s probably more in line with Apple’s advice, which seems to be not to sign things until you’re actually submitting them, so as not to give legitimacy to development builds which accidentally escape into the wild. However, I’m not certain that all the environment variables that I’m using will be set at that point, so it may be that the script would need modifying. I’ll leave that bit as an exercise for the reader…