Twitter clients used to be a UI design playground. The growing popularity of Twitter, an open API, and the rapid takeoff of the App Store contributed to the creation of a defining genre of mobile software in 2009 and 2010: the Twitter client for iPhone. In the golden days of third-party Twitter apps, a good new client would come out at least every month, with several developers pitching their own ideas for what was meant to be a mobile-first communication network.
iPhone apps and the Twitter API were a perfect match five years ago. Twitter made sense as a social network in your pocket; Apple’s iPhone OS and newly launched App Store made that a reality. As a user, there was little friction in trying multiple Twitter clients: because Twitter data was always “in the cloud”, changing clients was like choosing a different outfit each day. The core Twitter experience would always be the same; the design and preferences around it would differ from client to client.
That was a time of astonishing innovation in mobile app design. Twitterrific, the first native Twitter client for iPhone, effectively invented key aspects of modern Twitter interaction and terminology; Tweetie, perhaps the most popular Twitter client of its time, pioneered touch interaction paradigms such as pull to refresh. And then there were Weet, Osfoora, Birdfeed, Twittelator, Echofon, Tweetings, TweetList, and dozens of other apps that helped refine and redefine the idea of what Twitter on an iPhone could be.
Good Twitter clients weren’t easy to create, but the challenge they packed was intriguing and flexible. As a Twitter developer, you needed to design an app that would primarily display textual information (this was before Twitter photos), handle hyperlinks, manage interactions between users, account for different network conditions, possibly integrate with third-party sharing services years before iOS 8, and, most of all, be fast, responsive, and easy to use. The constraints of Twitter clients in 2009/2010 freed many from the struggle of coming up with an original app idea.
If you’re using an iOS app[1] today, there’s a good chance some of its features or design ideas first appeared in a Twitter client five years ago.
We know how the story moved forward. In April 2010, Twitter realized that they needed an official iOS presence on the App Store, so they bought Loren Brichter’s Tweetie, relaunched it as Twitter for iPhone, and Brichter released the (unsurprisingly genius) Twitter for iPad.[2] For a while, it looked like Tweetie would live on, but then Twitter started adding questionable features to it, and it became clear that the third-party Twitter client would be persona non grata on the App Store.
Over the years, there have been countless examples of Twitter prioritizing their own app and a closed ecosystem approach over third-party developers and improvements to the API. From the infamous quadrant and token limits to the display guidelines and constant reticence about bringing new features to the API, Twitter has been nebulous in providing an official stance on third-party clients after the Tweetie acquisition, but the subtext of their announcements has always been fairly clear to everyone in the third-party scene. Twitter wanted people to use their official app, not a third-party client.
Before the Twitter acquisition in 2010, I was using a bunch of third-party clients but I had eventually elected Tweetie as my preferred one. After Brichter’s app turned into Twitter for iPhone, I stuck to it for a while, but then I was allured by Tapbots’ promise of a Twitter client for power users. As I wrote in my original review, Tweetbot had everything I was looking for, and that was before Tapbots would bring fantastic new features that made it even more versatile.
I loved Tweetbot in a way that I didn’t love any other app for iOS. I have extremely vivid and personal memories of getting the first beta builds of Tweetbot for iPhone and iPad, and, until Editorial came around, Tweetbot was the app I spent most of my days in. From 2011 until earlier this year, I used Tweetbot every working hour of every day. Tweetbot was Twitter for me.
That’s not to say that I stopped checking in on the state of other Twitter clients for iOS, but I certainly became less curious because I had found the one. I’ve primarily continued to keep an eye on Twitterrific, but I largely ignored the third-party space for two years. Last year, the launch of iOS 7 motivated me to look for new Twitter clients again and I stumbled across new versions of TweetLogix, Echofon, and Tweet7, but my affection for Tweetbot and the fact that the majority of my Internet friends were using Tapbots’ app convinced me that I didn’t have to look for anything else.
I like to think that I’m naturally curious, but, for my Twitter client of choice, I had become complacent and fixated on the belief that the official Twitter app could never offer anything valuable again. Earlier this year, an idea started poking me in the back of my mind: if the rest of the world is using the Twitter app for iOS, shouldn’t I give it another chance?
This realization came from a simple occasion: I was having dinner out with some friends, and I noticed that they were using the Twitter app for iPhone to read news and follow their favorite celebrities. Tweetbot was Twitter for me and I was certain that I could never switch to another app, but they seemed to be just fine with the official app and its lack of streaming, mute filters, quick actions, and all those other great details Tweetbot had. “They’re not power users”, I thought, and that settled it.
Still. For someone who likes to think he’s curious and writes about apps for a living, my unwillingness to at least try the app from the service I use every day was remarkable in its shortsightedness. Twitter had changed since 2011, and it wasn’t meant for power users. The rest of the world was using Twitter through the official apps and I thought that I knew better than anyone else. So, a fun experiment began:
I started using the official Twitter client as my main Twitter app on my iPhone and iPad.
For the past six months, I’ve been reevaluating my entire Twitter experience based on the apps I use to read tweets and interact with people. The idea made a lot more sense once I stepped out of my preconceptions: I wanted to understand what 2014 Twitter was like and if that meant sacrificing my nerd cred and use a Muggle’s Twitter app, so be it. But at the same time, I’ve gone back and forth between Twitter and third-party clients, primarily out of habit, but also because they still offer powerful features and design details that I appreciate.
I didn’t want to focus on the history of Twitter clients, my thoughts on Twitter’s policies, or every single Twitter app currently available for iOS 8. I also couldn’t compare every single feature or design decision for every possible scenario a Twitter client could be used in.
Instead, I attempted to address my curiosity from a utilitarian standpoint. Given the three most popular Twitter apps for iOS (Twitter, Tweetbot, and Twitterrific), I wanted to slowly evaluate their features for my use case. To do this, I assembled a list of features I need a Twitter client to be capable of handling and I started taking notes every time I switched between clients. I’ve been doing this since early June.
I’ve spent weeks comparing features and changing apps to understand the kind of experience they want to promote. But implementation details and design differences aside, I also kept wondering the same question: was the real Twitter different from the third-party clients I used for three years?
What’s 2014 Twitter like on iOS?
Table of Contents
Loading Timeline Gaps & Tweet Marker Sync
Web Views
Cards and Previewing Tweets
Extensions
Gestures
Profiles
Lists
Tweetstorms
Direct Messages
Uploading Photos
Discover
Muting
Fave and RT Counts
Search
Timeline
New Twitter
Notes
Update #1: Clarified that Tweetbot's web view has a Readability mode and its double tap gesture on tab bar icons for timelines can scroll to the last read tweet if possible. Clarified that Twitterrific can load favorites and mentions on other people's profiles too.
The apps tested for this article were the latest versions of Twitter, Twitterrific, and Tweetbot 3 for iPhone.
I only considered Tapbots’ iPhone app due to the lack of Tweetbot 3 for iPad. Both Twitter and Twitterrific (Universal apps) were tested in their iPhone and iPad versions, with design and feature differences noted when appropriate.
You can click (or tap) images to get a full-size version. You can link to any specific section using the Table of Contents above.
This is not a feature-by-feature comparison. If you can’t find a feature you care about in this article, it’s not because I don’t think it’s important. Rather, it means that I don’t rely on that feature and I’m not knowledegeable about it enough to cover it (this policy applies to all MacStories reviews).
Please also note that I approached this with the idea that Twitter is not evil because it’s trying to make money with ads. If you’re sure you won’t be able to use any Twitter client with ads in the timeline, this article won’t convince you of the contrary (nor does it want to). The Twitter app has ads.
And finally, I’d like to thank Silvia, Myke, Stephen, and Graham for their notes and feedback on the article. Their patience is always immensely appreciated.
That said, let’s dive in.
Loading Timeline Gaps & Tweet Marker Sync
I’m a Twitter completionist. Because I’ve always used the service to discover interesting new apps and links, I’ve developed a habit of trying not to miss a single tweet that is shared or retweeted in my timeline, with the only exception for the weekends.
Particularly after launching better linked posts on the site and starting our MacStories Weekly newsletter with a dedicated Links section, discovering stuff on the Internet has become essential to my livelihood, and Twitter is the best (and most diverse) service for this. I know that I haven’t missed cool apps, links, and news thanks to my dedication to reading my entire timeline every day, and for this reason, in spite of strong evidence suggesting that Twitter doesn’t intend timelines to be consumed this way, I won’t change how I read Twitter.
This behavior makes timeline gaps and timeline sync one of the most prominent aspects I have to consider in a Twitter client. I want to be able to wake up in the morning and start reading my timeline from where I left it the night before; and, I want to know that I can close Twitter for a couple of hours in the afternoon without losing my place in a stream of tweets. More importantly, whenever a timeline gap occurs[3] I need the ability to load tweets without making the timeline scroll and lose my position.
Unfortunately, the official Twitter app doesn’t support sync and leaves much to be desired for timeline gaps.
The app is capable of detecting timeline gaps[4], but it can keep your position (load tweets above or below) in the timeline only if you tap “Load more Tweets” when the gap is close to the top or bottom of the stream. It’s not clear that Twitter for iOS supports this (there’s no visual indication like in Tweetbot), and, sometimes, the app still scrolls the timeline upon loading tweets from a gap.
This means that you may end up scrolling back and forth in your timeline if you want to keep reading Twitter exactly where you left off, which can be a considerable waste of time when you’re a completionist and follow >1000 accounts. The lack of sync makes everything worse as timeline position isn’t shared across devices.
In practice, the Twitter app results in several minutes I spend scrolling and trying to find the last tweet I saw when I closed the app. Every morning and whenever I leave the app for a couple of hours, Twitter either completely reloads the timeline (pushing me to top to see the latest tweets) or inserts a timeline gap that occasionally fails to load new tweets above my position.
Combine this with the app’s tendency to not restore its state when it’s launched, and it’s easy to understand that Twitter doesn’t care about treating its timeline as a stream of tweets you want to read in its entirety from oldest to newest. In spite of timeline gaps, Twitter seems to be all about the latest tweets and providing you with fresh content, which can be tedious for a completionist – a problem that is common to modern social apps such as Facebook and Instagram as well.
Twitterrific fares better in this comparison, but I find the best implementation to be Tweetbot’s. Both apps support timeline gap detection and both allow you to sync your timeline position with iCloud and Tweet Marker, but Tweetbot has been faster and more reliable in my tests.
The concept of timeline sync between Twitter clients across multiple devices was popularized by Tweet Marker, a service launched by Manton Reece in 2011 (first teased as Tweetmarks) and that is embedded in dozens of clients for iOS and OS X. Tied to your Twitter account, Tweet Marker offers a mostly invisible, volatile bookmark that saves your position in the timeline every time you use an app that integrates with the service. This allows you to, say, stop reading tweets from 2 hours ago in Tweetbot on the iPhone and pick up in the same spot in Twitterrific for iPad without having to scroll to find the last tweet you saw. The implementation varies across apps and it’s dependent on how developers handle timeline gap detection and scrolling.
In Twitterrific, you can choose to show the visual Tweet Marker indicator and automatically scroll to it. When the same set of tweets is loaded across two different clients, Twitterrific is usually able to quickly take you to the last tweet you were at when you closed another Tweet Marker-enabled app. If you keep two apps open at the same time, Tweet Marker sync tends to be flawless in Twitterrific.
In my experience, Twitterrific loses position in the timeline when it has to deal with tweets that haven’t been loaded yet and that require loading a timeline gap. Twitterrific with Tweet Marker sync works well with recent tweets (e.g. You left home thirty minutes ago and want to keep reading tweets now that you’re at the grocery store), but it doesn’t work well when there are hours of tweets between the most recent tweet in your timeline and your last position hundreds of tweets ago.
Tweetbot has the most solid implementation of timeline gap loading and Tweet Marker sync. Tapbots’ app rarely fails to load your last position when you launch it and it’ll always try to load as many tweets as possible (as allowed by the API) between your position and recent tweets above a timeline gap. Tweetbot shows a visual Tweet Marker indicator, always scrolls to the last tweet saved by Tweet Marker, and can keep position for the Mentions tab, too.
What’s great about Tweetbot is that beyond stable Tweet Marker sync and handling of timeline gaps, it also clearly indicates how to load more tweets above or below a gap in the timeline. When I wake up in the morning and I want to catch up on all the tweets I missed overnight, I can let the timeline gap turn into tweets above my current position so the full stream is loaded and I can keep reading without scrolling back to older tweets. Tweetbot appears to be designed with an eye for timeline completionists, and it has been this way since its early adoption of Tweet Marker.
Both Twitterrific and Tweetbot come with a second option for timeline sync – iCloud. I, however, have always preferred Tweet Marker for two reasons: I never had issues with Tweet Marker (unlike my iCloud account), and it works across multiple apps from different developers. So while iCloud adds the benefit of marking direct messages as read in Tweetbot, it doesn’t sync my position between Tweetbot and Twitterrific, which Tweet Marker handles elegantly.
Web Views
I spend a considerable amount of time discovering links on Twitter and opening webpages to see what they’re about. For this reason, being able to effortlessly switch between web views and the timeline as well as the ability to quickly share links to other apps are valuable aspects in my Twitter workflow.
The Twitter app is, again, a disappointment from this standpoint. Links in Twitter open in a modal web view that takes over the entire app, with the title of the webpage displayed in the title bar. You can tweet a link (the only instance where the web view will be superseded by a UI element of the app), copy it, mail it, send it to a read later service, or open it in Safari; you can’t share it natively with extensions because, for reasons unknown, Twitter doesn’t support the native iOS 8 share sheet.
I cringe every time I have to open a web view in the Twitter app because it means that a webpage needs my full attention while it’s loading – I can’t switch to another part of my timeline, and I can’t dismiss the web view but keep it open in the background. The lack of share sheets only exacerbates my distaste for Twitter’s web view: I can’t easily save links to extensions when I’m using Twitter, which slows me down.
The only nice touch of Twitter’s web view is that it displays the full URL of a webpage in the title bar under the webpage’s title.[5] Twitter also displays a lock icon for HTTPS connections, which is a welcome plus.
Web views are much better in Twitterrific: they’re still modal, but Twitterrific supports a readability mode for webpages (either Instapaper or Readability) and lets you share URLs using the iOS 8 share sheet. Twitterrific doesn’t display webpage URLs and titles simultaneously (it only shows the URL while a webpage is loading) and it doesn’t come with any special icon for HTTPS, but it adds a dedicated 1Password shortcut to quickly fill logins with the 1Password extension (which I never used personally for links in tweets).
Support for share sheets in web views makes processing links great in Twitterrific for iPad: once you get used to the power and convenience of extensions, it’s hard to use the custom sharing menu of the Twitter app, unreasonably limited to options Twitter decided for its users and that don’t make Twitter a good iOS 8 citizen.
Unfortunately, Twitterrific suffers from the same issue of other apps that implement extensions: the system can be flaky. Twitterrific displays action extensions for webpages that are also supported by Safari, but only Safari returns the full DOM of a webpage, which makes extensions such as ImageDrain and Stacks useless in Twitterrific. This isn’t Twitterrific’s fault – just like I can’t blame the app for messing up the order of extensions if the share sheet is modified with drag & drop.
The way Tweetbot handles opening links from any view of the app is my favorite. As I mentioned in my original review of Tweetbot 3 last year, Tapbots built a web view system that lets you open a link without the in-app browser taking over the entire app. Each web view is modal to the view it was activated from: if you open a link from the timeline view, the timeline will turn into a web view, but you’ll still be able to switch to other sections such as Mentions or Favorites.
Tweetbot's web view. Notice how the only active tab is the Profile one, where the web view was activated from.
This design choice frees you from the pressure of having to open a link knowing that you won’t be able to use the app in any other way while a webpage is shown, and it also lets you open multiple web views relative to their originating sections – you can open a link from the Timeline and another one separately in Search, for example. This is great if you want to multitask with web views in Tweetbot, and it makes me wish that more apps – not just Twitter clients – would be inspired by it.
Tweetbot also supports extensions with the same limitations of share sheets from Twitterrific. The system mostly works – I smile every time I can easily save a link to Todoist or a tweet to Notebox without leaving the app I’m using – but extensions can occasionally fail.
A web view in Twitter, Twitterrific, and Tweetbot.
In switching between these three clients for the past months, I’ve noticed that I miss Tweetbot’s non-modal web views but I prefer the iPad to go through favorites I want to turn into todos or notes, and thus Twitterrific. The Twitter app has a lot to learn from The Iconfactory and Tapbots when it comes to web views, but it makes up for those deficiencies at the very starting point: previews for links.
Cards and Previewing Tweets
Twitter offers a feature called Twitter Cards that enable you, as a user, to preview content without leaving the Twitter timeline for a web view. There are different types of cards: from the popular Summary and Gallery to the more peculiar Lead Generation and Audio Player cards, the official Twitter apps support a wide range of interactive media previews that aren’t made available to third-party clients via API.
I suspect that most Twitterrific and Tweetbot users who never used the Twitter app for extended periods of time largely ignore the existence of Twitter Cards – I assume so because I did that. Since I started using Twitter on iOS, I became fascinated with the concept and realization of cards – so much that MacStories’ tweets support the Summary card and readers can sign up to our Weekly newsletter directly from Twitter.
Examples of Twitter Cards.
I first wrote about cards on MacStories when Twitter launched audio cards for SoundCloud and iTunes:
Besides the obvious photos, galleries, and aforementioned audio cards, there are several types of cards that get expanded or are interactive in the Twitter apps for iOS. In the months I’ve spent using Twitter for iPhone and iPad, I’ve come to expect articles to reveal Summary Cards (we support them with MacStories links) because they often tell me whether a link is worth opening or not just by looking at their preview. I find summary cards for web articles to offer more information and to be more respectful of my time (and cellular data).
In short, Twitter Cards turn tweets into rich previews that are easy to understand without visiting a webpage. Often, these previews embed relevant media directly in the timeline, so you can view images/press buttons without even opening a tweet’s detail view.
I’ve become a fan of Twitter Cards because they help me save time and find more cool links. Sometimes, the text that accompanies a link doesn’t really sell the article: by tapping the tweet, I can see if there’s a Summary card and take a look at the first image of an article, perhaps a brief description too, and decide whether the link may actually be worth opening or not. I was able to reevaluate dozens of links that I then used for MacStories or MacStories Weekly thanks to the Summary card. Same deal with YouTube videos: YouTube supports the Player card, which gives you a tappable video thumbnail and a description of the video in the tweet detail view.
App deep-linking in Twitter. Spotify should look into their Unicode handling.
Most cards are deep-linked to their official apps, meaning that content can also be viewed directly in a native app if it’s installed on your device. YouTube videos can be played back in the YouTube app, Spotify links can be opened in Spotify, Kickstarter projects can be displayed in the official Kickstarter app, and so forth. This is optional – you have to tap a dedicated “app button” in the tweet detail view to beam content to its associated app, and it’s a great experience if you prefer native apps to web views. If you don’t have the app installed, Twitter will let you download it from the App Store using SKStoreProductViewController, which opens an App Store panel that doesn’t take you away from the app.[6]
Even more impressive is when cards are more than thumbnail previews and bring interactive content to the Twitter timeline. Thumbnails for Kickstarter links can be tapped and a player for a project video will open immediately; iTunes Movie Trailers thumbnails also turn into a video player inside the Twitter app (Star Wars proof); SoundCloud links feature a special Audio Player card that turns into a persistent mini-player.
Cards are a smart move: they don’t compromise the 140-character nature of tweets, but instead they use web content to offer previews with deep ties to native apps that, in my opinion, make a lot of sense for an information network on a mobile device. I want to be able to open YouTube videos in the YouTube app and of course Kickstarter links should offer an option to easily switch to the Kickstarter app that already has all my credentials and preferences.
In daily usage, Summary Cards are the ones I see and use the most, and I’ve grown used to being able to preview articles before I tap them: it’s a great way to avoid clickbait and other sensationalistic garbage. Unlike other cards, web summaries aren’t embedded directly in the timeline – you’ll need to tap tweets to see them.
Cards work in the opposite direction of traditional clients: instead of forcing you to tap a link, they bring a native snippet of the web to you.
But there’s a problem: supporting Twitter Cards is entirely up to the publisher/content owner, and for this reason not every link automatically gets a rich visual preview on Twitter. While popular blogs and media services tend to support Twitter Cards nowadays, there’s still a vast sea of independent publishers who have no idea what the benefit of a card could be, or, really, what a Twitter Card is. When links aren’t supported by a card in the timeline, Twitter falls back to looking like Tweetie and any other client: a tweet, and a blue hyperlink.[7]
I also want to briefly mention the unusual and powerful Lead Generation Card that we’re using to handle signups to our MacStories Weekly newsletter through Twitter. Thanks to integration with MailKimp, Twitter lets you build cards for your newsletter that display a description and signup button alongside a tweet in the official Twitter app. To sign up, Twitter uses your configured email address: tap a button, and you’re signed up. No need to open a web view (although you can), no need to type your email address. This card type also extends to buy products from cards (which I haven’t tried) and other services that turn Twitter users into customers.
As a user, I’m a fan of the idea, although it still feels strange to be able to act on tweets and not just “consume” them. As a website owner, I can say that Twitter signups doubled our newsletter subscribers overnight since we tested them, which has been a positive experience.
Cards aside, Twitter has long supported timeline previews for photos, a feature that was expanded in the past year to include multiple photos and animated GIFs. I was initially put off by the former, but I’ve learned to appreciate the ability to include multiple attachments in uploads, and I’ve started to think of pictures as separate entities from the limited character space of tweets.
Native GIFs are welcome: GIFs I have in my iOS library can be uploaded through the Twitter app, but the service encodes them to video instead of preserving the original GIF format, which I’m not a fan of because I can’t redownload them. Still, they look like GIFs in the Twitter timeline, which should be okay for most people.
The Twitter app disappoints with direct URLs to images or videos stored elsewhere. For a long time, Tweetbot and Twitterrific have been able to turn image and video URLs into inline previews – a nice touch if you want to link to a GIF stored on your own server/S3 bucket or simply link to an image from someone else’s website. This is the epitome of a third-party client feature: it’s the right thing to do, but Twitter likely wants to encourage uploads to its own photo service, so they won’t support direct links to images or videos with native previews.
Three video cards and a GIF in Twitter for iOS.
A great touch of the official Twitter app is that playing videos (whether they’re previews in the timeline or videos embedded in a web view) doesn’t pause audio playback that may be happening in another app. Instead, Twitter will simply lower the volume of existing audio playback in the background and play a video you’ve tapped alongside it.
I come across this difference on a daily basis: I always have music or podcasts playing on my iPad when I’m working, and I don’t want them to pause because I chose to view a Vine or YouTube video in Twitter. This will be strange the first time you’ll see it in action, but, at least for me, it absolutely started making sense after a couple of days and I now wish that iOS had an option to play multiple media items at the same time.
Twitter Cards aren’t available to third-party clients over the API, which has forced Tweetbot and Twitterrific to come up with their own custom integrations to display tweet previews for web content. The result is that the timeline shown in these two clients will look different and out of place after you get used to the richness of previews in the Twitter app.
For Tweetbot, Tapbots didn’t build any sort of visual preview for article links, which are shared and diplayed as regular hyperlinks in the app. Tweetbot has proper support for Twitter photos (both for tweets containing single and multiple photos) and it can load and show an inline preview for any URL that points directly to an image stored elsewhere. This is useful if you want to tweet GIFs using links fetched from services like Giphy – they will be visualized inline by Tweetbot, which comes in handy when you don’t want to share a native GIF through the official Twitter app (Tweetbot can’t upload GIFs to Twitter with the API).
Notwithstanding its API limitations, Tweetbot provides decent support for image and video previews. The app shows thumbnails for YouTube, Vine, and Instagram videos, which are differentiated from image thumbnails by a Play button; while YouTube thumbnails will take you to a YouTube web view, Vine and Instagram videos will play in a popup over the timeline. The same video player is also used for native Twitter GIFs, which are always transcoded to video by the service.
Tweetbot shows inline previews for Instagram[8], Droplr, CloudApp, Flickr, img.ly, Mobypicture, and yfrog images. Tweetbot can’t support previews for images shared in Direct Messages, and it can’t preview native Twitter videos (such as this one) either. The former is a particularly annoying limitation, as tapping an image URL shared in a DM will open a Twitter web view that will require authentication.
One of my favorite touches of Tweetbot is its ability to preview iTunes content inline, which I appreciate when it comes to iTunes links for apps.
Twitterrific, like Tweetbot, can’t support Twitter Cards and doesn’t have any inline previews for web links. Twitterrific shows previews for native Twitter photos, but only individual ones; Twitterrific, in fact, still hasn’t been updated to support multiple Twitter photos, so tweets containing more than one photo will only show the first one in Twitterrific. This is a major issue if you want to make sure you always see all photos attached to a tweet. Twitterrific can’t show native Twitter GIFs either.
Twitterrific displays inline previews for Droplr, CloudApp, Instagram, and Flickr links, but tapping their thumbnails (which can be set to small or large) will open a webpage to view the full image – it won’t load the image in a floating popup (as is the case with Twitter photos). Twitterrific can, however, load direct image URLs without opening a web view, which also shows a progress bar on top of the timeline.
Thanks to its integrated previews and iTunes support, I prefer Tweetbot to Twitterrific for previews of images and videos uploaded to third-party services.
The evolution of Twitter from quick status sharing service to an information network that spans text, links, and media has left third-party clients in the cold for Cards and the photo features the service has been rolling out in the past year. Tweetbot and Twitterrific – primarily due to API limitations but also because of their own implementations – largely treat Twitter timelines as streams of text with the occasional photo or GIF.
In the months I’ve spent using the Twitter app, I’ve come to expect my Twitter client to support multiple photos, native GIFs, summaries for web articles, and other static or interactive previews with Cards. I want to be able to listen to SoundCloud snippets in the timeline with a mini player, and I appreciate that Twitter gives me the tools to let people subscribe to my newsletter easily and securely.
Twitter is inconsistent in its implementation of Cards and previews across platforms. The iPhone app is the company’s most supported and frequently updated mobile client, always receiving the latest design updates and feature additions. On the iPad, only some card types are supported, while others are inexplicably broken.
In practical usage, I’m faster at discerning interesting links in the Twitter app because of its support for Summary Cards. The convenience of being able to see a quick preview of an article allows me to decide whether a link deserves my attention before tapping it. Selecting a tweet to see a summary is still faster than switching back and forth between the timeline and a web view. My main issue is that Twitter Cards aren’t supported by a few websites I read frequently; I wish more publishers added Cards integration to their content for Twitter users.
Extensions
Twitter doesn’t support native iOS 8 share sheets; Twitterrific and Tweetbot do. I don’t understand Twitter’s decision.
As I wrote last month:
I don’t understand why, two months after the release of iOS 8, the official Twitter app for iOS doesn’t implement the system share sheet for action and share extensions. There is no technical hurdle preventing Twitter from adding their own custom buttons to a share sheet or coming up with ways to show both custom and native share sheets. If the decision is political because Twitter doesn’t want to allow users to easily share Twitter content to external services, then it’s a stupid one, likely driven by an absurd idea that “user lock-in” is good for “engagement” and other buzzwords possibly made up by the same person in charge of the strategy statatement (but isn’t a share sheet all about connecting people to their world and other brands after all? Isn’t a share sheet “information sharing”? This is why I’m not a CFO, I guess). If a share sheet is considered dangerous by Twitter, then I guess that Twitter has bigger problems to worry about. Thankfully, third-party Twitter clients are still around to be good iOS citizens.
The way I see it, it makes no sense for Twitter to withhold support for the native iOS share sheet when they already have a few custom options that could be supplanted by better, official, and native extensions to let users share tweets and links to more services. If the decision is political, it’s a stupid one; if the reason is that this isn’t high on Twitter’s priority list, then their iOS team should know better.
Tweetbot and Twitterrific let you share tweets and links from the timeline and web views via extensions, which is useful. The entire extension framework in iOS 8 is still buggy and prone to presenting errors and it occasionally crashes, but there’s nothing Tapbots and The Iconfactory can do about it. Developers need better tools to debug extensions, filter them by type, and disable them when necessary, so hopefully Apple will keep improving the system over time.
Curiously enough, neither Twitterrific nor Tweetbot offer a share extension to send tweets using their app interfaces from anywhere on iOS. It’s a strange omission considering that both apps were quick to embrace share sheets for getting links out of their respective apps.
I’ve been using Twitterrific to save links through extensions because it’s available on the iPad and it lets me go through my Favorite tweets (I give a lot of faves every day) and send them to other apps easily. I loved the ability to merge links to multiple tweets with Notebox, and that wouldn’t have been possible without Twitterrific for iPad, updated for iOS 8. If you only care about Twitter clients on your iPhone, support for extensions in Tweetbot and Twitterrific is mostly the same – Twitterrific may get a slight edge over Tweetbot because it lets you save individual DMs through extensions.
Twitter should really add support for share sheets to its iOS app. The reliance on old and custom sharing options is inexcusable and it slows down the user experience.
Gestures
Note: The following section is technical and boring if you’re not into gestures. I decided to include it for the sake of research and to mention a few smaller implementation details. If you’re not interested, you can skip to the next section by clicking here.
Ever since I began using Tweetie in my iPhone in 2009, I’ve grown used to interacting with my timeline using gestures. Long presses, swipes, double taps, quick flicks – iOS has provided a great opportunity for developers to explore how multitouch can simplify the act of browsing your timeline and hide functionality until you need it.
In using Tweetbot, Twitterrific, and Twitter for iOS over the past months, I’ve collected how these three apps implement gestures differently and the trade-offs involved with enabling new iOS features and interaction patterns.
Tap & Hold
Twitter
On the iPad, you can tap & hold on a tweet you sent to:
Mail tweet
Copy link to tweet
Send to read later service (if contains link)
Delete
The iPhone app has the same options, but it adds a shortcut to share a tweet via DM.
You can also tap & hold tweets sent by others on the iPad to:
Mute
Block or report
Mail tweet
Copy link to tweet
Send to read later service (if contains link)
The iPhone adds, again, Share via Direct Message but presents the other options in a different order. It’s not clear why Twitter isn’t applying some consistency to this menu, as it makes things slower when switching across devices.
You can also tap & hold links directly in the timeline of Twitter for iOS, and, in this case, the options are the same between the iPhone and iPad app:
Tweet (it’ll place the cursor before the link, adding a space between them)
Mail
Copy
Send to read later service
Open in Safari
Tap & hold is supported for user avatars as well, showing integration with Apple’s Contacts app:
Mute
Block or Report
Create new contact
Add to contact
In the same vein, you can tap & hold usernames in tweets, but only from a tweet’s detail view because usernames aren’t directly tappable in timeline. When you do, you’ll get these options:
Copy
Create new contact
Add to existing contact
And, of course, you can tap & hold photos to:
Tweet photo
Save photo
In addition to timeline tap & hold shortcuts, you can long-press the Me tab to show the account switcher, both on the iPhone and iPad.
The last tap & hold shortcut is one of my favorite ones: you can tap & hold the compose button (top right) to bring up a Drafts screen so you can modify a saved draft and send it as a tweet.
Twitterrific
Twitterrific and Tweetbot are more consistent with the rest of the system in that they have now replaced their former custom menus with share sheets for the most part.
In Twitterrific, long-tapping a tweet shows the share sheet with extensions, passing the Twitter URL of a tweet to it. The share sheet contains custom buttons to copy a link to the tweet, open it in Safari, tweet its link again, and translate it.
This idea of using the share sheet for every tap & hold gesture is carried out through the entire app with slightly different results:
Usernames: the @username is passed to an extension; share sheet contains buttons to copy the profile’s URL and tweet the @username. Usernames are tappable in the timeline.
Links: the URL is passed to the share sheet, which contains custom buttons to open it in Safari and tweet it.
Hashtags: the share sheet receives the hashtag’s name and has buttons to copy a Twitter link for a hashtag’s search, view the search in Safari, and tweet the hashtag.
Images from the timeline: the share sheet captures the Twitter photo’s URL.
Images from the expanded view (tap image first): share sheet, but the image file is passed to extensions, so you’ll see a different set of them (such as Dropshare).
Furthermore, Twitterrific lets you tap & hold tabs to customize them, and you can also long-tap your profile picture in the top left to bring up the account switcher. In the timeline, you can tap & hold the retweet button (tap tweet first) to open the compose screen in old-style RT mode.
Tweetbot
Tapbots’ take on tap & hold gestures is similar to The Iconfactory’s, but Tweetbot still has a few custom panels that don’t use the iOS 8 share sheet.
The share sheet is used in the following places in the app:
Tweets: the Twitter URL is passed to extensions; there are custom buttons to copy a link to the tweet, copy the tweet’s text, and open it in Safari.
Links: the URL is passed to extensions; there are buttons to open the link in Safari, copy it, and tweet it. Like the Twitter app, tweeting a link this way places the cursor before the link in the compose field, adding a space.
Images from timeline: the share sheet receives the Twitter photo URL; there are buttons to open in Safari, copy, and tweet a link.
On the other hand, Tweetbot’s tap & hold gestures use custom panels for:
Usernames and avatars: the panel shows follow status and buttons to DM, manage in lists, mute, unfollow, and report for spam. Usernames in Tweetbot are clickable in the timeline.
Images in expanded view: the menu has options to save or copy the image, plus view it on the web and tweet its link. There are no photo-oriented share and action extensions in Tweetbot.
Hashtags: options to tweet the hashtag, copy it, and mute it.
In addition to share sheets and panels, you can tap & hold the gear icon in a tweet’s detail view to post a link to the tweet and long-tap your avatar or username to view your profile on Favstar. Tweetbot lets you tap & hold tabs to customize them and, like the Twitter app, long-pressing the compose button opens your existing drafts.
As I noted when version 3.5 was released, adopting the system share sheet forced Tapbots to drop the ability to view full URLs by holding them.
Double taps
Double taps don’t seem to be popular in Twitter clients. The only use I’ve found was in Tweetbot, which lets you double tap in four different places:
DM tab bar icon: mark all messages as read;
Tab bar, any timeline: scroll back to the top (Twitter uses a single tap for this; Twitterrific simply relies on tapping the status bar);
Search tab bar icon: get into the search field and start typing;
Profile tab bar icon: open your Favstar profile.
Swipes
Like double taps, swipe gestures aren’t used too much in the Twitter clients I tried. Tweetie was famous for its swipe gesture that revealed an action bar for a tweet, but that’s gone in Twitter for iPhone, which uses swipes to navigate across Timeline, Discover, and Activity.
In the Twitter app, you can swipe through photos in profile pages on the iPad and swipe through photos on tweets that contain multiple ones. You can also swipe from the edge of the screen to navigate (iPhone) and swipe to delete DMs.
In Twitterrific, you can swipe right on a tweet to reply, and swipe left to view the conversation; this also works in DMs.
Tweetbot has deeper support for swipe gestures:
Swipe left on a tweet to open its detail view;
Short swipe right on a tweet to fave it, long swipe to reply. The short swipe can be configured to be fave or RT;
Swipe from the edge of the screen to navigate;
Swipe to delete a DM;
Swipe through multiple photos in a tweet;
Swipe up/down with two fingers to change theme.
It’s hard to pick a favorite for gestures: there’s hundreds of details and variables to consider, and iOS 8 has brought consolidation in options shown via tap & hold. Twitterrific and Tweetbot have more convenient gestures than Twitter: Twitterrific is nice for quick replies; Tweetbot has a great flick gesture to dismiss images.
I compiled this list of gestures out of curiosity and to show the little design decisions that can go into what most people would deem trivial or obvious. My takeawa