I wouldn't worry about what's displayed on the screen first - I'd think about what our objects are, what actions they perform, and what data access you need. Then figure out how to write those; then figure out how to display it.
It sounds like you have a Grid and some Blocks. The Grid object needs to store all of the blocks; when it's time to get touch controls working you'll want to ask questions like "what block is in position 1,1" and "what moves are available from 1,1", so the Grid object needs a way to answer that.
A simple way to so that is with a two-dimensional C array of pointers. Each grid square would have a pointer to the block in that square, or nil if there is no block.
Code:
struct gridPoint{
int x;
int y;
}
@interface Grid : NSObject {
Block* gridSquares[4][4];
}
//actions
-(void)addBlock:(Block*) block;
-(bool)moveBlock:(Block*) to:(gridPoint)point //use this to make the move, if it is valid
//data access
-(Block*)getBlockAt:(gridPoint) point; find the block at a point when touching
-(bool)isValidMove:(gridPoint) forBlock:(Block*)block //use this to find out if the move is valid after a drag or tap
@end;
Once you have these building blocks ready then you can create a scene with sprites and have it make calls into this "data model". The rules of the game will be in the data model, not your view/sprite code.