A few weeks back I ran into an interesting UITableView bug and I finally got around to writing up a test case and submitted a Radar to Apple. The test application source is on my GitHub and I've copied the radar to Open Radar.

I'm working on an app right now that has the option of driving a second screen. There are two methods of connecting such a screen: using a special dock cable to physically connect a monitor; and using Airplay to connect to an Apple TV device and using that screen.

Note that I'm not talking about mirroring the iPad display to the second display, I'm talking about having a completely different UIView on the second display. (This is confusing because iOS calls turning that on "Airplay Mirroring" although it's entirely up to the application whether it actually mirrors the main view or not.)

This second display is primarily a UITableView and it can potentially have quite a few rows to display. Also the intent is to have a screen that can be read at a distance so I use quite a large font (the current "large" size font is 36 point.) Since there's no touch UI there's no way for the user to directly scroll the secondary display but the app scrolls the second display to match a similar table on the iPad display. As the user manipulates the main display the secondary screen scrolls in unison. Well, at least it should and that right there is the bug. In my experience any UITableView method call that takes an animated: parameter does not animate on the Airplay secondary screen if animated: is set to YES. This works fine on the physical secondary screen, but not the Airplay. For example scrollToRowAtIndexPath:atScrollPosition:animated: will silently fail if you try to animate it.

There's also a workaround I have, and you can see it in the code on GitHub. Short form is this: animating the contentOffset value of the table in a GCD block via [UIView animateWithDuration:delay:options:animations:completion] works. So instead of simply scrolling to a row, I calculate a contentOffset for that row and scroll the underlying UIScrollView.

I was not able to find any references to this bug anywhere via Google so I'm not sure it's been reported before. If you want to animate a UITableView on an Airplay secondary screen you probably want to take a look at the GitHub repository.

OK, let's say you're making an iOS app. And it's new so you go to use storyboards because they are awesome and you can target iOS 5.x. Swell. And you're going to use UITableViews and storyboards have that hot new prototype thing where you can lay out your cell right there in the UITableView and you're guaranteed you'll always get a cell from dequeueReusableCellWithIdentifier. Awesome! Well not so fast partner. Go read this Radar and this Radar. Yeah, that sucks. Short version is that works fantastically unless your user has turned on VoiceOver, at which point you don't get a cell at all. The stub code Xcode generates at that point will create a generic UITableViewCell with none of your custom layout. If you're lucky you'll get a blank cell. If you're unlucky your code assumed it got a custom cell type and crashes on some property access or method call. So what do you need to do? You have to old school it and just ignore the new layout feature. You can't require your users to turn off VoiceOver, that's not reasonable. You can leave the prototypes in and they will work in the VoiceOver off case but as far as I can tell there is no way to load a prototype cell from a storyboard. I suspect that you might just be able to rummage around in the nib and find a prototype but I don't see a proper way to do that. In the VoiceOver case you have to provide code that will load a cell from a nib file. You can leave the prototype cells in and that will work in the non-VoiceOver case but now you've got two cell prototypes and that's a bad idea. I do recommend leaving the call to dequeueReusableCellWithIdentifier in place though. Even with VoiceOver on the table can recycle old cells so if you do all of the cell identifier stuff then after a while your view can get a working set of cells that it just reuses on a scroll. Here's a code snippet that rolls this all up. It's not revolutionary but it gets the job done.

    TripTableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];

    // That call is supposed to always work, but it doesn't if the user has VoiceOver on. If they do, we'll engage le hack below

    if (cell == nil) {

        [[NSBundle mainBundle] loadNibNamed:@"TripTableViewCell" owner:self options:nil];

        // The above will load our blankCell field with a new TripTableViewCell.

        cell = blankCell;

With this code you make a nib that contains your custom cell. Then in the view controller you make an IBOutlet like so:

@property (nonatomic, retain) IBOutlet TripTableViewCell* blankCell;

In the nib you set the File's Owner to the controller and connect blankCell to the cell. Like I said, nothing shocking here just some old-school-ness in the new storyboard world …