To start with my answer, I would like to conclude that its totally your own design decision that whether you would use CGLayer
in your app or not.
The real thing is that if you are drawing something on-screen, it will possibly buy you nothing on iOS platform. On iOS, the basic screen composition block is a CALayer
. CALayer
takes a Quartz(CG) graphics context to draw that on screen and that might be a context created by CGLayer
itself. Now, CALayer
being hardware accelerated by itself, would try to cache any graphics content to graphics card and reuse them. And that's the purpose what we had used a CGLayer
previously.
Also, if offscreen rendering is concerned, a CALayer
can do that when shouldRasterize
is set to YES
and under some other circumstances. However, keep in mind that offscreen composition is again another task performed by CPU before handing over the rendered content to GPU. So again there is no clear winner.
CGLayer
would be particularly handy when creating a CG context that wont be drawn on screen, like a PDF context.
I'm not sure why Apple development team has asked one to avoid CGLayer
completely. Might be there are some underlying architectural flaw but that is undocumented, till date. However, until we are sure about that and we have existing apps designed over CGLayer
architecture, I dont find any specific reason to completely abandon that.