We’ve been pretty busy in recent months, with a number of contracting jobs, including a bit of work with the lovely folks over at Karelia software.

Live music is dear to our hearts though, so we’re planning on taking some time out this week to attend the excellent Hebridean Celtic festival, which happens each year here in Stornoway, on the Scottish island of Lewis in the Outer Hebrides.

The festival is very much a labour of love, and although it attracts a large audience from all over the world, it’s run by a charitable trust. So when they came to me to ask about the possibility of doing an app, I was rather keen to get involved (although a little scared at how little time we had to get something ready for this year).

After a bit of nifty footwork, and a few anxious nights waiting for Apple’s review process, the result is this little app. Given the amount of time we had, we decided to keep it simple, but we’re rather pleased with the results. Hopefully, the festival organisers are too.

Apple are due to release OS X Mountain Lion soon.

One of the features included in it is something called Gatekeeper, which is intended to improve security. By default, when you install Mountain Lion, you will only be able to run newly downloaded applications if they have been signed by the developer, using an official Apple developer identity (note that you can turn this behaviour off, but that’s the default setting).

What this means in practise for you, with regard to Neu and/or Ambientweet?

If you’re using copies of Neu or Ambientweet downloaded from the Apple store, there will be no change.

In any event, there will be no change if you continue to use copies that you’ve already downloaded (ie on another machine or with a previous version of the system).

If you download the current version of Ambientweet (1.1) or Neu (1.2) from our website, they are currently not signed in the correct way, so Gatekeeper will complain about them. There is a way that you can tell Gatekeeper to make an exception, but that’s not really an ideal solution in the long term, so we’re preparing a quick update to bring Ambientweet up to version 1.1.1, and Neu to 1.2.1.

The only change for these versions is that they will be signed correctly and Gatekeeper will recognise them as legitimate.

If you want to test beta versions of these applications, they should be available later today from the beta software page. Barring any reported problems, they’ll then go live in the next few days.

Since the only purpose of these updates is to prepare for Gatekeeper, and since Gatekeeper already accepts applications downloaded from the Apple store, these updates will not be submitted to the store. If you’re using versions from the store, you can safely continue with versions 1.1 or 1.2 of Ambientweet and Neu respectively.

Proper updates, with more features, will arrive in due course, bringing the store and non-store versions back into line again.

My first desktop Mac was a IIcx, bought in about 1989, for the astounding sum of nearly £4000 (to put that in context, it took me a year of working between school and university to pay for it, and I could have bought a new Ford Fiesta for less).

Since then, as a Mac developer, I’ve owned and used many more, pretty much always the top spec of the current generation. There was certainly a time when having the latest, greatest desktop machine was essential (not to mention highly desirable for the sheer geeky joy of it).

However, since going back to indy development in 2010, I’ve only worked on my laptop, and I didn’t have a desktop machine at home for a good few years prior to that, despite regularly working from home on a big game with masses of data.

So the recent speculation leading up to WWDC about whether the Mac Pro would get an update, and the subsequent answer (“not really, well maybe slightly, but there’s something new coming next year”), lead me to ponder what I’d actually want. The four things that I can see a desktop might offer me are:

• more power (processing and memory)
• more storage
• more screen real estate
• the ability add custom hardware

The conclusion I came to is that with all of these things, what I actually want isn’t really a desktop machine at all.

Conceptually what I want is one or more black boxes (well, maybe shiny aluminium boxes), that I can plug into my laptop (or perhaps hang on the network), which expand its capabilities.

In performance terms, these boxes should behave as near as possible as if they were inside the laptop, hanging directly off the main system bus, but other than that, they really don’t have to be housed in one big lump under my desk.

Whether Thunderbolt is up to the sort of load this would impose, I don’t know. For storage, I suspect that it is, and solutions are already there.

To some extent screen real estate may be too, although I’m not sure what sort of external monitor the new retina Mac Book Pro will be able to drive in addition to it’s own monster display.

If it were possible to house additional video hardware at the other end of a Thunderbolt cable (maybe it is?), so that one could effectively plug in additional video cards via the cable, this would pretty much remove the need for a desktop Mac as a way to drive a silly numbers of monitors.

Similarly, custom hardware, encoders and input cards, and so on, can and should probably live at the other end of a Thunderbolt cable.

All of which just leaves processing power and memory.

Given the bandwidth requirements of both, it’s clearly unlikely to be possible to add these directly to a laptop as if they were on the main logic board, but I’d love to see Apple try to get as close as it could to that.

Wouldn’t it be great to have a Mac-Mini / Airport Extreme sized box that required little or no configuration and just made your laptop more powerful when you plugged it in?

To some extent, things like distributed compilation offer this already. We used to have a pretty excellent setup for the Mac when I worked at SI, distributing to a large number of high end Mac Pros, and it really improved the build times. I think that got a bit broken with Xcode 4 though, and since then I’ve tried it at home with limited results, but only attempting to distribute to a machine with pretty much the same power as my laptop.

Given the increasingly distributed and task oriented nature of the code we all write these days, an approach which we need anyway to take advantage of the multiple cores already in our machines, it seems like some sort of generic solution allowing us to scale up the power of a machine ought to be a lot more achievable now than it was in the past.

Data is the big problem - getting the right stuff to the right processor in a timely fashion is tricky (just ask anyone who’s ever written code for a PS3) - but it’s not insurmountable.

Abstractions like GCD and NSOperation are probably a bit too fine grained to be transparently parcelled out to an external processor, but if we had another abstraction for encapsulating slightly larger chunks of work along with the data needed to do them, we’d have a chance of making this sort of thing fly. Things like XPC could really help here, allowing whole abstract services to run without the client process having to know or care where.

Nothing I’m talking about is revolutionary of course, but packing it up in a really clean, modular, elegant way that can be used by pro-consumers would be. And who better to do it than Apple?

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 (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.”

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:

• the response is so late that the problem is no longer current
• the response is so impersonal that I don’t quite know whether to interpret it as a courtesy, or a serious request for help
• the response doesn’t appear to acknowledge the difficulty of following it up
• incidentally, the response didn’t tell me which version fixes the problem

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.

I’m happy to say that Ambientweet 1.1 has been approved for release and is now in the store.

The main changes in this version are:

• Added ability to view the results of a search.
• Fixed bug where a message containing links could get truncated.
• Fixed clipping of author info when it spills onto three lines.
• Fixed auto-completion window popping up again straight away after a completion.
• Improved tweet caching so that mentions are always kept - this stops the badge being shown again for mentions that have already been seen.
• Added a “psuedo tweet” which is a reminder that you’re running a pre-release or unlicensed version of Ambientweet (if you are). It is inserted into the tweet stream every now and then.
• Improved application security.

You can find more details, and download links, on the Ambientweet home page.