Why I Love Indies and You Do Too

As much as I love Macworld, I have to say that the one indispensable website in our community is Daring Fireball — an indie website.

As cool as Twitter is, its early success in our community was due entirely to Twitterrific. And it took The Iconfactory to come up with the word “tweet” and the bird logo for Twitter.

It took Loren Brichter to invent pull-to-refresh in Tweetie.

It took Marco Arment to invent the entire read-later category with Instapaper.

And me, I shipped the first Cocoa RSS reader at a time when Mac users mostly hadn’t heard of RSS. (And while corporations have dabbled with RSS, it’s pretty much back to its roots now as an indie technology.)

* * *

I can’t find it now, but I was asked on Twitter a couple days ago why I placed such emphasis on indies. Isn’t the point that we want high-quality software, and it doesn’t matter if it comes from indies or corporations?

I’ve noticed something obvious about popular music — it’s almost never instrumental. There’s always a human voice singing a melody. We humans love human voices.

That’s what we get from indies that we don’t get from corporations. We get that human voice and the emotional connection that goes with it.

* * *

But it’s not just that human voice, and the thrill it gives us to see a smart person or team doing great work. It’s also that indies make software that no corporation would ever make.

Think of MarsEdit, a desktop blog editor that works with a variety of blog systems. While WordPress writes an app that works with WordPress, it takes an indie to write the app to connect to everything.

Or think of Pixelmator and (my favorite) Acorn. What corporation would go up against Photoshop? It takes indies.

A great example is Capo. I can’t imagine a corporation building this — and, if they did (with a team of six, probably), they wouldn’t be one-tenth as hardcore as one Chris Liscio.

Inventiveness, passion, and courage comes from indies, not from people who watch the bottom line.

* * *

But indies do have to watch the bottom line — at least enough to be able to survive as an indie so they can keep making software.

And I think we’re already missing out on great software that would have existed in a better context.

So it’s worth thinking about a few things. One is how things could be better for indies — Marco, for instance, suggests that the App Store should get rid of the top lists.

Another is that you, as an indie or potential indie, should know what you’re signing up for, and you should have enough information to make smart decisions that will allow you to keep doing what you love.

The advice I’ve seen boils down to a few things:

  • Start with small apps. Do a few of them.

  • Strongly consider doing Mac apps too. (You can charge sustainable prices for Mac apps.)

  • Start your business as a side business until it’s making enough money to support you.

  • Do contracting as needed to make up the income gap.

  • Don’t skimp on marketing. It’s important.

  • Persevere.

But know that you’re still going to fail, most likely.

I would love for you to prove me wrong. Write something that blows my mind and that makes you successful.

Ignore the doom and gloom. Make me eat my words. Please!

Jake on CloudKit and Groups

Jake Savin: Square Pegs and Round Holes:

It’s possible separately via a web portal (not programmatically as far as I know), to configure a subset of data to be editable only by specific people, but the idea is more about providing a way for the maintainers of some data resources to update that data, than it is about providing a mechanism for users to create ad-hoc groups among themselves. (i.e. dynamic configuration data that’s loaded by the app at launch.)

While this is a super useful feature, the value of which hasn’t really been called out much by the iOS dev community, it is not what Marco Tabini described. (I can see how the misunderstanding arose though.)

Just Is a Four-Letter Word

A List Apart: The Most Dangerous Word In Software Development:

“Just” implies that all of the thinking behind a feature or system has been done. Even worse, it implies that all of the decisions that will have to be made in the course of development have already been discovered — and that’s never the case.

Mark on Mobile Software

Mark Bernstein: The Mobile Software Disaster:

It’s clear that mobile apps have the ability to make people smile, to make people think, to make people get more stuff done., to let people do things they couldn’t do without them. Making software is productive: it creates value for lots of people. We need to be able to capture some of that value, or people will stop making software.

CocoaConf Seattle Early Bird Pricing

CocoaConf Seattle early bird pricing ends August 1 at midnight.

You should register. Check out the list of speakers — me, Gus, Laura, Izzy, Paul, Mattt, Janine, Daniel, and more.

Nick B on Leaving Indie Life

Nick Bradbury:

In what feels like a different life now, I used to be a fairly well-known indie developer. I spoke at events like SXSW, and my blog had a large audience of people who liked hearing about my work on HomeSite, TopStyle and FeedDemon.

Nick was the single greatest indie Windows developer. So good that I once called him an honorary Mac developer. (Well, I was being complimentary and a jerk at the same time.)

I should point out that I ripped off some of his ideas from FeedDemon entirely without shame — and with Nick cheering me on.

A lot of mobile developers have left the indie ship and done as I have and joined a larger company, many of which look at mobile apps as a free (or nearly free) complement to their other offerings. There’s plenty of opportunity here for mobile developers, and I think that opportunity will continue to grow for a while.

He’s right. (Nick works at Automattic, by the way, which is a great company.)

Nevertheless, I still believe with all my heart (more than my brains) that there’s plenty of room for indie mobile developers. It’s just that the most straightforward path — write one great app and get rewarded — isn’t necessarily the smartest.

On Pricing More

Robert McGinley Myers suggests raising prices:

But when I look at that sales chart for Unread, and see that huge spike in the first few days, I see myself and other people like me, people who love these beautifully designed, “hand-crafted” apps.

We aren’t buying these apps on impulse. We’re buying them because we read the reviews and we know what the best apps are, and we want to own the best. Maybe indie devs need to stop chasing the normals (who think everything should be free anyway) and just charge a fair price from the folks who care.

I think what would happen is that launch week would be even better — but every week after that would be much worse, in terms of both units and revenue.

Would you have bought Unread at $19.99? Or even $14.99 or $9.99? I don’t know if I would have.

Faruk on Indies

The iOS Indie That Could:

First, let’s look at the skills involved in creating and publishing a great app like Unread. You need a good understanding of interaction design, UI design, (most likely also) icon design, and having great taste and the ability to know when to say “No” to things are a boon to its positive reception by critics and users alike. Then, you need to do the programming of the application, which generally requires at least a decent understanding of database architectures, MVC principles, the main programming language and its frameworks, and generally good programming discipline. Next, you need content strategy skills: all the labels and text in your UI send messages to the user, and if they’re poorly written or unintuitive, this will cost you in significant, but difficult to measure, ways. The same applies to the marketing of your app: the website promoting it, the language used in your AppStore listing, the quotes you provide in interviews, and so on. Good selling skills overlap with this, but if you’re simply publishing it on the AppStore and not making direct sales to, say, enterprises or businesses, you probably don’t need the equivalent of a sales agent. Then, from your business end, you need all the various business management skills as well as the project management chops to keep yourself on track, issue yourself realistic deadlines, and so forth.


Marco, in App Rot:

Apple’s App Store design is a big part of the problem. The dominance and prominence of “top lists” stratifies the top 0.02% so far above everyone else that the entire ecosystem is encouraged to design for a theoretical top-list placement that, by definition, won’t happen to 99.98% of them…

The best thing Apple could do to increase the quality of apps is remove every top list from the App Store.

We’re not employees, so a union doesn’t make sense. But it’s still true that a group of some kind has more leverage than individual developers.

What I’d love to see is something formal where Apple listens to developer feedback about the App Store. It’s their App Store, but it’s also the only market place for iOS apps — and, because it’s the only game in town, fairness suggests that we’d have at least an advisory role (beyond kvetching on blogs and Twitter and Radar).

But how this should work is beyond me. (I grew up more on Robert Heinlein than on Ursula K. LeGuin.)

Shopster 2013

More numbers. About a year ago Pablo Bendersky wrote about his app Shopster:

I can’t say the first day sales were a disappointment, as I was not sure what to expect, since our previous apps did not have the coverage Shopster had. We were surprised to see the app had only sold about 200 units…

As you can see, in our first week averaging 100 sales a day, our app ranked consistently in the top 100 productivity apps…

Shopster got reviewed by Gizmodo and finally, on April 11th, it was picked by Apple as New and Noteworthy. At the point we thought sales would skyrocket…

As you can see, things did not get better, and our app averaged 41 sales per day.

Say the app was priced at $1.99. If it had sustained the opening rate of 100 sales per day, this means $199 per day, which is $139.30 after Apple's cut.

Say it’s just one developer. That developer would make $50,844.50 in one year, at that rate.

If that one developer writes two or three apps that do as well, then that’s a pretty good living, for sure.

But the average was 41 per day, which means $81.59 per day, which is $57.11 after Apple’s cut. That turns into $20,845.15 per year.

Now you need to write five of these to have a good year. (More if it’s a team rather than a solo developer.) And you have to support those apps, and probably do another five next year because the bulk of sales happen at launch.

My city (Seattle) is in the process of raising its minimum wage to $15 an hour, which is about $30,000 for a full-time job. Many iOS indies would do better at minimum wage jobs here than on the App Store.

iOS Indie Game Numbers

Chad Etzel:

Even though I managed to bring in a paltry $498 for a year’s worth of side-project time, it gets even worse. I paid nearly $700 in Facebook and Twitter mobile ads to try and market them. I also bought an iPad Mini and an iPod Touch for development and testing, so I’m even deeper in the hole overall.

I was wondering if games were different than other types of apps — easier to make a profit, maybe? Or harder?

This is just one developer’s experience, but if it’s at all representative then games are probably harder.

Tyler on Mac Apps

Tyler Hall:

In 2007, I priced the app at $7. Over time I raised the price to $9, $12, $14, $19, $24, $29, $34, $39, and, now, $49. With each price increase my total sales and revenue have only gone up. And, as an extra bonus, the quality of my customers has increased as well. I never received as many angry emails from customers as I did when the app was priced cheaply.

(Via Jared Sinclair.)

Lots of Apps

Benjamin Mayo comments on Jared Sinclair writing about Unread’s revenue:

In my opinion, you make money on the App Store by selling small things — its very nature is a bitesize marketplace. This is how you maximise your effective hourly wage. This doesn’t mean you have to turn around crap. You can still output quality pieces of software.

I think he’s right that this is a workable strategy.

The obvious downside, though, is that you don’t get apps like Overcast, Unread, Tweetbot, and my own app Vesper (and plenty of others) if everyone sticks to this strategy.

We want those kinds of apps, not just the bite-sized apps.

More on iOS Indies

When I asked who all the iOS indies are, I got a bunch of good responses. By iOS indies, I meant:

• People making all (or almost all) of their money from iOS.

• And who are making that money from publishing their own apps, not via contracting or a paycheck.

There are plenty of people with both iOS and Mac apps, and plenty of indies who make much of their money from contracting. But I was curious about the pure iOS indies, since I thought it would tell me something about the ability of indies to make money on the iOS App Store.

(Games, by the way, are another country. I should be explicit about not thinking about games, since I don’t know anything about the market or what it takes to make an iOS game. It’s possible that game-writing is a wonderland of fun and money. I don’t know.)

There aren’t many pure iOS indies. I’m sure I’m missing some, but the names that kept coming up were David Barnard (Launch Center Pro), Jared Sinclair (Unread), David Smith (Feed Wrangler and others), Charles Perry (Action Lists and Benjamin), and Greg Pierce (Drafts and others).

(Congratulations to these folks! And to the others whose names I missed. You’re living the dream, and that’s cool.)

I think my point still stands — pure iOS indies are fairly rare. I can easily come up with a bigger list of pure Mac indies, even though iOS developers in general outnumber Mac developers.

If you want to write your own iOS apps, it appears that either you accept the likelihood of a pretty low income or you have a day job, write Mac apps, or do contracting (or some combination).

I think this is too bad. It seems like the iOS market is so huge that it should be able to support lots of iOS-only indies.

But with how prices have fallen — how people are now accustomed to not paying anything until they’re hopelessly addicted and need the $4.99 packet of imaginary things that will get them to the next level — I can’t recommend to anybody that they quit their job to just write their own iOS apps.

(Unless those apps are games. Maybe games are fine. I have no idea.)

There’s a downside to this beyond just the vague feeling that it’s a shame that iOS developers have to supplement their incomes — it’s that any rational developer aware of the economics will not be able to make as big an investment in iOS apps as they would if they could expect their effort would be rewarded.

Consumers win in terms of quantity of choices and low prices, but not in terms of quality.

[Sponsor] Creating static blogs made easy!

Statiked is a blog client for your static blog hosted on Github and S3.

The online world has seen a new revolution lately: static blogs. However, as the current tools that are available to host and manage a static blog stand, it is only accessible to a minority of bloggers out there. Even seasoned programmers who use Github daily often find it difficult to write and publish a blog post. Statiked takes out all the pain points in publishing to a static blog.

Statiked allows you to compose your article in your favorite text editor. Currently it supports, TextMate, TextEdit, Sublime Text 2, and BBEdit. You write all your articles in plain text using Markdown. Statiked generates the corresponding HTML before publishing it to the host.

If you are like us and don’t want to leave the comforts of a blog editor which you are used to, Statiked provides an XML-RPC server built in. Point your favorite blog editor to the URL provided by Statiked, and blog as if you are publishing to any hosted blog.

There are three beautifully designed responsive themes packaged within Statiked. With a bit of hacking you can port your Jekyll or Wordpress theme to use with Statiked too. Porting a theme is easy as Statiked supports the famous Liquid template system.

Statiked is a useful tool for any blogger who wishes to host a static blog. There are no bash commands to remember. No scripts to deal with. You do everything through a simple and intuitive UI. Publishing to a static blog is as easy as writing an email. Use your time to focus on writing. Write Just Right!

You can get Statiked from our website. Follow us on Twitter at @statikedapp.

I Was Wrong — You Totally Can Use CloudKit for Identity

See Session 208, Introducing CloudKit.

Your app gets a stable but random user identifier that does not include any user information. Two different applications get different identifiers, but the same application run by the same user on different devices get the same identifier, as you’d expect.

From the session, at 40:36:

And lastly, this is an independent API. This is a section of the CloudKit framework. You can use this in collaboration with the database API, or you can use this completely separately. We’ve given you enough support that, if you wanted to, you could implement a login-via-iCloud flow in your application using the CloudKit framework.

Unread’s Numbers

Jared Sinclair writes about Unread sales.

(I bought Unread about a month ago, by the way. It’s a very good app, and I recommend it.)

Contrast Jared’s numbers with NetNewsWire’s numbers in 2004 and 2005 (the last time I paid attention to its sales) — NetNewsWire made 5 figures every month, month after month.

This was before the App Store. It was a Mac app in a small market. (Far smaller than iOS, and much smaller than the Mac market is now.)

Setting Expectations About CloudKit

Macworld: Why you should care about CloudKit:

The big difference is that the information stored in it can be made available to multiple users, allowing them to collaborate and share information through the cloud—something that iCloud “Classic” was unable to do…

Don't let the term “public” put you off, though—CloudKit doesn't force all the shared data in a big bucket that is automatically visible to everyone who installs a particular app. Instead, developers will be able to protect the information as they see fit, allowing, for example, users from a particular group or organization only to have access to specific content…

It’s not hard to see that CloudKit greatly simplifies the creation of apps that revolve around multi-user collaboration. Previously, creating a group chat app like Glassboard, or a team-based task management software like Wunderlist, would have required a significant amount of work.

I don’t see how this is true. While it’s technically possible to use the public data for group collaboration, it’s only the code in the client app that enforces this. CloudKit has no notion of groups.

It would be irresponsible to use the public data for private group collaboration.

Neither of the two apps mentioned as example — Glassboard and Wunderlist — should use CloudKit.

And, since CloudKit is iOS and Mac only, and those two apps exist on other platforms, they couldn’t use CloudKit even if it did have private group data.

CloudKit is cool, and I think lots of developers and users will benefit from it. But it’s important to set expectations properly, and not suggest that it’s useful in cases where it’s not.

(Hopefully that will change. I’d love for CloudKit to understand groups.)

Also, there’s this:

Finally, CloudKit allows third-pa>rty apps to piggyback their authentication mechanism on Apple ID, thus making it easy to tell each user apart in a unique way without having to write and maintain a login system—and without forcing users to remember yet another password.

I don’t see how that’s true, either. If CloudKit gives you a user-specific token that identifies a user, sending that token to your own server — without an additional authentication system — isn’t secure. An attacker could submit random tokens until they found somebody’s data.

Update a few minutes later:

Kyle Sluder asks on Twitter:

If authentication is user id + nonce, how is it not secure?

Good question. Perhaps this could be made to be secure.

So I’ll make another point: in the absence of Apple saying, “Yes, you can use it this way,” I wouldn’t. It feels like a misuse of the system, and something Apple would recommend against. Putting your app in that position is not a good idea, especially given that it’s the kind of practice Apple could choose to disallow.

If I’m wrong — if Apple is indeed offering just the authentication part of CloudKit as a service to developers — then I’d like to see where this is spelled-out.

Update 9:45 am:

Well, Tom Harrington tells me that Apple has indeed said you can use CloudKit authentication as a service.

It was specifically mentioned in one of the CloudKit WWDC sessions. Log in with iCloud instead of Facebook or whatever.

That’s really cool. I’ll go back to the session and double-check, of course, but I don’t doubt Tom. (He knows this stuff.)

Update 10:06 am:

See I Was Wrong — You Totally Can Use CloudKit for Identity.

Who at the Table is an Indie iOS Developer?

Until last night’s unofficial Xcoders I hadn’t thought to ask this question.

There are a ton of Mac and iOS developers in the Seattle area — and almost all the iOS developers are making money either via a paycheck (they have a job) or through contracting.

The only local indie iOS-only developer I could think of was me — and even that won’t be true for much longer, as we’re working on Vesper for Mac.

There probably are other local indie iOS-only developers, but I just can’t think of them at the moment. At any rate, they’re rare.

To be fair, there aren’t that many more indie Mac developers. There’s Gus with Acorn. John Chaffee and BusyCal. Chris and Napkin. Hal Mueller and SkunkTracker. The Vellum folks. But that’s a bigger list than indie iOS developers.

(Noted: not all of the Mac developers are making a living solely through their Mac apps. Gus and John are, but Chris, for instance, also does iOS contracting.)

I think I have two points.

One is that indie developers — people who make all or most of their money via products they create and sell — are fairly rare these days. Most of the local developers I know work at Omni, Black Pixel, or Apple or do contracting.

The second is that indie iOS developers are more rare than indie Mac developers. Though iOS developers outnumber Mac developers by a huge margin, they’re under-represented in the indie community.

This isn’t scientific or anything. I’m just observing the local community, and I could be missing important data.

But if I’m right that this is the general trend, then it means that people making a living as indie iOS developers just isn’t a thing these days. Some money for iOS development is coming from companies like Omni that do create products — but most of it appears to be coming from corporations that need apps (or think they do). Places like Starbucks and Target.

The dream of making a living as an indie iOS developer isn’t dead — see Overcast as a recent example — but, if I’m right, hardly anyone believes in it any more.

I’d love to be wrong.

Who are the indie iOS developers? Who, that is, is making iOS apps only and supporting themselves solely or largely via sales of their apps? (Anywhere, not just in Seattle.)

You could say Q Branch, but we’re working on a Mac app. Marco has a new app, so that’s one. You might say Loren Brichter, but it’s possible his money comes more from Facebook than Letterpress. (I just don’t know.) You might say Michael Simmons and Flexibits, but they have a Mac app.

Found another one: Tutu Lab. That makes two. Who else?

Prefixes Considered Passé

Me on Twitter:

Decided. No longer prefixing classes in app code, even with Objective-C. I can hear your screams and I don’t care.

Prefixing was always a poor solution to the lack of namespaces in Objective-C. There was no enforcement anywhere — and a prefix like RS could stand for Ranchero Software, Red Shed, Red Sweater, and Rogue Sheep. (Those are all real companies that used RS.)

A couple things have made me decide not to use prefixes in app code class names anymore.

First is that I’m spoiled by Swift. I didn’t think it would make much difference to me to be able to use naked class names — CreditsViewController instead of VSCreditsViewController, for example — but it does. It’s much nicer.

The second is that the Xcode 6 betas no longer ask for a prefix when starting a new project. And it creates AppDelegate and friends — not BSAppDelegate and friends.

If I had to guess, I’d say that Apple engineers are also spoiled by Swift’s no-prefixing, and somewhere in developer tools a decision was made not to push prefixes for app code any more.

This — no prefixes for app code classes — will become a recommendation, I’d bet.

There is a caveat, though. There could be non-prefixed class names in Apple’s frameworks. I haven’t personally verified these, but Spencer MacDonald says there’s a Message class and Saul Mora says there’s a BluetoothDevice class. There could be more.

Avoiding these conflicts is the point of prefixing. We can argue that it’s the responsibility of frameworks to use prefixes so that we app developers don’t have to watch out for these — but arguing doesn’t make it so.

Nevertheless, I’d bet these are rare enough that it’s the worth the potential hassle, and we can always file Radars if these come up.