`-[UIView initWithFrame:] must be used from main thread only` kind of overkill.

Question

AntiMoron OP

Created Oct ’17

Replies 3

Boosts 0

Views 9.4k

Participants 3

XCode 9 Main thread chekcer gives me such warning:

-[UIView initWithFrame:] must be used from main thread only

Why I say this is overkill?

Apple's document says here:

The frame rectangle for the view, measured in points. The origin of the frame is relative to the superview in which you plan to add it. This method uses the frame rectangle to set the

center

and

bounds

properties accordingly.

Which it means, it just created an `NSObject` and set its `bounds` property and `center` property according to the parameter you set.

To be honest, it's completely safe when you create an object in any thread in objective-c. <`UIView` is subclass of `NSObject`>. Intrinsically creating an UIView is creating an NSObject defined in UIKit.
Also, views which are not in view hierarchy doesn't do any UI jobs by iOS. It's there just as a NSObject.
Even some may say that `UIView` needs to be in main thread to obtain its life cycle. But appearently it's been done in next update cycle and it's still in main thread, if the view was in view hierachy.

I don't get it why the main thread checker being so overkill.

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’17

I’m sorry but you are very wrong here. The API contract for UIKit is that (except for some specific documented exceptions) it’s a main-thread-only framework. You must not call it off the main thread. Even if that happens to work in the specific circumstances that you tested today, there’s no guarantee it will work in all circumstances, or that it will continue to work on future versions of the OS.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 2

AntiMoron OP

Oct ’17

hi eskimo, glad to see your reply. UIKit is a main thread only framework I totally agree that. I know iOS does lots of optimization on life cycles(laying out and rendering). But I want to challenge the API contract for UIKit: The UIView hasn't been added to view hierarchy yet, so neither laying out is done nor rendering. The view's just created and not been managed by iOS yet. Personally I think it's about memory management, main-thread doesn't write into this piece of memory which the view occupied. So I think that's why it should be safe. Since you are apple stuff, I know there may be some places I get it wrong, I'm eager to know more detail reasons about why this is not safe and banned in the API contract.

0

Answer 3

QuinceyMorris OP

Oct ’17

>> The view's just created and not been managed by iOS yet.

You don't know that. For example, it's not implausible that iOS might keep a list or other data structure of all views, whether or not they are added to the view hierarchy yet. If the maintenance of the list is not thread safe, creating views on a background thread could corrupt the data structure. (This is hypothetical, of course. I don't know any implemention details.)

>> I want to challenge the API contract for UIKit

The problem is that a contract is 2-way. As well as giving you a rule to follow ("don't do that!"), it frees Apple's engineers to do whatever they want within the boundaries, including things that are unintuitive to outsiders looking in. You can't predict what's safe.

The only protection you've got is the contract, which is why you must respect it.

0