Tag Archives: twitterrific

Twitterrific Phoenix on Kickstarter

I use Twitter much differently than most people. I haven’t returned to my @manton account in over 4 years, and instead I cross-post all my blog posts to @manton2. I reply and like tweets when I get mentions, but I don’t actually follow anyone.

But despite this weird use of Twitter, I follow the company closely and still maintain the Tweet Marker timeline syncing API. So I’m excited to see Iconfactory launch a Kickstarter campaign to fund new work on Twitterrific for Mac.

I’ve backed the project. It’s a good opportunity to support one of the pioneers of Twitter development.

Navigation controllers on the Mac

Brent Simmons has a good post about the pros and cons of bringing UIKit to the Mac. On the differences between iOS and Mac development, though, one point did stand out for me:

And there are things Macs don’t have at all — navigation controllers, for instance, since they don’t make sense in a context where you can just show the hierarchy via multiple panes.

Brent’s right that most Mac apps don’t need navigation controllers. I don’t think I’d have any use for them in my Mac app, Clipstart, for example. But navigation controllers are becoming more common in Mac apps, starting with Twitter apps especially. I expect an important part of Iconfactory’s work on the Chameleon framework to bring Twitterrific to the Mac was supporting navigation controllers.

I’ll always consider myself a Mac developer first, even though most of what I do these days is on iOS and for the web. I’d definitely welcome UIKit for Mac. I’m getting closer to announcing a new iPhone app and web platform, and while I have a Mac version in development too, I can’t justify the time right now to finish it. UIKit for Mac would make that decision much easier.

Tweetbot + Twitterrific

The second app to support “Tweet Marker”:http://tweetmarker.net/ has arrived, and it’s a great one: “Tweetbot”:http://tapbots.com/software/tweetbot/. I love using Tweetbot on the iPhone and Twitterrific on the Mac and iPad. Seeing these apps work together just makes for a better Twitter experience.

Here are a few tips to keep in mind while using apps that support Tweet Marker:

Turn it on! First things first: enable Tweet Marker in both apps on every device you plan to use Twitter on. MacStories has a good summary of this (with screenshots) for “their coverage of Twitterrific”:http://www.macstories.net/mac/twitterrific-4-3-syncs-timeline-position-with-tweet-marker/ and “again for Tweetbot”:http://www.macstories.net/news/tweetbot-1-6-gets-tweet-marker-timeline-sync/.

What syncs? Only the main timeline and mentions sync between the apps. While working with these developers, we made a decision to change how Twitter lists sync after Twitterrific had already shipped. So while both apps think they are syncing lists, the format on the server is not compatible between the two. A future version should fix this.

How to switch apps? Most apps take the approach of saving the last-read position when the app is quit or sent to the background, and restoring it again when it is launched or brought to the front. You may need to change your default habits a little to get the most accurate behavior. When you know you are going to switch apps, just close your active Twitter client first before opening the next one. It may also help to wait for the app to download new tweets before scrolling or interacting with it.

Hosting for Tweet Marker

Today was day 7 of the “first app”:http://twitterrific.com/ to ship with Tweet Marker support. Overall, things have been working great. I thought I’d write a little bit about my hosting experience so far.

First, the good news: the service is up and fast. Twitterrific is sending a lot of traffic, even with the preference off by default, but the server app is architected in such a way that things are zipping along nicely. Performance is especially important on the iPhone, where a Twitter client might be saving state on quit and any lag would be pretty obvious. Non-trivial server work, such as hitting the Twitter API, is done in the background using Resque, and the queue size there is usually small too.

There have been two distinct problems, though. Each was a good opportunity to improve the system.

On the first day, the background queue stalled and the requests piled up, so much so that my Redis instance ran out of memory and clients started receiving errors. I upgraded Redis, restarted the app, and bumped up the number of processes to quickly catch up on the backlog. Although it hasn’t resulted in errors since, it has delayed some requests on 2 more occasions after launch. I also adjusted how I’m collecting statistics to further improve performance.

More recently, I’ve noticed some sporadic SSL errors when Tweet Marker tries to verify the user account via Twitter. I added more wait-and-retry logic, and I’m keeping an eye on this to kick the background script if necessary. There have been no errors in the last couple days.

I still think it was the right decision to host on Heroku. Although I am manually monitoring the server for general health (need to automate this badly), everything is less work than I would do with a colocated box or VPS. The biggest cost is that at the last minute I upgraded to Heroku’s dedicated PostgreSQL database. I’m still evaluating that, but I would rather launch with too much horsepower and scale it down later, than not enough.

Again, thanks for your support. It is a little nerve-racking because I know that “other people”:http://www.iconfactory.com/ are depending on Tweet Marker being up and performing well. This is a different experience for me than working at a “larger company”:http://www.vitalsource.com/ with a dedicated system administrator, and also different than server backends for my Riverfold products, where it is only my own customers who will be disappointed if I fail.