Doing the same in the Lists table results in the Settings table appearing in the same way. The reverse is also true – pulling the table “up” from the bottom will result in the previous screen sliding up from the bottom.

This works by exploiting a property of UIScrollView, from which UITableView inherits. The contentOffset property measures how far from the top of its frame the table has been scrolled – it’s measured in pixels, so if a 1000-pixel tall tableView was scrolled halfway, the contentOffset would be 500px.

The trick here is that the contentOffset can also be negative – which occurs when the tableView’s contents are dragged down from the top to leave a gap. Often this triggers the pull-to-refresh methods, but in Clear’s case it’s the cue for new views to be presented.

To catch the user pulling the table down in this way, you can use the scrollViewDidEndDragging:willDecelerate: method which gets called when the user lifts their touch after dragging the table around.

If you check the tableView’s contentOffset at this point and discover that it’s more than, say, minus 60 pixels, you can use that to trigger another method – be it calling a data update, or pushing in new views. An example might look something like this:

-(void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate {
    
    CGFloat contentOffsetY = scrollView.contentOffset.y;
    
    if (contentOffsetY < -60.0) {
        [self displayActivitySpinner];
    }
        
}

Detecting a pull at the bottom of the table is similar – instead of looking for a negative contentOffset, though, you need to detect a contentOffset that’s greater than the tableView’s contentSize.

Again, you’ll need to apply a threshold to this to prevent the new view or whatever being presented as a result of a ‘normal’ scroll action. If the tableView is flicked to the bottom, the contentOffset will exceed the contentSize as the table “bounces”.

What Clear seems to do is have three tableViews loaded at any given time, and then change their frames in a UIView animation block to animate them sliding from the top and bottom of the screen.

It’s clever, although it does rely on the user discovering these interactions – there’s no obvious call-to-action as there would be in the case of a “back” button, for example.

Deleting and completing tasks are done by swiping the row – a left swipe deletes the item, a right swipe marks it as complete. Here’s the basis of how that’s done.

The effect relies on the cell’s contentView having two UIViews “stacked” one on top of the other, and a pair of UISwipeGestureRecognizers attached to the cell – one for left swipes, and one for right swipes. When a swipe is detected, the uppermost UIView is animated left or right to “reveal” the UIView that sits “underneath”. By chaining the animations together with UIView animation blocks, you can also do things like make the animations “bounce” at each end of their range of movement.

The outline process runs like this:

1. Create a UITableView and wire up with delegate and data source as per usual.
2. Create a custom UITableViewCell class, and override the initWithStyle:reuseIdentifer: method to lay out the UIViews inside it. Then implement the animation methods in the custom cell’s subclass, and add the UISwipeGestureRecognizers.
3. Populate your table with instances of your custom UITableViewCell.

The first and third steps are pretty routine, so don’t really need much explanation. The magic, such as it is, happens within the UITableViewCell subclass. The initWithStyle:reusedIdentifier: method can be used to lay out the contents of the cell and set up the UISwipeGestureRecognizers – here’s a sample method:

- (id)initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString *)reuseIdentifier
{
    self = [super initWithStyle:style reuseIdentifier:reuseIdentifier];
    if (self) {
        // Initialization code
        
        // Create the top view
        _topView = [[UIView alloc] initWithFrame:CGRectMake(0, 0, self.contentView.frame.size.width, 80)];
        [_topView setBackgroundColor:[UIColor whiteColor]];
        
        // Create the top label
        UILabel *label = [[UILabel alloc] initWithFrame:CGRectMake(10, 20, 150, 40)];
        [label setFont:[UIFont fontWithName:@"Zapfino" size:18]];
        [label setTextColor:[UIColor blackColor]];
        [label setText:@"Swipe me!"];
        [_topView addSubview:label];
        
        // Create the top image
        UIImageView *pointImage = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"point"]];
        
        CGFloat pointImageXposition = self.contentView.frame.size.width - 160;
        [pointImage setFrame:CGRectMake(pointImageXposition, 18, 144, 44)];
        [_topView addSubview:pointImage];
        
        // Create the swipe view
        _swipeView = [[UIView alloc] initWithFrame:CGRectMake(0, 0, self.contentView.frame.size.width, 80)];
        [_swipeView setBackgroundColor:[UIColor darkGrayColor]];
        
        // Create the swipe label
        UILabel *haveSwipedlabel = [[UILabel alloc] initWithFrame:CGRectMake(10, 25, 200, 30)];
        [haveSwipedlabel setFont:[UIFont fontWithName:@"GillSans-Bold" size:18]];
        [haveSwipedlabel setTextColor:[UIColor whiteColor]];
        [haveSwipedlabel setBackgroundColor:[UIColor darkGrayColor]];
        [haveSwipedlabel setText:@"I've been swiped!"];
        [_swipeView addSubview:haveSwipedlabel];
        
        // Add views to contentView
        [self.contentView addSubview:_swipeView];
        [self.contentView addSubview:_topView];
        
        // Create the gesture recognizers
        UISwipeGestureRecognizer *swipeRight = [[UISwipeGestureRecognizer alloc] initWithTarget:self action:@selector(didSwipeRightInCell:)];
        [swipeRight setDirection:UISwipeGestureRecognizerDirectionRight];
        
        UISwipeGestureRecognizer *swipeLeft = [[UISwipeGestureRecognizer alloc] initWithTarget:self action:@selector(didSwipeLeftInCell:)];
        [swipeLeft setDirection:UISwipeGestureRecognizerDirectionLeft];
        
        [self addGestureRecognizer:swipeRight];
        [self addGestureRecognizer:swipeLeft];
        
        // Prevent selection highlighting
        [self setSelectionStyle:UITableViewCellSelectionStyleNone];

    }
    return self;
}

This is fairly verbose, but breaks down into four stages:

1. creating the top view, which is the one which is viewable when the cell is in the “normal” state
2. creating the bottom view, which is the one that gets revealed when the top view moves
3. adding these two views to the cell’s contentView
4. creating and adding two UISwipeGestureRecognizers to the cell and using these to fire the animation methods.

The animation is done by two methods in the cell subclass, one for right and one for left. Here’s the detail of the rightward-swipe method:

-(IBAction)didSwipeLeftInCell:(id)sender {
    [UIView setAnimationCurve:UIViewAnimationCurveEaseIn];
    [UIView animateWithDuration:1.0 animations:^{
        [_topView setFrame:CGRectMake(-10, 0, 320, 80)];
    } completion:^(BOOL finished) {
        [UIView animateWithDuration:0.15 animations:^{
            [_topView setFrame:CGRectMake(0, 0, 320, 80)];
        }];
    }];
}

It uses UIView's block-based animatedWithDuration:animations: method to chain together a series of moves to give a “bounce” effect – the view that’s doing the movement “overshoots” the end position slightly, and then settles back. The durations in this code are deliberately long to show the effect, but when they’re shorted in practice the bounce effect can really liven up the interface.

In the case of Clear, the swipe gesture methods also trigger updates to the tableView’s data model to mark the task as completed (or deleting it). At a rough guess, there’s a separate section of the table for deleted items that uses another custom UITableViewCell subclass to style the items with the strikethrough and dark background.

The swipe effects are a nice detail in the Clear app, and it’s a great example of how gestures can be used in place of more traditional tap-based interactions. The tradeoff is that the interactions are less apparent – the call to action of a Delete button is obvious, whereas a gesture has to be either explicitly explained or discovered. It’ll be interesting to see if this is the start of a pattern in app design.

[I've put an example app that's a full implementation of the swipe interactions shown above up on GitHub at https://github.com/timd/SwipingTable . And the full process is shown in detail in my book, for which this is a shameless plug (well, if I can't promote it on my own blog, where can I? ]