Monthly Archives: April 2012

Clipstart 1.4.2

I released a small bug fix update to Clipstart today, version 1.4.2, to fix an issue with YouTube uploads when using your Gmail address sign-in instead of the YouTube account username. This version should also show up in the Mac App Store after it goes through Apple’s approval process. You can see the full release notes for recent bug fixes here.

As I said earlier this year, there will only be a couple more releases of Clipstart in the Mac App Store. My current plan is to switch completely over to direct-only sales with version 1.5. The new versions run without prompting for registration if you’ve already purchased and run a copy from the Mac App Store.

Picking the right brand

You may not notice it right away, but Tweet Marker Plus is the start of a big migration for my Twitter projects. The backend infrastructure for will be moving there, so that Tweet Marker can have access to published collections. And a major web feature to complement Tweet Library — originally written for last year but never released — will be launching on Tweet Marker Plus instead.

Essentially, Tweet Marker will be the web app and web services. Tweet Library will be the native iOS client only.

This has a few pretty big advantages for me:

  • One web app to manage instead of two.

  • Other Twitter apps can access the collections publishing API.

  • Tweet Marker is a better brand than Tweet Library.

More people know about Tweet Marker. It just makes sense to build any new web features on top of that existing name.

The first step in this transition is ready now: published collections can be accessed via For example, see this collection of tweets from the game Millinaut by Shaun Inman, Neven Mrgan, and Alex Ogle.

VoodooPad 5

VoodooPad 5 is out this weekend, with a new file format that plays nicely with Dropbox. Gus Mueller says:

“No more connecting to WebDAV servers and having to deal with authentication issues and strange HTTP errors. Now you can just put your VoodooPad 5 document in a Dropbox folder and VP will detect when pages have been updated.”

This is another good example of where web APIs like Dropbox can be more useful than iCloud. Multiple people can collaborate on a VoodooPad document, and the direct download and Mac App Store copies of VoodooPad can sync together.

Also new in version 5 is native support for Markdown and an ePub export option. The workflow for help documentation that I posted 5 years ago carries over to VoodooPad 5 just fine, too.

Indexing the hidden web

There has been some good commentary on Sergey Brin’s interview with the Guardian. It’s probably best summarized in John Gruber’s comment:

“The assumption here is that the only way to search is through Google, and that the ‘open Internet’ is only what Google can index and sell ads against.”

This resonates with me because I think Google has put enough ads on the internet. It’s impossible to take anything Google says at face value if they talk of “open” but their intentions say “ads”. But here’s the thing: Brin is actually right. There is great data hidden behind apps that should be indexable.

In the race to win the App Store, we forgot about the web. Think about Instagram. Millions of photos are being shared that are inaccessible via a search engine. These photos can’t be found again and aren’t discoverable. When you search the web, how does it make sense that public photos on Flickr show up, but public photos on Instagram do not?

We shouldn’t have to choose between Apple’s closed systems and Google’s ad-driven business. I want to talk about improving the web without automatically being pro-Google. This tweet from John Marstall made me realize it:

“I’d prefer to separate ‘indexable’ from ‘indexable by Google.’ Yes, they’re mostly the same for now. Might not always be.”.

We need competition in web search. More than Bing. A new search engine is the number 1 item from [Paul Graham’s frighteningly ambitious ideas](

“The best ideas are just on the right side of impossible. I don’t know if this one is possible, but there are signs it might be. Making a new search engine means competing with Google, and recently I’ve noticed some cracks in their fortress.”

Of course it’s crazy, but so was the 1st search breakthrough, lightning-fast AltaVista, and so was the 2nd major innovation, Google itself. It’s time for a search engine that isn’t all about ads. It’s time for search that understands apps and embraces data from web services as much as it does from web sites. It’s time for the 3rd act in search.

iCloud vs. the web

“This MacStories article”: covers the progress that developers have made adopting iCloud over the last 6 months. Over the next 6 months, we should have an even better appreciation for what iCloud is and isn’t good for.

For iOS backups and iTunes Match, iCloud is fantastic. For private, app-specific data that doesn’t make any sense away from a single developer’s native Mac and iOS apps, it’s also excellent. There’s no question that using Macs, iPhones, and iPads today is a significantly better experience thanks to iCloud.

But there are two fundamental limitations in iCloud that make it inappropriate for a bunch of syncing uses:

  • No way to access it from other platforms or web apps.

  • No way to share data between apps from different developers.

I don’t expect Apple to change this. Again, for what iCloud was made for, these limitations are fine. It simply means that iCloud cannot replace web APIs that do solve these two problems.

“Here’s what I wrote”: not long after announcing the Tweet Marker API:

“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.”

Think back to the so-called Web 2.0, which gave us web services to access previously closed-off data. This eventually led to truly dominant syncing APIs like Dropbox, Simplenote, and Instapaper. At the same time, we all have more devices than ever before. Syncing exploded on iOS in text editors and note taking apps. Without a proper shared file system between apps, or even an event or scripting system, these iOS apps looked to web APIs as the only way to communicate.

That has turned out wonderfully. With web APIs as the only solution, we see more compatibility between apps and more web services popping up all the time. If you create a new web app, it’s dead without an API. Every success of the modern web, from Flickr to Twitter, has an API that is available from any platform.

So then what about iCloud? If Web 2.0 made data more accessible, iCloud takes that same data and… keeps it closed. It’s a step forward on user convenience and a step back on interoperability.

If you’re a developer considering iCloud support, just make sure your data fits there. Ask yourself if your data is all about your app, or if it’s bigger than your app. Developers who are willing to take a risk on building an open API instead of iCloud could see new opportunities: web-based views of their data, compatibility with other apps, and syncing on the Mac outside of the App Store.

A couple years ago, “Shawn Blanc said about cloud syncing”:

“And my next wish? A cloud-based service like Instapaper, but for to-do items. I want it to be available in apps like Tweetie, Reeder, and more, so when I click on ‘Do Later’ it sends the link or item of note into a running to-do list (that syncs with Things, of course).”

Imagine if Things or OmniFocus or another tasks app opened up a slice of their private syncing API to make the Instapaper of to-do inboxes. Now take other APIs for all of the useful apps we use. Not just to-do apps as Shawn mentions, but RSS, photos, blog drafts, sketches, and more.

What I wrote above about Tweet Marker is still very much true. Since then, Tweet Marker has become the standard for last-read syncing between Twitter apps, with support for 15 apps and many more in development. I want to see more syncing platforms like this. Let’s think big and make apps work together.

Saved tweet filters

When I created “Tweet Marker Plus”:, I thought I was creating a new way to search Twitter. Limit the search to just people you follow and you can store more tweets, and more relevant ones. But as I’ve been adding new features to it, I’m realizing that Tweet Marker Plus is really a new kind of Twitter client — a client that has search and filters at its core.

Here’s what the sidebar looks like in my Tweet Marker Plus account:

saved filters

Seems simple enough. But quickly switching between saved filters is very powerful. Because Tweet Marker is routinely fetching new tweets in the background, even when you haven’t opened your web browser in days or weeks, there are no gaps in the timeline. When I use a filter, it’s showing me everything that any of the people I follow have said since I first started using Tweet Marker Plus.

I’m excited about this. I’ll keep adding features and growing the storage, to make Tweet Marker Plus the best value $2/month could possibly get you.

Instagram and hosting

I love reading about how big sites use Amazon EC2. If “this post from Instagram”: is still accurate, they must be at something like $50k/month in hosting costs. Their user base has doubled in the 4 months since they posted that.

My setup for Tweet Marker is trivial by comparison, but to me — without Instagram’s $7 million in funding — it’s a very big deal. What I wrote “back in October”: about moving to Redis is still mostly true, although I’ve added MySQL and Sphinx to the mix. I now run with 3 Amazon EC2 “medium” instances and have 5 web dynos (with 3 Unicorn processes each) at Heroku.

I put everything from donations back into the servers. For Tweet Marker to work, it had to be rock solid. It had to scale. It’s only the first week for “Tweet Marker Plus”: subscriptions, but already I have a good feeling that it’ll all pay off.

Tweet Marker Plus and API v2

Tweet Marker is going really well. It’s growing fast, users love it, and it has wide support in all of my favorite Twitter apps.

Today I’m announcing the next step for the service: Tweet Marker Plus. This is a paid subscription with additional features, such as a brand new search and a web-based timeline that syncs with Tweet Marker. Along with Plus, I’m rolling out version 2 of the API.

We’ve learned a lot over the last few months. Here are some of the things that I wanted to improve for the next version of Tweet Marker, both for the API and the business.

  • Consistent behavior across clients. It was fine at first for everyone to experiment with their own way to use the API, but now it’s time to come up with some best practices to guide developers.

  • More frequent sync. Mac and iPad clients in particular — where the app may stay in the front for some time — need to be hitting the server at regular intervals to catch changes from other devices. I believe this is the most common source of problems.

  • JSON-based API. The “v2” API should use JSON and carry more metadata, such as timestamps for the tweets and when it synced.

  • Profitable hosting. Although I’ve accepted donations since nearly the beginning, hosting costs are way up. I didn’t originally intend to turn this into its own business, but that is the clear way forward. It needs to bring in consistent revenue to cover hosting now and into the future.

With paid subscriptions, I can tackle the above bullets and also add more features. The first new feature to launch as part of Plus is a new search. Tweet Marker Plus indexes tweets from your friends so that you can find tweets later. It’s the solution to use when you don’t want to search all of Twitter, but you also want a large collection of tweets, not just the most recent ones that many clients store and filter.

Tweet Marker Plus is $2/month. You can sign up today at “”: Also check out “the screencast”:

The API documentation has moved to Github and is “also available now”: