AFAIK the reason that this isn't very common in the iOS community is that loading an image is often much faster (performance wise) than drawing a custom UI. What are your experiences with this?
Depends on size of image. The file system, while much faster than a spinning disk, is still slow enough that saving/loading large files (say, nearly-full-screen-sized) has a noticeable performance impact. Especially if you do it on the main thread (as people tend to do).
If this asset is nothing more than a gradient with some trimmings, it'll be substantially faster to just draw it. Also bear in mind that manual drawing in iOS is blisteringly fast.
You are right though - blitting a 32x32 icon to screen from a cached image is substantially faster than translating it from a vector format (say, an icon font). That being said, all of the iOS devices in common use today have a large amount of CPU performance headroom that makes this rather moot. We have absolutely no trouble hitting 60fps consistently drawing all of our own UI procedurally. Your main bottleneck is in your GPU's fill rate (and even then, only on the original iPhone 4), which limits the amount of overdraw/offscreen rendering you can do.
Some things in iOS-land are still slow. CALayer shadows for example are very slow if you use them directly out of the box (where they determine the visible mask of the layer and cast a shadow based on that). But they are very, very fast if you know the magic buttons to push (e.g., setting the shadow path to a fixed shape). Proceduralizing your entire UI definitely takes a bit of experience with Core Animation and Core Graphics.
The workflow gains we make, though, are massive. All of our iconography is vector-based, and all of our UI dynamically drawn. Need that button a different shade of green? Done. Need to change the depressed state of the button? Done. Icon a bit small? Done. Shadow should be a touch lighter? Done. We do take some performance loss for this, in theory, but since there is so much headroom it doesn't actually translate to a noticeably (read: sub-60-fps) degraded experience.
If this asset is nothing more than a gradient with some trimmings, it'll be substantially faster to just draw it. Also bear in mind that manual drawing in iOS is blisteringly fast.
You are right though - blitting a 32x32 icon to screen from a cached image is substantially faster than translating it from a vector format (say, an icon font). That being said, all of the iOS devices in common use today have a large amount of CPU performance headroom that makes this rather moot. We have absolutely no trouble hitting 60fps consistently drawing all of our own UI procedurally. Your main bottleneck is in your GPU's fill rate (and even then, only on the original iPhone 4), which limits the amount of overdraw/offscreen rendering you can do.
Some things in iOS-land are still slow. CALayer shadows for example are very slow if you use them directly out of the box (where they determine the visible mask of the layer and cast a shadow based on that). But they are very, very fast if you know the magic buttons to push (e.g., setting the shadow path to a fixed shape). Proceduralizing your entire UI definitely takes a bit of experience with Core Animation and Core Graphics.
The workflow gains we make, though, are massive. All of our iconography is vector-based, and all of our UI dynamically drawn. Need that button a different shade of green? Done. Need to change the depressed state of the button? Done. Icon a bit small? Done. Shadow should be a touch lighter? Done. We do take some performance loss for this, in theory, but since there is so much headroom it doesn't actually translate to a noticeably (read: sub-60-fps) degraded experience.