Introduction

The Mail-style swipe actions from the iOS 7 era were built on UITableView editing APIs, not on a hidden Mail-only component. If you wanted a row to reveal buttons such as Delete and More, the usual solution was to provide custom row actions for a swiped table view cell.

Use Table View Row Actions

For an iOS 7 style implementation, the key delegate method is tableView:editActionsForRowAtIndexPath:. It returns the actions that appear when the user swipes left on a row.

1#import "InboxViewController.h"
2
3@interface InboxViewController ()
4@property (nonatomic, strong) NSMutableArray *messages;
5@end
6
7@implementation InboxViewController
8
9- (void)viewDidLoad {
10    [super viewDidLoad];
11    self.messages = [@[@"Welcome", @"Build Report", @"Invoice"] mutableCopy];
12}
13
14- (NSArray *)tableView:(UITableView *)tableView
15editActionsForRowAtIndexPath:(NSIndexPath *)indexPath {
16    UITableViewRowAction *moreAction =
17        [UITableViewRowAction rowActionWithStyle:UITableViewRowActionStyleNormal
18                                           title:@"More"
19                                         handler:^(UITableViewRowAction *action, NSIndexPath *path) {
20        [self showMoreMenuForIndexPath:path];
21    }];
22    moreAction.backgroundColor = [UIColor lightGrayColor];
23
24    UITableViewRowAction *deleteAction =
25        [UITableViewRowAction rowActionWithStyle:UITableViewRowActionStyleDestructive
26                                           title:@"Delete"
27                                         handler:^(UITableViewRowAction *action, NSIndexPath *path) {
28        [self.messages removeObjectAtIndex:path.row];
29        [tableView deleteRowsAtIndexPaths:@[path] withRowAnimation:UITableViewRowAnimationAutomatic];
30    }];
31
32    return @[deleteAction, moreAction];
33}
34
35@end

This gives you the familiar trailing buttons. The returned order affects how the actions are displayed, so test the exact arrangement you want.

Implement the More Action as a Secondary Menu

Delete usually maps directly to one model update. More is different because it typically reveals a second set of options such as Flag, Archive, or Mark as Read.

For the iOS 7 era, UIActionSheet was a common historical choice.

1- (void)showMoreMenuForIndexPath:(NSIndexPath *)indexPath {
2    UIActionSheet *sheet =
3        [[UIActionSheet alloc] initWithTitle:@"Message"
4                                    delegate:nil
5                           cancelButtonTitle:@"Cancel"
6                      destructiveButtonTitle:nil
7                           otherButtonTitles:@"Flag", @"Archive", nil];
8
9    [sheet showInView:self.view];
10}

In production code, you would connect the selected action back to the underlying message model. The key point is that the More button is a gateway to secondary actions rather than a final action itself.

Keep the Data Source in Sync

The visual swipe UI is only half of the feature. The backing array has to stay consistent with the table view updates. If you animate a row deletion without removing the corresponding model item, the next reload can reinsert the row or cause index mismatches.

That matters even more when actions involve asynchronous work. If deleting a message also hits a server API, decide whether the UI should update optimistically or only after confirmation. Either strategy can work, but mixing them inconsistently creates confusing behavior.

Separate UI Code from Row Action Logic

It is tempting to put all business logic directly inside the row action block, but those blocks become hard to read quickly. A better pattern is to call helper methods for delete, archive, or additional menus.

That makes the swipe configuration easy to scan and keeps model-side behavior testable.

Modern Equivalent for Newer iOS Versions

If you are maintaining an old app while also targeting newer iOS versions, it is worth knowing the modern replacement. UITableViewRowAction was eventually superseded by UIContextualAction and UISwipeActionsConfiguration.

1override func tableView(
2    _ tableView: UITableView,
3    trailingSwipeActionsConfigurationForRowAt indexPath: IndexPath
4) -> UISwipeActionsConfiguration? {
5    let more = UIContextualAction(style: .normal, title: "More") { [weak self] _, _, done in
6        self?.showMoreMenu(at: indexPath)
7        done(true)
8    }
9
10    let delete = UIContextualAction(style: .destructive, title: "Delete") { [weak self] _, _, done in
11        self?.messages.remove(at: indexPath.row)
12        tableView.deleteRows(at: [indexPath], with: .automatic)
13        done(true)
14    }
15
16    return UISwipeActionsConfiguration(actions: [delete, more])
17}

That is not what you would ship for a strict iOS 7 target, but it is useful context when maintaining older interaction patterns in a modern codebase.

Common Pitfalls

A common mistake is animating the row deletion without updating the underlying array. The table view may appear correct briefly and then break on the next reload.

Another issue is packing too much logic into the action handler blocks. Keep the handlers thin and move real work into helpers.

Developers also sometimes assume the Mail app behavior is a built-in mode they can enable. It is not. You implement the actions explicitly through table view APIs.

Finally, be careful with destructive gestures. Immediate delete on swipe is convenient, but important data may need confirmation or undo support.

Summary

• Mail-style swipe actions on iOS 7 are built with table view editing APIs.
• Use tableView:editActionsForRowAtIndexPath: to provide Delete and More actions.
• Keep the backing data source synchronized with any visual row change.
• Use the More action to expose secondary operations without crowding the cell.
• Prefer modern contextual swipe APIs only when the deployment target allows them.