smb big sur

Hi, We were successfully able to mount an SMB network share using its IPv6 address. We tried mounting SMB via Finder as well as NetFSMountURLSync and it worked. How is SMB mount working?

Thanks. Sure, I just meant that it seems a little unclean to have a temporary file on a volume that is not controlled by the OS and could potentially be lying there forever if the volume is disconnected in the middle of the operation. There's a forum post I did here about the choice between using the directory returned by url(for:in:appropriateFor:create:) vs creating your own user-visible directory, but the bottom line is that there isn't really any single, right answer to this question. You're going to leave data behind if the operation is interrupted, and you have to decide whether it's better to: Make things seamless by minimizing user involvement, but risk orphaning data in ways that aren't necessarily visible to the user. Complicate the experience by making what you're doing visible to the user. The right choice here depends entirely on the details of the product you’re building. I'm going to be using URLResourceKey.volumeSupportsFileCloningKey to determine if cloning is available and use clonefile in t

I am working on an app (iOS, iPadOS & macOS (Mac Catalyst)) for a Home Automation device. I am using HomeKit APIs to access commissioned devices and provided APIs to get a MatterNodeID and then a MTRBaseDevice so I can query the device. Since the current APIs for accessing Matter devices this way do not support subscriptions, I am using the readAttributes() method of the MTRBaseDevice to get information from the device. There can be significant lag time in these reads, and I realize my network speed and congestion can contribute to this. What are the final endpoints you're interacting with and, in particular, are they using Thread? On top of the fixed cost (more on that shortly), Thread accessories tend to increase latency. Part of that is that extra layer of the thread bridge and lower bandwidth, but most of that is that the accessory itself, particularly for things like battery-powered sensors or buttons. In concrete terms, there is a pretty big performance spectrum between: A wall-powered Matt

First off, a warning on ANY usage of URL.path() and string-based paths in general. Basically, the existence of string paths in our API is a fundamental design mistake we made 25+ years ago and have been paying for ever since. The issue isn't all that visible because actually relying on normalization sensitivity is a fairly terrible idea, not because the system actually handles this case properly. In addition, there are places in our API like file iteration where the path variant is MUCH worse than the URL equivalent. In any case, I recommend avoiding string paths wherever possible. Kevin, this is helpful information. Just to make sure I'm reading you correctly, is it a valid approach to copy the file into your sandboxed app directory (e.g. the app's documents folder) to Quick Look, and then remove it once you're done with Quick Look? Yes, but with the qualifiers: Things get a lot more complicated if/when you're crossing volumes, something which isn't necessarily obvious without a lot of additional checking. Y

Oof, as much as I'd like to, migration to Swift/SwiftUI is just not practical at this time. Our application is very big with a lot of distinct parts (think Xcode but with more parts) so this is not trivial to do even if it's one file at a time. I've got a team working on porting the Windows MFC version of our application to .NET and they've been working on it for 3 years and still aren't done! Our application is available for Windows, Mac, and Linux and one of the nice things about ObjC is that it can be mixed in with C/C++ code which makes writing multiplatform code very easy. I did look at perhaps writing all new GUI code in Swift a few years ago when it first came out but had problems with the ObjC and Swift bridging and gave up as I had more pressing things to work on.

So, before everything else, I think the big question that needs to be clarified here is how exactly the user is most really going to interact with your app and documents. In particular, questions like: How many documents is a typical user likely to have and how long is that document likely to last? How should the results of searching at the system level compare to searching at the app level? Looking at the documentation for CSImportExtension, it appears that this is for gathering & updating information about a file, not the items in the file. The extension only gets one CSSearchableItemAttributeSet that is for metadata about the file. I think we need to step back and approach this in terms of two separate problems: System-wide search In-app search As far as a system-wide search is concerned, I think you need to use CSImportExtension. The reason for that is actually this: The extension only gets one CSSearchableItemAttributeSet that is for metadata about the file. Files come and go all the time, a

It’s certainly possible, but probably more hassle than it’s worth. Specifically, Swift supports compiling to WebAssembly (Wasm) [1] and you could then run the Wasm instructions yourself. However, this is much more difficult than the equivalent path with JavaScriptCore because: JavaScriptCore can interpret JavaScript directly. In Swift you’d have to include a copy of the Swift compiler within your app. Additionally, there’s no built-in Wasm runtime, so you’d have to write or acquire one of those. Of these, the second point is less of an issue. Wasm runtimes are relatively small and easy to maintain. Indeed, there’s a default one featured on the Swift website [2]. The first point, however, is much more complex. The Swift compiler is big and complicated, and successfully embedding it in an iOS app would not be trivial. Finally, there’s the App Review side of this. I don’t work for App Review, and thus can’t make definitive statements on their behalf. However, the App Review Guidelines do place restricti

Thanks. Sure, I just meant that it seems a little unclean to have a temporary file on a volume that is not controlled by the OS and could potentially be lying there forever if the volume is disconnected in the middle of the operation. I'm going to be using URLResourceKey.volumeSupportsFileCloningKey to determine if cloning is available and use clonefile in that case, and otherwise use filecopy to copy the file to the system temporary directory and then copy it from there to the actual destination volume. The latter may be a problem if it's a big file for which the system volume has not enough free space, but in that case the user should just disable checksum calculation in my app.

Just to follow up — when you mention good coverage for regions, could you please clarify what exactly defines good coverage? Region monitoring is primarily driven by WiFi location data, which has three consequences (one of which is less obvious). It works pretty well when WiFi density is fairly high. That obviously includes most urban environments, but also tends to include most residential areas (since home WiFi networks are common). It doesn't work well when WiFi density is low/non-existent. There are some special cases for things like users’ home* but, in general, region monitoring doesn't work well in rural environments, wilderness, etc. (less obvious) The nature of WiFi location data means that it can fail in weird/unexpected ways. *There are on-device heuristics which track broad usage patterns which are then used to improve things. So, the home location, for example, is something like the WiFi network the device is connected to for ~8-12 hours a day, ~8+ of which are idle (because the user is asleep).

using a function for autoresizing works... in the future what do you suggest me? using swift and objc both, rewritter is too big project -(void)fixAutoResizingForSubviews:(UIView *)parent { // 19/06/2025 Simone per ios26 for (UIView *sub in parent.subviews) { if (sub == barMenu) { sub.autoresizingMask = UIViewAutoresizingFlexibleWidth; // No flexibleHeight } else { sub.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight; } [self fixAutoResizingForSubviews:sub]; } }