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?
Post
Replies
Boosts
Views
Activity
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).