For Vesper we use Lighthouse — which I like a lot. But I got email from Robert Kern at Bugify, which I hadn’t heard of — and, judging by the website and screen shots, it looks worth checking out.

While we don’t plan to switch, I do recommend checking it out if you’re looking for a bug tracker. (It has an API.)

Here are the slides for my talk at AltWWDC as a PDF.

The title: How I Made Vesper. Once there’s a link to the video for my talk, I’ll post that.

AltWWDC was such a cool thing. Many thanks to Judy and Mike and all the volunteers and speakers.

Check out objc.io. Looks great.

I’ve Instapaper-ed every article, so I have something to read while folks who have WWDC tickets are attending sessions.

If I had one feature request, it would be an RSS feed for the site.

Since I’m always interested in hearing what other teams use to work together and ship their software, I figure I should list what we use to work together on Vesper.

Mercurial

To swim with the current these days is to use git. But I like Mercurial better — and I think Mercurial is to Macintosh as git is to Windows. That’s probably not fair or rational, but it doesn’t really matter, since both git and Mercurial are excellent systems.

Along with Mercurial we use Bitbucket. I rarely had to log in to the site — which is as it should be. It just worked.

All of us use Mercurial on the command line.

Glassboard

Almost all of our company communication is via Glassboard. We’ve sent just a few emails and a few more text messages — but mostly it’s been Glassboard.

(This is the second app I’ve shipped with the aide of Glassboard. The first was Glassboard itself.)

In addition to our company board, we have a board that includes Doug Russell and Nick Arnott, our accessibility and QA experts, and we have a board for beta testers.

In the past, before Glassboard, we would have used a discussion list because it’s valuable when testers are able to discuss things with us and each other. It becomes collaborative, and it makes for better software.

My first experience with this model goes back to my days at UserLand Software in the ’90s when we had a testers mailing list for Frontier. It was so productive, and so much fun, that I’ve used this same model for all of my subsequent apps.

Lighthouse

Lighthouse bills itself as “beautifully simple issue tracking,” and to its credit I’m not sure what else there is to say. It’s a bug tracker. It looks nice. It’s easy to use. It works well.

We made heavy use of the milestones feature. We tend to tag tickets. We don’t order tickets by priority. (My internal algorithm defeats priorities. When there isn’t a clear choice, I pick based on how long it is till dinner, whether or not I’m tired, what I just completed, and what mood I’m in.)

In the last few weeks of the project, I measured progress by calculating how many tickets we’d have to close per day. If that number kept going up, then hitting our ship date was at risk. (We hit our date.) (After revising our early naive schedule.)

HockeyApp

We use HockeyApp to distribute builds to testers. My favorite HockeyApp feature: symbolicated crash logs. My second-favorite feature: email notifications when there’s a crash.

In the past I’ve used TestFlight, which I also like very much. Both are an incredible improvement over the old days of passing around .ipa files and provisioning profiles.

Dave, John, and I are guests on Debug 15.

Local hero Doug Russell worked on accessibility for Vesper — and wrote it up on his (aptly-named) Taking Notes blog.

Vesper is on the App Store.

I’m especially proud of the work my co-workers Dave Wiskus and John Gruber did. I had the privilege and fun of making their designs real.

I started working on it in early February. John and Dave had a head-start on the design. It’s been an intense several months of coding and iteration, and I’m really happy to be able to present it to you now.

Of all the software I’ve ever made, just two were lovable from the moment I started writing code. This is one of them.

• SecondConf 2013 registration is open. I wish I was going.

• I’ll be speaking at AltWWDC on technical topics.

• I’ll be speaking at 360iDev on using SQLite plus FMDB instead of Core Data — why you’d want to and how to do it.

In Identical Cousins 17 Michael and I talk to Jonathan Deutsch, one of the geniuses behind Hype.

Nick Bradbury — my friend, co-worker at NewsGator and Sepia Labs, developer of HomeSite, TopStyle, FeedDemon, and Glassboard — starts work at Automattic on Monday.

Congratulations to Automattic on hiring a great developer!

In this episode, Michael and I have the fun of interviewing Chris Liscio, who makes the super-mega-ultra-groovy audio apps Capo, FuzzMeasure, and TapeDeck.

I was a guest on Daniel Jalkut’s Bitsplitting podcast. It was fun! Many thanks to Daniel.

Tom Harrington continues his series of posts on iCloud and Core Data.

I’ve seen addPersistentStoreWithType:​etcetera: block for 30 minutes. And keep in mind, this is when iCloud is working normally. This is not an error condition, this is “working as designed.”

He suggests a solution: using two separate databases, one for normal use and one just for syncing, with custom code that shuttles data between the two.

That solution points to what bothers me about the whole thing, which is that this is all too tightly-coupled. Ideally your storage system and syncing system are not the same thing, and you could swap out one for another.

This would allow for flexibility and efficiencies that you can’t get when you just say “here’s my database; please sync it, iCloud.”

Apple and Backend Services for Apps

Imagine Apple announced something that worked like this:

• You go to a website somewhere at apple.com and set up a backend for your app.

• You create a database for it and a custom https API. You might have to write some code — but it would be in a popular scripting language, nothing weird. All this with a browser-based UI.

• Apple provides a client framework for making calls to the server.

• Authentication is completely taken care of — the system uses iCloud credentials, and your app doesn’t have to do anything. (It just knows if you’re authenticated or not.) In your app a user never has to sign in or create an account or anything like that.

• Everything Apple stores is automatically encrypted. Apple’s server takes care of encrypting/decrypting automatically, so your code (in the client or on the server) never has to deal with that.

• Apple’s system provides the ability run periodic tasks (like polling Twitter, App.net, or RSS feeds).

This would be more general than just a syncing solution, but you could use it just for syncing. Or you could add more sophisticated backend services. (You could write an RSS reader with this or something social like Glassboard.)

It would have to cost money, of course.

And you’d have to write code; you’d have to design your syncing system. But it would give you abilities you don’t have with iCloud Core Data syncing, and it would decouple your database and syncing, which is the right way to go.

I’ve mentioned Azure Mobile Services before, which I like because it’s in spitting-distance of an idealized Apple service. I would go so far as to suggest that Apple and Microsoft should partner to provide this service. Play to each company’s strengths.

(Disclaimer: Mobile Services paid me to do some videos for them and has sponsored my podcast.)

Syncing is only part of the future

Even if Apple works out syncing — somehow — that’s just not enough. That just gets us to where we should have been in 2008. The future belongs to apps with more sophisticated services.

And the future belongs (in part) to whoever provides those services. If you’re an iOS or Mac developer, you’d like it to be Apple.

Here’s what should worry folks at Apple: that Google provides something like the above for Android developers. Google obviously has the expertise, and it wants to make Android more attractive to developers.

(Yes, there’s Google App Engine, but I’m imagining something easier.)

Or, put another way: the backend system will become nearly as important as the UI frameworks, and plain-old-syncing isn’t enough.

I wasn’t clear on it completely. So I asked Dave, and he answered.

WWDC sold out in three minutes. (Or less.) I didn’t manage to get a ticket, though I did try.

I have a feeling that AltWWDC is gonna be huge this year. (I’ll be there — I’m speaking. I’d be there even if I weren’t.)

It was only a few years ago when WWDC didn’t sell out at all. It even had Early Bird pricing.

Michael and I just winged it with episode 15.

We have some sponsorship slots open for future episodes of Identical Cousins, the podcast I do with Michael Simmons.

If you might be interested, contact me or Michael. (There’s Twitter info on the site. Or you can email me using brent plus the domain name of the business I own.)

Past sponsors have included Windows Azure Mobile Services, FastSpring, and Pinbook. You’d be in great company.

Alex Kessinger estimates the size of market that will pay for an RSS reader.

Small Picture, Dave Winer’s new company, introduced Fargo today. It’s an outliner that runs in your browser and saves to Dropbox. The file format is OPML, so you can edit those documents in other apps (such as OmniOutliner) that support OPML.

Michael and I talk to Nick Bradbury in Identical Cousins 14: Partners in Crime.