Insufficient API to Efficiently Support Wrapping UIKit Views with Double Layout Pass Requirements for SwiftUI Recent Similar Reports:None Resolution:Open Basic Information Please provide a descriptive title for your feedback: Insufficient API to Efficiently Support Wrapping UIKit Views with Double Layout Pass Requirements for SwiftUI

Originator:bryn.bodayle
Number:rdar://FB9718086 Date Originated:10/21/21
Status:Open Resolved:
Product:SwiftUI Framework Product Version:iOS 15
Classification:Incorrect/Unexpected Behavior Reproducible:Always
 
Certain views in UIKit required a double layout pass in order to size correctly. The most common of these views is a multiline UILabel which needs a first layout pass to determine its max available width, and then a second layout pass in order to determine its height given that width. To make this work with AutoLayout, UILabel uses special flags which give it a double layout pass.

We are looking to wrap UILabel using `UIViewRepresentable` in order to continue using special views with a double layout pass requirement in SwiftUI. We are using a generalized wrapper for UIKit views we wish to expose to SwiftU. We have to use a GeometryReader in order to make a double layout pass and then are required to measure the UIView twice, once in each layout pass. We'd like to avoid this extra code complexity and the negative performance impact of these measurements and layout passes when possible.

Could SwiftUI provide a more effective method for supporting UIKit views that require a double layout pass? It seems like SwiftUI could use its knowledge of the available size provided to a view in order to set the preferredMaxLayoutWidth of the UILabel on the first layout pass.

After some Googling it appears that other developers are encountering this limitation.

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!