Post not yet marked as solved
I recently created a prototype of a macOS app that embeds a large Rust library (Apache Arrow & DataFusion). The Swift side of the library can be seen at https://github.com/parquette/Parquette/tree/main/SwiftArrow/ and the Rust side is at https://github.com/parquette/arcolyte/ . The fully notarized universal app can be downloaded and run from https://github.com/parquette/Parquette/releases/ .
The process is that it builds the Rust library that exposes a primitive C FFI interface (via cbindgen). This is built as a static library (for both Intel & M1) and embedded in the Swift library, which enables it to be invoked directly via Swift's C language support (see the headers referenced by SwiftArrow.modulemap). These FFI bindings are tedious to write and maintain, since there are no Rust swift-bindgen tools (yet) to help you out. If you only need a coarse-grained interface to your Rust code like invoking the main() method and handing the return code, it shouldn't be too difficult to just call them directly from Swift.
There's a lot of little tricky moving parts to getting everything working together, so you may just want to fork the project as a starting point to see if your library can be embedded in the same way.
We've been seeing a similar issue, although 30-45 seconds is a crazy amount of time (our delays were on the order of a second or two, which is still far too slow). You might want to profile in instruments to see just what is taking all the time, or even just pause the debugger and grab a stack to see if there's anything suspicious there.One workaround we use is to just render the entire unfiltered list, and individually hide any rows that should be filtered. E.g., instead of:List(filtered, id: \.self) { (item: Name) in
NameListRow(item: item)
}You would do:List(names, id: \.self) { (item: Name) in
item.gender == self.selectedGender ? NameListRow(item: item) : nil
}Obviously this isn't a good general-purpose solution to filtering (since you wouldn't want to do it with millions of source rows where the filter would return only a handful), but if you are just switching between two sets of hundreds or thousands of records, rendering the whole thing and selectively hiding individual rows had made it much smoother for us.
It is frustrating that these depreactions don't include any helpful information on migrating. Everyone using the Scanner APIs is going to be going through this.Instead of doing this: var str: NSString?
if scanner.scanUpTo("***", into: &str) {
// do stuff…
}You should now do this: if let str: String = scanner.scanUpToString("***") {
// do stuff…
}
Post marked as Apple Recommended
For the record there appears to be no native way to set a tooltip on a SwiftUI view (feedback #FB7095924), but the following workaround seems to do the trick:public extension View {
/// Overlays this view with a view that provides a toolTip with the given string.
func toolTip(_ toolTip: String?) -> some View {
self.overlay(TooltipView(toolTip))
}
}
private struct TooltipView: NSViewRepresentable {
let toolTip: String?
init(_ toolTip: String?) {
self.toolTip = toolTip
}
func makeNSView(context: NSViewRepresentableContext) -> NSView {
let view = NSView()
view.toolTip = self.toolTip
return view
}
func updateNSView(_ nsView: NSView, context: NSViewRepresentableContext) {
}
}
Post not yet marked as solved
FWIW, if you make an empty subclass of NSStepper and use that from your custom NSViewRepresentable, then it seems to work without crashing on hover. E.g.:class MyStepper : NSStepper { }Of course, you'll have to implement the bindings support yourself, but at least it is a temporary workaround until this weird bug is fixed.
Post not yet marked as solved
Same here. It has been happening since beta4. Before that the Stepper() view worked fine.
