Good question. This is one of many things we have implemented, but are not in the 1.0 version of the public framework. Reasons include:

1. Unknown demand for such advanced optimizations make it hard to gauge value of spending time making those features available, vs investing in documentation, sample code, or other framework features.
2. Limited time (currently all the maintainers of ASDK are working on Instagram, which doesn't yet use ASDK, so seeing demand / interest in the framework will help us justify more time).

This feature is an example of one that needs to have a carefully thought-through API to make it useful and intuitive. Some mechanism of determining the "block size" (how much work to do per turn of the runloop), and supporting a wide variety of operations, is important but non-trivial. It's a solvable problem but would primarily help only the most complex apps—probably "top 5%" in terms of rendering complexity / hierarchy depth.

The technique does work equally well for removing subviews / sublayers and deallocating views / layers as it does for adding / creating them, but that degree of general applicability is one of the key qualities of the approach that makes it a little difficult to settle on the best API.

This is a great question / discussion for the Paper Engineering Community group if you want to cross-post the question there (I'll add this comment to the thread), particularly if you have further questions, which I'd be happy to answer.

wow!nice