NSIndexpath.item vs NSIndexpath.row
Interview Questions practice on Codemia
Over 8,000 real interview questions from top companies, searchable by company and role.
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.
Here row matches the table view API and reads naturally.
item in Collection Views
A collection view thinks in terms of sections and items.
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:
- '
rowis the table-oriented name' - '
itemis 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.rowwithUITableView. - Use
indexPath.itemwithUICollectionView. - In many cases they refer to the same stored position value, but the semantic name matters.
- Modern Swift code uses
IndexPathrather than focusing onNSIndexPath. - Match the property name to the UI component so the code stays readable.
Related reading
- NSInvalidUnarchiveOperationException Could not instantiate class named NSLayoutConstraint
- NSLayoutConstraint crashes ViewController
- NSLog on devices in iOS 10 / Xcode 8 seems to truncate? Why?
- NSNotificationCenter addObserver in Swift
- NSNotificationCenter addObserver in Swift
- NSOperation and NSOperationQueue working thread vs main thread
- NSOperation and NSOperationQueue working thread vs main thread
- NSOperation vs Grand Central Dispatch
.png&w=3840&q=75)
Tackling System Design Interview Problems
A short course that equips you with the skills to approach system design interviews methodically.
Start the free courseTrack 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.