Item vs NSIndexpath.row

You need to use indexPath.row

Difference is that:

indexPath.row is for tableView and indexPath.item is for collectionView.

item

An index number identifying an item in a section of a collection view. (read-only) @property (nonatomic, readonly) NSInteger item;

Discussion

The section the item is in is identified by the value of section. Availability

Available in iOS 6.0 and later.

Declared In UICollectionView.h

row

An index number identifying a row in a section of a table view. (read-only) @property(nonatomic, readonly) NSInteger row;

Discussion

The section the row is in is identified by the value of section. Availability

Available in iOS 2.0 and later.

Please check the NSIndexPath Additions for details

indexPath.row is best in your case

First info about NSIndexPath

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 between indexPath.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

>     Available in iOS 6.0 and later.

Okay, nobody has given a good answer here.

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.

Reference: NSIndexPath

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.

UICollectionView.h

@interface NSIndexPath (UICollectionViewAdditions)


+ (instancetype)indexPathForItem:(NSInteger)item inSection:(NSInteger)section NS_AVAILABLE_IOS(6_0);


@property (nonatomic, readonly) NSInteger item NS_AVAILABLE_IOS(6_0);


@end

UITableView.h

//_______________________________________________________________________________________________________________


// 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]

Functionally there is no difference:

var item: Int { row }

Semantically, row implies 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.