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.

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'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).