Making Vesper, NetNewsWire & OmniOutliner: A Top Dev Interview With Brent Simmons

Surviving as an Indie

Recently, you and John Gruber announced that you are shutting down your app Vesper, which although it was popular hasn’t earned enough money to make it a financial success. If you had to pinpoint the #1 reason why Vesper didn’t earn as much as you had hoped, what would you say it was?

Vesper by John Gruber, Brent Simmons, and Dave Wiskus

If we had done as John suggested in his recent post on Daring Fireball — designed the iOS app first, but then shipped the Mac app before shipping the iOS app — I believe it would have had a much better shot.

Also: I’d probably use Cloudkit for syncing. It didn’t exist when we started, and then it did exist but didn’t have a web API, and we were strongly interested in doing a web version of Vesper. Now that Cloudkit *does* have a web API, it would have suited our needs. This would have saved us a bunch of time and money.

This isn’t the isn’t first time that you pointed out that it’s hard to make a full-time living as an indie iOS developer these days, due to the saturated market, downward price pressure, and other problems. However you have pointed out it’s easier to be an indie macOS developer. Why do you think indie Mac developers are having more success?

Some people are finding success on the iOS App Store — and I congratulate those folks. This includes Omni, where I work.

But I do think it’s far more difficult to make a living as an indie iOS developer in 2016 than it was as a Mac developer in 2005. My suspicion is that in the Mac market, 2016 is not very different from 2005, and you can still make money there. But iOS is like a giant curtain laid across the map, so people don’t see the opportunity.

The thing about Mac users, at least with productivity apps, is that they’ve always been willing to pay for value. They love their Macs, and they love apps that help them get their work done, and they’re very happy to root for and support indie developers. Mac users *want* great apps, and they want us to succeed.

It’s a much smaller market than iOS, sure, but it’s full of people who love apps and let it show. I love writing Mac apps in large part *because* of Mac users. They’re the best. They’re our partners.

What advice would you give someone who would love to quit their job and try being an indie developer?

In 2008 I wrote Advice for Indies, which includes these lines:

I’ve worn out a few chairs. So much of it is work ethic. Keep doing it. You might want to go play Destiny or watch Doctor Who — but you’ve got a feature to finish and bugs to fix.

That’s not to say that you shouldn’t have a life. You should, absolutely. But recognize that it really does take a lot of constant work. You have to be in that chair.

Brent’s workspace at The Omni Group using his favourite camera app, BitCam.

Indie Dev vs. Full-Time

You have a great history of your own successful projects as an indie developer, and also working within a team like The Omni Group. Which do you prefer and why?

OmniGraffle, one of the many apps made by the Omni Group.

They’re different, for sure, but in each case development is very social. It’s rare that great apps come fully-formed from the head of a solo developer.

I wasn’t sure if I’d like the more traditional environment of Omni. I take the bus to work, sit in my office, have lunch with the company (at 12:30 every day), and talk to and communicate with people throughout the day. It’s nice to be on a team. Everyone pulls their weight, and the company is full of smart and dedicated people. It turns out I *do* like it.

It’s also nice that when I’m not there, I’m not there. As an indie I worked at home and thus I was always at work. It’s good for the soul to have a dividing line.

Can you please describe the process of moving from prototype to shipped feature within The Omni Group, and how that compares to a similar process when you are an indie developer?

At Omni and at Q Branch the process is pretty similar: the designers figure out how a thing should work, then write it up and provide mock-ups — and then I ask questions, and that may or may not trigger further revisions — and then I go and build the feature. Which may then trigger further design and revisions, sometimes small and sometimes large. It’s iterative.

For my personal projects, I’m both designer and builder — and so I run a bunch of things (though not every single thing) by my beta testers. Sometimes I absolutely know what I want and I do it and there’s no need for early feedback. Other times I just need a sanity check. Other times I’m trying to pick from a few options. And then sometimes I really just have no clue how feature X should work.

And, of course, my beta testers — who are so much more than beta testers, since they’re in on everything from way before the beta — often have ideas I hadn’t thought of. They’re absolutely critical to building great apps.

Swift

What do you think of Swift? Are you using it in your projects? If so, what benefits or challenges have you found using it?

Brent is using Swift at Omni and on personal projects

I love Swift, and — both at Omni and on my personal projects — I write new code in Swift. And sometimes port old code over to Swift.

I think, however, it’s important to think critically about our tools, and not just love shiny new things for their shininess.

Example: I’m a protocol-oriented-programming partisan since before Swift. Objective-C and Cocoa are very much about delegates, protocols, and composition-over-inheritance, and that’s where I learned it.

And yet, one of the most natural uses for protocols is to make it so you can have a collection of heterogenous items that all implement the same interface. Think of an email client. You might have an Account protocol, and different classes for IMAP, POP, Gmail, etc. that conform to that protocol.

Somewhere in your data model you’ll have a collection of these Accounts. I tend to use sets, because I want to ensure uniqueness and because any sorting should be done at or near the UI level. Can you have, in Swift, a Set, where Account is a protocol? No, because you can’t make a protocol Hashable.

There are workarounds, for sure, but that doesn’t change the fact that a thing that ought to be natural and simple isn’t.

But it’s early days. The language is still evolving. And the things that bug me – this particular problem and others — are likely to get fixed in the future.

The project we’re all on as a community now is not just about evolving the language but also experimenting and trying new things in the process of defining idiomatic Swift. This takes longer than language evolution, by necessity, but it’s absolutely critical to Swift’s future, so that collaboration (on a team, on an open source project) works well.

In other words, we’re all working on defining what is insane gibberish Swift and what’s normal. That process involves writing a lot of insane gibberish Swift! But that’s not bad, really. That’s just how the process works. And it’s fun.