iOSDevelopment
NSIndexPath
SwiftProgramming
UITableView
AppDevelopment

NSIndexpath.item vs NSIndexpath.row

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

Introduction

In iOS development, IndexPath identifies a position inside a sectioned data structure. The properties row and item both refer to the position component of that path, but Apple uses them in different UI contexts: row for table views and item for collection views.

The Basic Distinction

Use indexPath.row when you are working with UITableView. Use indexPath.item when you are working with UICollectionView.

That is the practical answer most of the time. The underlying index path still stores section plus position, but the semantic name helps match the UI component you are using.

row in Table Views

A table view thinks in terms of sections and rows.

swift
1import UIKit
2
3final class TableViewController: UITableViewController {
4    let names = ["Ava", "Ben", "Cara"]
5
6    override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
7        names.count
8    }
9
10    override func tableView(
11        _ tableView: UITableView,
12        cellForRowAt indexPath: IndexPath
13    ) -> UITableViewCell {
14        let cell = tableView.dequeueReusableCell(withIdentifier: "Cell")
15            ?? UITableViewCell(style: .default, reuseIdentifier: "Cell")
16        cell.textLabel?.text = names[indexPath.row]
17        return cell
18    }
19}

Here row matches the table view API and reads naturally.

item in Collection Views

A collection view thinks in terms of sections and items.

swift
1import UIKit
2
3final class CollectionViewController: UICollectionViewController {
4    let colors: [UIColor] = [.red, .green, .blue]
5
6    override func collectionView(
7        _ collectionView: UICollectionView,
8        numberOfItemsInSection section: Int
9    ) -> Int {
10        colors.count
11    }
12
13    override func collectionView(
14        _ collectionView: UICollectionView,
15        cellForItemAt indexPath: IndexPath
16    ) -> UICollectionViewCell {
17        let cell = collectionView.dequeueReusableCell(
18            withReuseIdentifier: "Cell",
19            for: indexPath
20        )
21        cell.backgroundColor = colors[indexPath.item]
22        return cell
23    }
24}

This is why item exists. The data concept in a collection view is an item, not a row.

Are They Different Internally

In many everyday cases, row and item refer to the same stored position value. The real difference is semantic and API-specific rather than two separate physical indices that can diverge.

That said, using the right one matters for readability and for matching the framework's expected terminology.

Modern Swift Uses IndexPath

Older Objective-C code and some documentation still mention NSIndexPath, but in modern Swift you usually interact with IndexPath directly.

The idea is the same:

  • 'row is the table-oriented name'
  • 'item is the collection-oriented name'

If you are writing new Swift code, think in terms of IndexPath even when older discussions say NSIndexPath.

Why Using the Right Name Helps

This may sound cosmetic, but it improves code quality in larger codebases. When someone sees indexPath.row inside table view code, the intent is immediate. When someone sees indexPath.item inside collection view code, the same is true.

Using the control's own vocabulary reduces mental overhead.

A Practical Rule

Use this rule and you will almost never be wrong:

  • table view delegate or data source code: use row
  • collection view delegate or data source code: use item

If you are working with a generic helper not tied to either UI type, then either property may technically refer to the same position, but choosing the one that matches the call site is still better.

Common Pitfalls

The biggest pitfall is assuming row and item represent totally different coordinates. In normal list-style usage, they are usually two semantic names for the same position component.

Another issue is carrying table-view terminology into collection-view code or the other way around. It still might work, but it makes the code feel off and harder to read.

Developers also forget that section and position are separate concepts. The most common indexing bug is mixing up indexPath.section with indexPath.row or indexPath.item.

Finally, older NSIndexPath discussions can make Swift code look more confusing than it really is. In current Swift, IndexPath is the normal type to focus on.

Summary

  • Use indexPath.row with UITableView.
  • Use indexPath.item with UICollectionView.
  • In many cases they refer to the same stored position value, but the semantic name matters.
  • Modern Swift code uses IndexPath rather than focusing on NSIndexPath.
  • Match the property name to the UI component so the code stays readable.

Related reading
Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

All Rights Reserved.