iOS7 ChessGame UIChessboardView Design
@property (retain) id chessdelegate;


There are several things wrong with this line.


retain - While this technically still is a property attribute, it has been replaced by strong.  It does the exact same thing as strong, but strong is the vastly preferred term here.
retain or strong are both wrong here anyway.  Any delegate property should ALWAYS be weak or assign (and weak is better).  In almost every instance, the object server as a delegate already has a strong reference to the object with the delegate property.  If we create a strong reference back, we're creating a retain cycle and the memory will never be able to be deallocated.
id works as the type, technically, but we don't want to use that.  What we actually want is something that conforms to the protocol we've outlined.  We need to either forward declare the protocol, or probably better, just move the entire protocol definition before the class interface, and then change that type to id&lt;ChessboardViewDelegate&gt;.
chessdelegate - First, just delegate is more than fine.  Since we've changed the type to id&lt;ChessboardViewDelegate&gt;, we know what kind of delegate it is... the only reason to give the property a name more descriptive than just delegate is if the class has and needs more than one type of delegate.  AND, if you find yourself in this situation, please don't forget to camelcase the property.  But in the end, it should just be delegate.


So, here's what the line should actually look line:

@property (weak) id&lt;ChessboardViewDelegate&gt; delegate;




mouseDown, mouseUp, and click.  We're developing an iOS project, not OSX, right?  All iOS devices are touch devices.  Moreover, look at the UIView method you override: touchesBegan:withEvent:.  There is mouse in iOS and our method names should reflect that.



Now then, as for the actual meat of this review and your code, what are we actually looking at?

This is a UI element meant to represent a chessboard.  Apple is quite consistent with the Foundation classes in Cocoa Touch.  Classes, even unrelated classes, will have similarly named methods that provide similar functionality when it makes sense to do so.

Let's consider UITableView and UICollectionView for a moment (and I'm choosing these for a reason).  Look at the similarities between these objects--specifically, how their delegate/datasource methods work.

What does the actual view itself actually do?  It only does two things.  First, it asks its datasource for what it should draw at a particular index path (and then it takes care of displaying it).  Second, it receives the touch events, then calls a method on its delegate to give it an opportunity to respond to the touch event.

Remember when I said that we should rename the delegate to simply delegate and that the only reason it should be different is if you have multiple?  Well, it seems that in keeping with Apple's design for this sort of stuff, it makes sense that we would have both a delegate protocol and a datasource protocol, and as such, we should have a property for each:

@property (weak) id&lt;ChessboardViewDelegate&gt; delegate;
@property (weak) id&lt;ChessboardviewDatasource&gt; datasource;


Now, we the chessboard view detects a touch event, it lets the delegate know and give the delegate a chance to respond to this event.  Meanwhile, the chessboard should have a public method called reloadData (exactly as UITableView and UICollectionView have).  When this method is called, the chessboard view goes through a series of calls to its datasource to determine what to draw at each square.

The chessboard view itself can maintain some information like background image, background colors, how to draw the squares, borders, etc., and it can even have information for what a knight looks like or what a pawn or king, etc looks like, but it should call to a datasource to say "What occupies this square?" 64 times.  And with this in mind, it shouldn't even care about any of the chess rules.  If I want to put 64 black kings on the board, the chessboard view should be fine with it.

So here's how the program flow should work with this setup:


First, we load the chessboard.  Next, we "reload" data, this is the first time we call to the datasource.  We ask the datasource what the board position should look like.  This first call might be a new game of chess, or perhaps loading a chess puzzle, or loading a previously saved game.
Next, we wait for user input.  Once we have some user input, we call out to the delegate.  The delegate performs some logic.  Is this a valid move or not?  Do we need to calculate the AI's response to this move?  Anyway, the delegate is informed of the move that's attempting to be made.
Once we've determined the result of the attempted move, we update the data model, and we ask the chessboard view to reload.  We the view reloads via calling out to the datasource, which has updated data, so the board will be drawn differently, and we're back to step two of waiting for user input.  Step 2 and 3 repeat in a cycle until the logic in step 3 dictates that one player or the other has won.




What would make sense to accompany this class is an enum that accounts for all the possible square states.  Each square is limited to only a dozen-ish possible states:

typedef NS_ENUM(NSInteger, ChessboardViewSquareState) {
    ChessboardViewSquareStateUnoccupied,
    ChessboardViewSquareStateWhitePawn,
    ChessboardViewSquareStateWhiteRook,
    ChessboardViewSquareStateWhiteKnight,
    ChessboardViewSquareStateWhiteBishop,
    ChessboardViewSquareStateWhiteQueen,
    ChessboardViewSquareStateWhiteKing,
    ChessboardViewSquareStateBlackPawn,
    ChessboardViewSquareStateBlackRook, 
    ChessboardViewSquareStateBlackKnight,
    ChessboardViewSquareStateBlackBishop,
    ChessboardViewSquareStateBlackQueen,
    ChessboardViewSquareStateBlackKing
}


Now, your datasource has a method that asks for one of these values:

@required - (ChessboardViewSquareState)chessboardView:(ChessboardView *)chessboardView stateForSquare:(ChessboardSquare)square;


The chessboard view calls this method on the datasource.  It tells the datasource which chessboard is asking for the square state and what square it's asking about.  The datasource simply returns a value from the above enum.

Notice the similarity between this method and UITableView's datasource method:

@required - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath)indexPath;


Oh, and the ChessboardSquare data type I mentioned?  This could be an enum with 64 different values, but what I think is actually better is a struct of two enums.

typedef NS_ENUM(NSInteger ChessboardRow) {
    ChessboardRow1,
    ChessboardRow2,
    // etc... to 8

typedef NS_ENUM(NSInteger ChessboardColumn) {
    ChessboardColumnA,
    ChessboardColumnB,
    // etc...


typedef struct {
    ChessboardRow row;
    ChessboardColumn column;
} ChessboardSquare;




I think it would be very beneficial to spend a lot of time studying the delegate/protocol pattern and write some unrelated practice projects dealing with UITableView and UICollectionView and really completely understanding how these ui elements interact with the data model and controllers behind them.  

If I were writing this chessboard view, it'd be a UIView subclass, yes, but the view would have an 8x8 UICollectionView on it to serve as the chessboard.  It'd be the delegate and datasource to the collection view.  Now, when the collection view calls a delegate/datasource method on the ChessboardView, some of them the chessboard view can handle entirely on its own.  The rest it can handle mostly on its own, but it's going to call out to the Chessboard delegate/datasource to get the rest of the information concerning how it needs to display the board based on the current game state.