Safe from the Losing Fight

This is a quick write-up of an unexpected SwiftUI limitation I encountered recently. In my own searching, I couldn’t find it documented anywhere so I’m hoping this post will help someone in the future.

Problem summary

You can’t wrap a UIView in SwiftUI’s UIViewRepresentable if that UIView changes its intrinsicContentSize based in its frame width, because UIViewRepresentable will ignore invalidateIntrinsicContentSize(). As a result, the UIView will have its height clipped.

To make it a bit more concrete, imagine you have a UIView that draws multiline text that can line wrap. UILabel would be an example. If you were to adjust the label’s frame width, it would reflow the text and the intrinsic content height would change to reflect that.

During SwiftUI layout, what UIViewRepresentable does is ask the UIView for its intrinsic content size before it has set the UIView‘s frame. It then takes the minimum of the available size from the superview and the UIView‘s intrinsicContentSize, and sets that as the UIView‘s frame. This causes the UIView to reflow the text and invalidate its intrinsic content size. UIViewRepresentable ignores this, and as a result the UIView is clipped too short.

You can find a simplified version of this bug using UILabel on Github.

Investigation

I tried many suggestions from Stack Overflow, and override any size or layout related UIView method that I could. None of the suggestions worked, and almost none of the UIView methods were ever called during layout. I felt I was probably missing something obvious, so I filed a Developer Tech Support incident with Apple to get an official answer. My submission is summarized in the Github repo.

Results

Here’s the official response from Apple:

Hello Andy,

Thank you for contacting Apple Developer Technical Support (DTS). We have reviewed your request and have concluded that there is no supported way to achieve the desired functionality given the currently shipping system configurations.

If you would like for Apple to consider adding support for such features in the future, please submit an enhancement request via Feedback Assistant (https://feedbackassistant.apple.com). For more information on Feedback Assistant, please visit https://developer.apple.com/bug-reporting/.

While a Technical Support Incident (TSI) was initially debited from your Apple Developer Program account for this request, we have assigned a replacement incident back to your account.

Best Regards,

Developer Technical Support
Worldwide Developer Relations
Apple, Inc.

According to the response this is expected behavior, so any change would an enhancement request. I have since filed the enhancement request as feedback FB8499811.

Moment of Zen

I have the exact same view on macOS as an NSView wrapped up in an NSViewRepresentable. It works great. When the NSView invalidates its intrinsic size, NSViewRepresentable re-queries the intrinsic size and updates the frame appropriately.

I guess someone already filed that enhancement request.

I’ve been meaning to write about some of the major problems that I have with the App Store, both the Mac and iOS varieties. But honestly, I don’t have a whole lot to add to what Wil Shipley and Craig Hockenberry have already said. Instead, I’ll link to the bugs I’ve written up, and encourage you to do the same.

• The App Stores need to support upgrade pricing. rdar://11131356 or Open Radar

• The App Stores need to support free trials. rdar://11133210 or Open Radar

• The App Stores need to support tracking statistics. rdar://11133330 or Open Radar

• The App Stores need better discoverability of apps. rdar://11133573 or Open Radar

I know there’s been a lot of pessimism about writing up Radars lately, including from yours truly. But the truth is filing bugs is the only official way Apple will listen, so the pragmatic side of me wins out. It’s not that I necessarily think filing bugs will cause a change, but it’s the only possible way of affecting changing that’s been given to me.

Recently Apple has been closing a lot of Radars with the response of:

We are closing this bug since our engineers are aware of the issue and will continue to track it.

This baffles me for a couple of reasons:

1. Isn’t the point of Radar (a bug database) to track issues that you’re aware of? If not in Radar, how are Apple engineers tracking them? Storing them in /dev/null?

2. Of course your engineers are aware of the issue, I freakin’ told them about it.

So I’m not sure what Apple means by this response. Word on the street (by which I mean Twitter, since we engineers certainly don’t go outside, much less into the street), is that it’s supposed to be a “polite” way of saying “we’re not going to fix it.” But I’m not sure why they wouldn’t just say “it works as intended”, which is what they used to say, or simply “it will not be fixed.” Have engineers gotten more sensitive over the years and Apple is afraid of rejecting them, fearing Foxconn style suicides? (Note to Apple: if I sign an affidavit stating my office is only one story high, will you tell me the real reason why the bug is being closed?)

Regardless, Apple is already so opaque when giving feedback about bugs, that a lot of engineers have given up filing bugs in the first place. Apple doesn’t seem to grasp that we’re doing them a favor by telling them where their bugs are. Radars seem to be treated more as an annoyance, than as valuable feedback.

But my main problem with “our engineers are aware of the issue” response is it’s very unclear what Apple’s trying to say. Even if they rejected the bug report in the past, even if it was for a lame reason, you knew where it stood and could do a minimal amount of tracking of it via the Radar. But now there’s not even that.

So to get to the bottom of this issue, and to increase the chances of irony, I’ve filed a Radar (Bug # 10777677, non-Apple people see OpenRadar). I’ll let you know if Apple engineers are aware of the problem and if they’ll continue to track it.