Thread safety of UIImage

Question

I know that Apple officially recommends UIKit to be used in the main thread only. However, I\'ve also heard claims that UIImage is thread-safe since iOS 4.0. I cannot find

Answer 1

It looks like Apple have updated their documentation since the earlier answers here were posted. According to the most up-to-date documentation, it is safe to create and use UIImage instances from any thread:

Because image objects are immutable, you cannot change their properties after creation. Most image properties are set automatically using metadata in the accompanying image file or image data. The immutable nature of image objects also means that they are safe to create and use from any thread.

https://developer.apple.com/reference/uikit/uiimage

Answer 2

Directly from Apple's documentation for UIImage

Image objects are immutable, so you cannot change their properties after creation. This means that you generally specify an image’s properties at initialization time or rely on the image’s metadata to provide the property value. It also means that image objects are themselves safe to use from any thread. The way you change the properties of an existing image object is to use one of the available convenience methods to create a copy of the image but with the custom value you want.

(Emphasis mine)

So at least in the current version of the SDK as of May 13, 2014, "image objects are themselves safe to use from any thread."

Answer 3

In the What's New in iOS: iOS 4.0 release notes, the UIKit Framework enhancements include this bit:

Drawing to a graphics context in UIKit is now thread-safe. Specifically: The routines used to access and manipulate the graphics context can now correctly handle contexts residing on different threads. String and image drawing is now thread-safe. Using color and font objects in multiple threads is now safe to do.

So UIImage is thread-safe on iOS 4.0 and later.

Answer 4

Thread-safe is not the issue, in that any thread can attempt to access a context at the same time (concurrently). And, while that is generally okay, in low-memory situations, like with a Photo Editing Extension on iOS devices, two threads accessing one context can crash an app due to low memory.

This happens when mixing Core Image filters with vImage operations. Both are thread-safe, but ARC will not release vImage buffer data before processing a Core Image object, so you have at some point two copies of an image in memory.

Accordingly, you never consider your knowledge of thread safety to be complete without understanding of threading and concurrency—and that goes double for any answer to questions about thread safety. In short: the proper question is, how does thread-safety apply to memory usage, whenever you're talking about image processing.

If you're just kicking the tires here, you need to wait to pose your question until you've encountered a real problem. But, if you're planning your next move, you need to know how to execute image processing commands sequentially, and with manual deallocation. You must design your app so that there is only one copy of the image being processing in memory. Never rely on automatic deallocation—thread-safe or not—to make that call for you. IT WILL NOT WORK.

Answer 5

Just to make it short: UIImage is not thread safe, or better does only work on the main thread, as I have experienced in my current after some debugging.

I hope that helps. I wish to have more clarity about this from Apple or even better an UIImage class, that could be rendered in a different thread. Shouldn't be too difficult ...

edit: After some research, I found that it is "UIGraphicsGetImageFromCurrentImageContext();" that causes the trouble. it's a bit off the topic, but maybe this helps: https://coderwall.com/p/9j5dca

Thanks to Zachary Waldowski.

Answer 6

It is true that apple recommends using elements from the UIKIt on the main thread:

Note: For the most part, UIKit classes should be used only from an application’s main thread. This is particularly true for classes derived from UIResponder or that involve manipulating your application’s user interface in any way.

Since UIImage isn't derived from UIResponder, and you do not actually display it on the interface/screen. Then doing operations with UIImages on another thread should be safe.

This is however based on my experience, I haven't seen any official documentation about it.