Monthly Archives: June 2011

Direct download as a bargaining chip

In the closing paragraph of “my Mac App Store follow-up post”:, I suggested that eventually most developers will exclusively distribute through the App Store. John Brayton, the developer of “CloudPull”: for Google Docs backup, “called this out on Twitter”:

“Good post, but disagree that selling outside the MAS won’t be worthwhile. IMHO we should be using our own stores as bargaining chip.”

“In a thread to the MacSB mailing list”:, John has a related version of this reasoning:

“Selling independently provides protection against Mac App Store policy decisions that could affect my app. If Apple decides tomorrow to kick me out of the Mac App Store, I would take a hit but I would still be able to sell my app.”

I couldn’t agree more, to both points. There may be some advantages to going App Store-only — less initial setup for checkout and licensing, no confusion about which version to buy, or where to upgrade — but indie Mac developers should be doing everything they can to control their own destiny. Having your own store is just good business sense.

Focusing on the wrong things

“Great post from Garrett Dimon”:, on his biggest mistake building the bug-tracker Sifter:

“I got bogged down watching our bottom-line even though we’ve always been comfortably profitable. I worried about preventing fraud even though the only instance we ever encountered only cost us $200. I constantly worried that Sifter could go down at any moment even though we’ve had 99.96% uptime since launch. […] All of these little things were distracting me from the work that really mattered.”

For a small company, focusing on the wrong things will make or break a product. I’m guilty of the same thing. I sat on “Tweetmarks”: for 6 months without launching it because I was worried about how to pay for hosting and how to get developers involved.

Sometimes there’s no obvious solution until you ship. Eventually it becomes easier to know when to be patient — to solve a problem right the first time — and when it’s needless worrying over something that may or may not even happen. And as 37signals says: “decisions are temporary”: anyway.

Mac App Store follow-up

I’ve been sitting on this post for a while. First the good news: “Clipstart”: is in the Mac App Store. Overall I was very happy with the response and glad to have a new way for customers to find the app.

I’ve received a bunch of good feedback on “my blog post about Apple’s 30% cut”: A few people are really upset with Apple, and there are posts in the dev forums about Mac apps that still weren’t approved for one reason or another weeks after the store launched. Other developers keep quiet, either for fear of rocking the boat or because they are happy with their sales and don’t see a significant problem.

And then there’s most of us who know Apple can do even better. We’re frustrated when an app (not just our own) is rejected or stuck in review indefinitely, but we just accept that things are a little dysfunctional and cross our fingers that maybe Apple will magically become more transparent.

But it’s not going to happen by itself. It’s not going to happen because the culture of Apple under Steve Jobs is secrecy. Apple is about great products, sure, but they’re so obsessed with the big reveal that it weakens their communication with developers.

From a “MacSB mailing list post about WWDC”: by Dave Howell, written back in February:

“Second, Apple employees are no longer allowed to talk about anything. In the past, half of the value of WWDC was talking directly to the folks who wrote the OS frameworks you have questions about. But now the answer to any question is always either ‘file a bug’ or ‘send an email to’ They’re all under a gag order.”

The baffling part is that many of the problems in the App Store process are easily solvable. The iTunes Connect team could, for example, make it a priority to answer all email. I don’t know what the organizational structure is over there, and I’m sympathetic to what must be a flood of app submissions, but it doesn’t feel like App Store support gets the same quality treatment that Developer Technical Support does.

Contrast with “Gus Mueller’s point on Twitter”:

“I’m with you on the 30% + silence issue. With PayPal, they’ll call me back when I email them with problems or questions.”

“Michael Tsai echoes this”: on his blog:

“The main value of Apple’s 30% cut is access to a larger market, but it still doesn’t look good that companies such as PayPal, eSellerate, and E-junkie charge much less and provide great service. I can e-mail or call those companies and get answers right away.”

Good support takes extra resources and it costs money. Luckily Apple has both, and that’s why drawing attention to Apple’s 30% cut was key to my original argument. Developers are playing by Apple’s rules and helping to fund the App Store.

Despite all this, I’m upbeat. In 2011 I want to look for ways that I can help Apple succeed, such as filing bugs. For years I swore off bothering, because it took so long to turn around a fix, if ever, and I had long since worked around a bug and moved on. iOS changes that delay because it improves so significantly every single year.

I’m all for “praising Apple when it’s deserved”:, but history shows that Apple improves the App Store when people complain. My posts are negative when it’s warranted and worth paying attention to.

The App Store is getting better. (I love that the Resolution Center is there even if I hope to never need to use it.) The writing is on the wall that a year from now most apps will be distributed through the Mac App Store, and the savings and independence of direct download sales won’t be worth the maintenance of two separate forms of distribution for many developers. But if Apple holds all the cards in this relationship, then we must hold Apple to a very high standard.


Don Draper, from the “season 1 finale of Mad Men”: (YouTube, skip if you plan to watch the whole series):

Don Draper

“This device isn’t a spaceship; it’s a time machine. It goes backwards, forwards. It takes us to a place where we ache to go again. It’s not called the wheel; it’s called the carousel. It lets us travel the way a child travels — around and around, and back home again, to a place where we know we were loved.”

When I first saw this a couple years ago I thought of Steve Jobs, the master pitchman in our industry. The delivery is different, more personal here, but it was stunning as part of the full episode. Who doesn’t want to build products that resonate so well, that go from nice utilities or productivity apps to something our customers fall in love with?

First you build a product that changes things, that is truly useful. Something ambitious. Then find a way to sell it that connects, and underscore why it matters.

I don’t really know how to do this yet. But I do know that part of it is telling stories. Why did I create “Tweet Library”: To tell stories, to remember events that matter before they’re lost in the fleeting stream of old tweets. It’s the kind of nostalgia at the heart of the Mad Men clip.

“I like this post from Kyle Neath of GitHub”:, that it’s about ideas, not products (via “Duncan Davidson”:

“People want to be part of ideas. Being part of a company who builds a successful product is cool… but being part of an idea is a lot more attractive. If you can build a business where both your employees and your customers think they’re part of an idea, you’ve created something special.”

If you can extract the core idea from a great product, everything that comes next can be matched to the idea, so the product has a clear path for new features. Building a story around it — something that sticks, and having the resources to tell that story properly — takes a lot of work. I’m inspired when I see others do it well, and it’s an art I hope to make time for.

WWDC 2011 keynote: diversify

This year’s WWDC keynote was one of the most significant of the last few years. Twitter integration and iCloud were the highlights for me, although at the end of the week I’m still not sure when or how I’ll be able to use either. But I love that it was a software-only event — that’s how WWDC should be — and I love that there were major new features on both of Apple’s platforms.

A few of the announcements seemed to have significant overlap (if not direct competition) with third-party developers, in particular Instapaper, Camera+, and the dozens of to-do list apps in the store. You can see some of that live reaction in a “collection of tweets”: I put together at the conference.

My first thought for Marco Arment was that he should come out with a new product. Not because I’m worried about Instapaper, but just because I’d love to see what he’d build next. “Marco is still upbeat on Instapaper’s chances”: for continued success:

“If Reading List gets widely adopted and millions of people start saving pages for later reading, a portion of those people will be interested in upgrading to a dedicated, deluxe app and service to serve their needs better. And they’ll quickly find Instapaper in the App Store.”

Yet here’s Dave Winer, “reflecting on when Apple competed with his product”:

“I think the answer is to find meaning in your work independent of what happens with the fickleness of the platform vendor and its developers. I went on to take the same software that Apple crushed and turned it into blogging, RSS, podcasting, web APIs, all kinds of cool stuff. And yes it did eventually make me a bunch of money. But not the way everyone thought it would.”

As Dave used to say, zig where they zag. Find the unique value in the apps you build and spin those out as separate products or use as inspiration for new features. Daniel and I have talked about this on Core Intuition: pull your app’s strength into a competition advantage by reusing code and adding more depth than anyone starting from scratch.

By playing to your strengths, you can do more, faster. Every indie Mac and iOS developer should be thinking about a suite of products.

“Justin Williams hits this”: in the context of WWDC:

“Some people grow frustrated by Apple continually making inroads in existing developer’s territory, but it comes with being a part of the platform. The key is to ensure your product lineup is diverse enough that you can survive taking the blow Apple may offer at the next keynote.”

You should make the choice to diversify before you’re forced to make it, because WWDC is already a full year of choices rolled up into one week. Dropbox/Simplenote and iCloud, OAuth and Twitter.framework, iOS 4 and 5, Retain/Release and ARC. Like the “Persians deliberating while both drunk and sober”: (“via Buzz Andersen”:, if you make any real decisions during WWDC’s info intoxication, make them again a week later.

Marco has a clear advantage over his new competition, though, regardless of whether he creates new products or sticks with Instapaper. “Send to Instapaper” is built into every great Twitter app and newsreader. It took years to build such widespread integration, and it won’t be easy (even for Apple) to be on equal footing with such a well-loved and established brand.

FAQ for Tweet Marker

I mentioned in “my first post about Tweet Marker”: that there were some decisions still to be made about the service. I don’t know everything yet, but I do want to answer some common questions I’m hearing from users and developers.

Will Tweet Marker be free?

Yes, I do not plan to charge users directly to use the service. There will also be no charge to developers for the basic sync API. However, it will take on real hosting costs, so I plan to have a more advanced paid plan (with more features and stats) so that participating Twitter apps can help pay for the service.

How useful is it if the official Twitter app doesn’t support it?

It is still very useful for users of third-party Twitter clients. I couldn’t allow the official Twitter app to use the API even if they wanted to, because theirs is a free app and has such a huge number of users. I also like that Tweet Marker becomes a selling point and discovery tool for other apps.

Shouldn’t Twitter provide this service as part of their API?

That would be great, but Twitter doesn’t seem interested in providing such a service. They don’t encourage users to read everything in their timeline, and it would be a little at odds with their focus on only the latest tweets.

Why aren’t you using Apple’s new iCloud?

The primary goal with Tweet Marker is to enable different Twitter apps to work together. iCloud is designed for storage and syncing only between apps from the same developer, so it’s not appropriate as a replacement architecture for Tweet Marker.

Where is it hosted and what language was it written in?

It is hosted on Heroku, which also powers the web site for my iPad app Tweet Library. Tweet Marker is written in Ruby with the Sinatra framework, and backed by PostgreSQL.

What about sample code for building this into an app?

I’m working on an example project for Mac and iOS. In the meantime, remember that it uses OAuth Echo, which is what most Twitter apps should already be using to post to Twitpic and Yfrog. Just change the URL to use the Tweet Marker server and include the tweet status ID in the POST body. To retrieve the value, it’s just a GET request without authentication. “See the docs”: for more.

Update: I reworded the part above about whether the service will be free, since I don’t control how third-party clients will make this feature available to their users. I also updated it to reflect the service name change from Tweetmarks to Tweet Marker.

Tweet Marker

So you want to sync the last-read tweet with all your different Twitter apps on iPhone, iPad, and Mac? Yeah, me too. While I hope to build a version of Tweet Library for other platforms, what I’d also love is to be able to switch between clients and know that each one will pick up where I was last reading in the timeline.

That’s why I’m introducing a new service for Twitter developers: “Tweet Marker”:

I’ve already showed it off to a few developers, and if you’re writing a Twitter app I’d love for you to support it too. It will be baked into the next version of Tweet Library.

There are still some unknowns (especially around whether I will need to ask for help to cover hosting costs), but I wanted to launch it now before WWDC so that other Twitter app developers meeting at the conference can give me feedback on the service. Tweet Marker has actually been running for months, and when an opportunity came along this week for a new logo (“thanks Alex!”:, I knew it was past time to finish documenting the service and get it out.

To be successful it needs at least 2 apps to support it (I’ll supply one of those). I’ve tried to solve all the other basic problems. It’s simple, fast, scalable on Heroku, and protected so that mischief-makers can’t tamper with tweet IDs.

Send me an email or find me in person next week if you have any feedback.

Update: This post has been updated to reflect the service name change from Tweetmarks to Tweet Marker.