We have five Cocoa apps at NewsGator: TapLynx, Social Sites, and three versions of NetNewsWire. They share code.

(You may not have heard of Social Sites. Written by Nick Harris, it’s an iPhone client for our Social Sites enterprise social networking app.)

We’ve just been doing the copy-files thing. Not good. So below I present an (ever-so-slightly edited: took out two words) internal email I just sent about managing the shared code. This is as a sanity check: I think, given our tools, this is the best way to manage this stuff, but I wouldn’t mind hearing that there are other, better ways.

The email: “Shared Code Plan”

Here’s the issue: we have a bunch of code that’s shared between two or more apps. We don’t have a way of managing this right now other than just copying files — which is inconvenient at best, and leads to files being not-quite-the-same in different places as bugs are fixed and features added.

Here’s the solution I’m thinking of. If any of this sounds like the wrong way to go, let me know.

Code shared between two or more apps will all live together in an RSCore repository. (If Apple can keep using NS, we can use RS. I just find the initials more poetic than NG, and that actually, bizarrely, matters to me.) This way the shared code will all be the same for each app.

Existing and new projects will include the RSCore repository as a Mercurial sub-repository (a sub-folder in the project folder).

The RSCore repository will have Foundation and UIKit sub-sections. (This way NetNewsWire/Mac can still use the Foundation stuff.)

A given project will include just what RSCore files it needs. It won’t be presented as a static library, since that makes debugging a pain, and leads to including unnecessary code.

However, RSCore will have a unit tests project, so we can verify code changes before committing, so we can avoid breaking all our apps at once.

Category methods on Foundation and UIKit will begin with an rs_ prefix, to avoid namespace collisions.

New classes in RSCore will be prefixed with RS.

We’ll be conservative about what we add. Only things that are for sure used in more than one app will go in there.

The idea is not to make additional work, but to make less work in the future, to make all this manageable, to increase productivity.

On Macs we have a long-standing culture of apps working together. I can think of a few examples from my own Mac app: you can send a podcast to iTunes, send an article to Twitterrific to tweet it, or send an article to MarsEdit to post it to your weblog.

Of course, on a Mac, the calling app doesn’t quit when you do these things. It stays open. You can get right back to it. (In some cases, the calling app stays in front the whole time, like when sending a podcast from NetNewsWire to iTunes.)

On the iPad (and iPhone) we can sort-of do the same thing. We don’t have AppleScript or Apple events, but we do have the URL scheme thing for inter-application communication. It’s technically possible to do some of these same things.

But we don’t have an easy way to get back to the calling app. Imagine a hypothetical case like this:

You’re in Twitterrific, looking at a web page, and there’s a link to a feed. You want to subscribe to that feed.

So you choose a “Subscribe in NetNewsWire” command. It opens NetNewsWire and subscribes to the feed.

Now that you’ve done that, you want to get back to your place in Twitterrific. You want it to be exactly as if it never quit.

We can do #1 and #2. It’s #3 that’s tricky.

So I have an idea. It just came to me, so I don’t know if it’s good or bad — but it’s worth posting, at least.

What if the calling app added, as a parameter to the URL, a URL to call when the task is completed?

This way the helper app (NetNewsWire in this case) would know, once the task is complete, how to get the user back to their place in the calling app (Twitterrific in this case).

The helper app wouldn’t even have to know anything about the calling app — it’s opening the URL that it was handed. (Maybe there’d be a spot for a success/fail return code of some kind too, but that’s a small side issue.)

curry.com: “If my intuition is right, I think we might even see app programmers become the heroes of a generation, where fans can’t wait for the release of the next magical app their idol has become famous for.”

Wolf: “Software engineering is advancing, albeit at a glacial pace. I spend most of my days writing in languages and using tools that were obsolete over a decade ago.”

Wolf talks about the lack of outcry over section 3.3.1. I’ve not cried out. I’ve been apathetic about it.

Well, maybe not totally apathetic — mostly I was glad because I don’t like Flash. I don’t like Flash because I’ve wasted too much time over the years dealing with Flash crashes.

But mainly I’ve been apathetic. Even though 3.3.1 isn’t all about Flash.

I don’t have time to care about everything. Should I make the time for this? I just don’t know. I don’t expect it will ever affect me personally, so it makes it that much tougher to care about. That’s not a laudable position, but it’s accurate (for me).

But there’s one notable thing here: there is no App Store for Macs, and no section 3.3.1 for Macs. C4 began as a Mac conference, and it could remain a Mac conference. I’ve been to every single one, and I’d love to go again. They’re been hugely valuable to me.

Regardless, Wolf deserves another huge round of applause and the heartfelt thanks of many people for putting on C4. It was always awesome.

But lately his tweets have done extra duty of getting the word out about the catastrophic flooding in Nashville. For some reason it seems like the national broadcast media have been slower than normal in getting to this story.

Look. When a city is in trouble, we have to pay attention and we have to help. We all know this.

Nashville is not the dark side of the moon: it’s home to a civilization of people who get out of bed, work, play, feed the cat, watch TV, make things, wonder about the future, learn things, drink a few beers, mow the lawn — and who are united now in wishing the rains hadn’t fallen like this, and who now need help.