It looks like Xcode 16 has changed this behaviour so I'm not sure if this is a bug or not. When a SwiftUI Button wraps a UIImageView and the button style is .plain the button doesn't work without setting isUserInteractionEnabled. struct ContentView: View { var body: some View { Button { print("Hello World!") } label: { UITestImage() } .buttonStyle(.plain) } } struct UITestImage: UIViewRepresentable { func makeUIView(context: Context) -> UIImageView { let view = UIImageView() // view.isUserInteractionEnabled = true // Fix view.image = UIImage(systemName: "plus") view.contentMode = .scaleAspectFit view.setContentCompressionResistancePriority(.defaultLow, for: .horizontal) view.setContentCompressionResistancePriority(.defaultLow, for: .vertical) view.layoutMargins = .zero return view } public func updateUIView(_ uiView: UIImageView, context: Context) {} } This feels unexpected, is this a bug?

I can't seem to find information on this but this is causing a critical bug where the Strong Password suggestion sheet presents on any secure field (UIKit) and clears the others when closing it. This means the user cannot enter a password when there is a secure confirm password field because switching fields clears the other. This looks to be a recent issue but I can't tell when this was introduced or if this is SDK / OS version related. I am finding it in both Xcode 26.2 and 16.4 when running on device (iOS 26.2.1 and XC 26 simulators). Code to reproduce: class ViewController: UIViewController { override func loadView() { let v = UIStackView() v.axis = .vertical v.layoutMargins = .init(top: 16, left: 16, bottom: 16, right: 16) v.isLayoutMarginsRelativeArrangement = true view = v let t1 = UITextField() t1.textContentType = .username t1.placeholder = "Username" v.addArrangedSubview(t1) let t2 = UITextField() t2.isSecureTextEntry = true t2.textContentType = .newPassword t2.placeholder = "Password" t2.clearsOnInsertion = false t2.clearsOnBeginEditing = false t2.passwordRules = nil t2.clearButtonMode = .always v.addArrangedSubview(t2) let t3 = UITextField() t3.isSecureTextEntry = true t3.textContentType = .newPassword t3.placeholder = "Confirm Password" t3.clearsOnInsertion = false t3.clearsOnBeginEditing = false t3.passwordRules = nil t3.clearButtonMode = .always v.addArrangedSubview(t3) v.addArrangedSubview(UIView()) } } No matter what textContentType is used the strong password still forcefully breaks the flow and blocks the user.

I'm working on a large SDK of UI frameworks. We have hundreds of strings and an older implementation that resolves them by looking up the key in the main, then current (module) bundles. This allows clients to tailor strings and provide localisation for locales that we don't support. I want to move to String Catalogs and have a way of doing that with a similar solution using LocalizedStringResource. But this seems pointless as I would like to have client String Catalogs show all strings from dependencies (our UI frameworks). Stepping back a bit, the default API for LocalizedResources and Keys uses the main bundle and has bundle as a property but String Catalogs does not and cannot respect that (highlighted in this post). A possible Apple solution could be storing the module with the string in the String Catalog for that framework then the executable can correctly assess what strings it should include based on its dependencies String Catalogs. I am looking for a way around this? Or any suggestions? I believe it might be possible using a build tool plugin to generate the String Catalog for the clients from its dependency catalogs and this way I wouldn't need any trickery / can use the LocalizedResource API as is (main bundle).

I'm working on an AppIcon selector and would like to do something like UIImage(named: "AppIcon-Alternate") to present the icon for the user to choose using the new IconComposer icons. I've done a fair bit of research on this and it looks like this used to be possible (prior to .icon) with workarounds that were later 'fixed' / removed (appending 60x60 to the icon name). The only 'solution' seems to be bundling the exported images into the app itself but this seems like a terrible idea as it massively bloats the app. Assuming we export from the new IconComposer tool and want to include dark mode that's roughly 3MB per icon which is absolutely shocking bloat and so a terrible solution. Looking into the app the Assets.car actually generates png files for these alternate icons. These are in the json as "MultiSized Image" assets. Interestingly using UIImage(named: is actually attempting to load these but fails to resolve an kCSIElementSignature. Also the OS alert when switching alternate icon shows a preview of the icon so this must be privately possible and using Asset Catalog Tinkerer I'm able to see these pngs. This feels like broken API; I'd guess the new icon format is not correctly generating the entry in the Asset.car to link the generated pngs for usage with UIImage(named:) API. Does anyone have pointers for this? This feels like a developer API afterthought or bug but is it intentional? Edit: I've submitted feedback for this FB20341182.