How to Be Wrong on the Internet

Sometimes I hear from people who’d like to blog more — or at all — but they worry, they say, about “being wrong on the internet.”

Me, I do it all the time. I’m constantly wrong on the internet. Here’s how I think about it:

Blogging is, for me, part of the process of getting to the truth.

Everything is provisional — it’s what I think now, and I might change my mind in a year. Or in a day. Or in a minute, when somebody posts (or tweets) more or better information or has a solid argument.

And that’s the part I love. A recent example: while writing the Vesper sync diary I got a ton of great feedback that changed my mind on some things, and that feedback ended up making those articles better and it made the app better.

The fun part is documentating all this. It’s learning-out-loud.

But to do that means thinking a little bit differently than you may be used to. Instead of taking feedback as criticism or correction, take it to mean that the process is working. If you learn something or change your thinking, then that’s great. That’s the point.

The feedback may also not change your thinking, but you may understand your thinking better and end up being better at defending and articulating it. That’s great too.

This may take some courage at first. But soon you’ll find that it doesn’t hurt at all.

Me, I’d be happy if everything I post is wrong. Because then I get to learn.

Ben on Building Businesses

Ben Thompson:

What stands out to me about Love’s approach was that from day one his differentiation was not based on design, ease-of-use, or some other attribute we usually glorify in developers. Rather, he focused on decidedly less sexy things like licensing. Sure, licensing is particularly pertinent to a dictionary app, but the broader point is that Love’s sustainable differentiation was not about his own code. Sustainable differentiation never is.

Mark on Prosperity Gospel Business Reporting

Mark Bernstein:

Prosperity Gospel business reporting holds that, when a product succeeds, it succeeds because the CEO or the product manager is brilliant and wonderful, a romantic hero like Steve Jobs. When a product fails, its failure stems from the shortsightedness and shortcomings of the foolish and ill-behaved management. Just like Steve Jobs, back in the day, was the dirty hippy who nearly ruined Apple.

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.)