Apple’s GLKit framework for IOS 5 is a few objective-c classes that make it easier to program for OpenGL ES 2.0, especially when porting from OpenGL ES 1.1 applications to 2.0. OpenGL ES 2.0 of course is the new graphics API for creating pretty 3D scenes in mobile apps. What makes it particularly hard for developers to program in 2.0 is shader programming. The methods of graphics rendering or fixed-function pipeline in 1.1 has been completely removed and made programable in 2.0, requiring developers to write their own rendering codes in OpenGL shading language or GLSL; that is shader programming. Apple’s GLKit classes manage all the shader programming needed to render scenes in 2.0, so that the developers can eat-the-pie-without-baking-it. It is not such a bad idea except that shader programming is for customizing the rendering process and the main reason for switching to 2.0. If we are going to switch to OpenGL ES 2.0, we should learn shader programming, at least that is what I thought.
Obviously, GLKit is for IOS 5 and does not work in IOS 4. The framework methods are also very standard, mainly to ease the porting of 1.1 applications. GLKit has very few capabilities beyond what was defined in 1.1 that I suspect that Apple’s main reason for creating GLKit is to remove the support for OpenGL ES 1.1 in the future. These are all speculations. It is probable that Apple will improve GLKit defining more classes for volumetric shadows, bump mapping, refraction, and so on. If so, GLKit may be the future, extending its classes into future OpenGL ES API with new capabilities like tessellation. Developers of course have the option to choose third parties’ development kit, making GLKit framework an inefficient and redundant layer.