First notice that .m are Objective-C files (which can have both Objective-C and C) and .c are plain C files which can only contain C code. Both employ the .h extension for the header.
Regarding Objective-C, the .m file does @interface TileMapLayer() to declare a class extension. A class extension can add ivars and properties to a Class that was already declared in the .h file. An extension is only viewable from within its own .m file. It doesn't make much sense to declare an extension inside an .h file, but I guess you could if you wanted.
Regarding purpose, a recommended practice is declaring the minimum amount of properties needed in the .h in order to keep the interface lean and clean. For properties that are only needed inside the class, you can declare them in the extension on the .m file. My personal preference is to avoid explicitly declaring and using ivars at all (unless I'm overriding a property setter or getter), because that way on the implementation I can tell at first glance which variables are local to the function or object properties. The overhead is usually negligible and I prefer to code for readability than to prematurely optimize. With the recently introduced auto-synthesized properties this saves a lot of boilerplate code as well.
A strategy that I also recommend is thinking carefully which properties should be modifiable from outside the object or not. Declare the non-modifiable properties as readonly in the .h files. Then, you can re-declare them as readwrite in the .m extension for operations from the object itself. This ensures that you or your colleagues don't commit the mistake and modify a readonly property that is not supposed to change from outside the object. In a sense it helps you in keeping the logic of the object inside it. I would try to avoid the trap of declaring everything readwrite (the default), because then it usually comes to bite you back later.
