Apple's ImageIO and UIKit use lazy decoding.

CGImage is lazy, not a data which hold memory buffer. It query the pixel buffer using callback (not like Android Bitmap or other things you familiar)

A CGImage can be created with CGDataProvider, which can provide the callback to access underlying pixel buffer (a 2-dimension array). So this not means the data must be always in memory (surprise ?)

See: https://developer.apple.com/documentation/coregraphics/cgdataprovidergetbytescallback?language=objc

So, ask yourself:

If CGImage is lazy, when UI render on screen (this happended on main queue), will this effect frame rate ?

For JPEG and PNG, the lazy cause the decoding happened on main queue, but iPhone or iPad's hardware-accelerate codec is fast enough, so it's OK

But for WebP/HEIC, this is not quite enough, especially for low model like iPhone 11 before. It use software codec.

So, this is why we introduce the force decode, force the lazy to become non-lazy in the background queue, then render on screen does not trigger decoding at all.

But force decode will also allocate pixel buffer in the background queue before rendering, so this will pre-allocate memory, and may contains more memory footprint.

In previous 10 years (iOS 4-iOS 14), UIKit team hide this internal detail, but this indeed effect performance. We provide the choice to you.

In iOS 15, UIKit team finally provide the public API to do force decode as well, see: https://developer.apple.com/documentation/uikit/uiimage/3750834-preparingfordisplay