What Twitter for iPhone 3.3 gets wrong

When it comes to iPhone apps, one thing the world definitely does not need more of is Twitter clients. There are so many out there it’s unreal. And as a heavy Twitter user, I’ve tried most, if not all, of them at some point.

I was a loyal user of the paid-for app Tweetie 2 by Atebits, and when Twitter bought it and converted it into a free application, I continued to use it. It seemed to strike the right balance for me of allowing some access to more sophisticated functions, while keeping them unobtrusive when you didn’t need them.

One of the ways it achieved this was by hiding advanced features – picture uploads, autocompletion of @ usernames and #hashtags, location marking, etc. – behind the keyboard. If you clicked the button that displayed the number of characters remaining, the iPhone keyboard would slide down, revealing the additional options.

I suspect that some of these functions were so well hidden that some users didn’t realise they were there at all. Which is why, I’m guessing, that with the latest update, to Twitter for iPhone 3.3, the key ones are now visible as you compose your tweet (compare with this screenshot from GigaOM’s review of Tweetie 2):

Twitter for iPhone's new editing screen, with completions and geotagging

Also previously hidden, the ‘shrink URLs’ option is now an automatic function, with Twitter using its t.co shortening service on the fly. When tweets are displayed, the t.co link is replaced by an abbreviated version of the destination URL, making it easier to spot where people would like to send you should you click on their links.

All this is great. They are gradual refinements that shows that great iPhone design eschews gimmicks in favour of straightforward, simple and practical application.

If only the rest of the app followed the same rules. I’m going to set aside the repeated crashing I had with version 3.3.0 – when it comes to apps that repeatedly crash on startup, I’ve been there, done that, and feel the developers’ pain – and concentrate on some of my bugbears.

No more Twitlonger

In previous versions of Tweetie/Twitter for iPhone, if you went over the service’s 140 character limit, you could opt to post your message to twitlonger.com, so the start of your message would show in Twitter followed by a link to a web page containing the whole thing. TweetDeck recently introduced their own service, deck.ly, which performs a similar function.

As the official app run by Twitter itself, it doesn’t surprise me that they’ve chosen to withdraw this functionality from their own apps. It does make me realise how often I came to rely upon its presence, though. No more lazily thinking ‘that’ll do’ if I can’t get my message sufficiently abbreviated now…

The quick bar

When version 3.3 was first issued, the most vociferous complaints from users were the new ‘quick bar’, which rotates through some of the current trending topics – which may include one that is clearly labelled as a ‘Promoted topic’ whose placement has been paid for.

The new 'Quickbar' in Twitter for iPhone 3.3

Personally, I don’t have an issue with that, although plenty of other users apparently do. The initial implementation was buggy, and meant the quick bar had a tendency to overlap other information when it wasn’t intended to. Version 3.3.1, issued a couple of days ago, fixes that bug, and the quick bar is now far less intrusive.

My issue with it is in its design. It’s been made to look like one of those old-fashioned display boards that you used to see at railway stations, with each label cut in half so that when the top of one is released, it falls to the bottom revealing a new label:

If you want to manually move that display on, you can. Here’s the kicker, though: although the animation works from top to bottom, the gesture you make is a swipe from left to right.

The animation effect acts in a downward vertical motion – but to initiate it yourself, you swipe from left to right

This is not good. For great iPhone app design, you should feel like your fingers & thumbs are completely in control of whatever you’re manipulating. iBooks’ over-the-top page curls are excessive UI clutter, but at the very least they respond to your finger strokes in ways you’d expect. Using a horizontal motion to initiate a vertical action is not good.

Location services

This one really bugs me, far more than it probably ought to. As I said above, Twitter for iPhone (and Tweetie before it) has long been able to mark an individual tweet with your precise location, with an option that was turned on or off as one of the options hidden behind the onscreen keyboard.

That feature, like the username and hashtag completion options, is now visible as you compose, and you can turn location management on or off at will:

Twitter for iPhone's geotagging support has a new, map-based interface. Shiny.

However, even with location marking off, the Twitter for iPhone app is still accessing the iOS Location Services API, as indicated by the arrow in the iPhone’s notification bar.

Note that although the geotagging for this post is not switched on, the Location Services icon is still showing in the top right…

In Apple’s developer documentation, it makes it quite clear that using the Location Services API is a battery drain. Even at its most basic level – where an app receives occasional notifications that you have moved location by a significant distance – using the Location Services API will eat into your mobile device’s precious battery charge.

I’m at a loss to see why Twitter needs this service on at all times. It can’t be to show localised trending topics, which only exist for a few cities worldwide. I suspect it’s a bug, and one that should be fixed.

UPDATE: The changelog for Twitter 3.3.2 includes “Disables significant location change monitoring that was causing compass to appear constantly when in app”, which should do the trick (I have yet to test this).

Still broken: Direct message notification

One thing that plagues several Twitter apps that I’ve used on my iPhone is the seeming inability to remember which direct messages I have already read. Every time I launch the app, it seems I must switch to the DM pane and either read them again, or use the ‘hidden’ feature of double-tapping the DM icon in Twitter’s tab bar to reveal the ‘Mark all DMs as read’ option.

One of these days, Twitter will see fit to fixing this. But in the meantime, talking of the tab bar…

The custom tab bar: slow and buggy

Many iOS apps use Apple’s standard ‘tab bar’ control – a series of buttons on a black bar at the bottom of the iPhone screen, used for switching between views. It’s a great control that works well out of the box.

What is not immediately obvious is that Tweetie/Twitter for iPhone’s implementation is subtly different. As well as highlighting the current view in the standard way, the app adds a small arrow at the top of the bar, which slides into position above the currently selected button as you switch between views.

The non-standard tab bar (spot the small arrowhead above the currently highlighted button)

I used to think this was a nice little attention to detail. In this latest build, however, if I attempt to switch views using the tab bar too quickly after starting the app, there’s a noticeable lag between tapping a control to change views, and the view actually changing. IN some cases, the view doesn’t change at all – so the tab bar can be highlighting the Direct Messages control while the main view is still displaying my timeline.

If implementing a custom version of a standard control starts to introduce bugs like this, that’s a good reason to reconsider your design decisions.


I like Twitter for iPhone generally. I don’t mind the quickbar. But there are some design decisions and bugs that get under my skin.

I know I’ve only developed one iPhone app – one that’s far from perfect, and relies on the Three20 framework, which has its own idiosyncracies that at points deviate from Apple’s iOS guidelines. That doesn’t make me an expert on how to work within Apple’s guidelines.

But for me, looking at how great developers like the people behind Twitter for iPhone get it wrong is one way in which I personally can get it a little more right in future.

Author: Scott Matthewman

Formerly Online Editor and Digital Project Manager for The Stage, creator of the award-winning The Gay Vote politics blog, now a full-time software developer specialising in Ruby, Objective-C and Swift, as well as a part-time critic for Musical Theatre Review, The Reviews Hub and others.

One thought on “What Twitter for iPhone 3.3 gets wrong”

  1. I assumed that the issue with Location Services was just a bug that I was experiencing alone, but it's good to hear it's not only me. Annoys me just as much.