The NSIndexPath class represents the path to a specific node in a tree of nested array collections. This path is known as an index path.
Each index in an indexPath represents the index into an array of children from one node in the tree to another, deeper node.
For example, the indexPath 1.4.3.2 specifies the path shown in Figure
Here in your case indexPath.row returns the index of the row at the specific indexPath.
Differences betweenindexPath.row and indexPath.item
Generally indexPath has two properties
1 - row
2 - item
row - property use with UITableView for get specific row base on indexPath.
it is also read only property
Available in iOS 2.0 and later.
item - properly use with UICollectionView for get item in section.
It is a read-only property. To use this property you need to declare it in UICollectionView.h
Inside NSIndexPath, the indexes are stored in a simple c array called "_indexes" defined as NSUInteger* and the length of the array is stored in "_length" defined as NSUInteger. The accessor "section" is an alias to "_indexes[0]" and both "item" and "row" are aliases to "_indexes[1]". Thus the two are functionally identical.
In terms of programming style – and perhaps the definition chain – you would be better using "row" in the context of tables, and "item" in the context of collections.
@Owen Godfrey's answer is better than the accepted answer from @iPatel. Here is some further clarification which I wasn't able to fit into a comment on his answer, so I'll copy his answer and add to it here. Credit belongs to Owen.
From @Owen Godfrey:
Inside NSIndexPath, the indexes are stored in a simple c array called "_indexes" defined as NSUInteger* and the length of the array is stored in "_length" defined as NSUInteger. The accessor "section" is an alias to "_indexes[0]" and both "item" and "row" are aliases to "_indexes1". Thus the two are functionally identical.
In terms of programming style – and perhaps the definition chain – you would be better using "row" in the context of tables, and "item" in the context of collections.
The core interface of NSIndexPath is defined in NSIndexPath.h. The storage of the indexes is in _indexes which is a private one-dimensional array of NSUInteger. NSIndexPath by itself can represent any number of dimensions. There are two relevant categories on NSIndexPath which extend the functionality, one from UICollectionView.h "NSIndexPath (UICollectionViewAdditions)" and one from UITableView.h "NSIndexPath (UITableView)". The one from UICollectionView.h adds the readonly property "item" and related convenience methods. The one from UITableView.h adds the readonly property "row" and related convenience methods. However both properties are just wrappers that access the underlying value in _indexes[1].
Since UIKit links with both categories, both sets of convenience functions are always available, no matter where in IOS you are using them. So you could create an NSIndexPath from [NSIndexPath indexPathForRow:inSection:] but retrieve the second index from indexPath.item. The underlying value is exactly the same whether accessed by indexPath.item or indexPath.row.
Stylistically it is cleaner if you use "item" with UICollectionView and "row" with UITableView as that is how they were intended to be used, and this makes for more readable code. However your program won't crash if you interchange them.
Look at the bottom of UICollectionView.h and you will see the category that extends NSIndexPath to add item as a property when used within for UICollectionView instances.
There is a similar section at the bottom of UITableView.h which adds row and section properties for NSIndexPaths that are used in UITableViews.
If you are trying to access these properties of an NSIndexPath instance within a class and the NSIndexPathInstance doesn't believe they are there, just import the header of the class that defines them into the top of your class and you will magically be able to access these properties.
//_______________________________________________________________________________________________________________
// This category provides convenience methods to make it easier to use an NSIndexPath to represent a section and row
@interface NSIndexPath (UITableView)
+ (instancetype)indexPathForRow:(NSInteger)row inSection:(NSInteger)section;
@property (nonatomic, readonly) NSInteger section;
@property (nonatomic, readonly) NSInteger row;
@end
To use these properties within your class you'll have to import the desired one into your class like so:
@import "UIKit/UITableView.h"
And then you can do things like: myIndexPath.row and [myIndexPath row]
Semantically, rowimplies that cells are spatially arranged in a list (unlike item), so Apple wants you to use item when you work with collection views. Mind the difference:
A table is always a list: it arranges cells in sections and rows.
A collection is often a list or a grid, but it also accepts custom developer layouts with arbitrary arrangements. e.g. you can place cells at random on screen if you like.
My 2¢: Since the underlying data structure (section, row) is the same for tables and collections, sticking to that terminology would have prevented this confusion.