“smb big sur”

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]; } }

As I mentioned above, I’m a big fan of using GUI apps to explore installer packages. However, I think this is a case where it makes sense to use the command-line tools rather than an app, because that gives you a more direct view of what’s going on. I created a new test project, add a restricted entitlement to it, and then exported an App Store Connect installer package. This is what I see: % xar -xf Test788895.pkg % lsbom com.example.apple-samplecode.Test788895.pkg/Bom . 0 0/0 ./Test788895.app 40755 0/0 ./Test788895.app/Contents 40755 0/0 ./Test788895.app/Contents/Info.plist 100644 0/0 1582 981317462 ./Test788895.app/Contents/MacOS 40755 0/0 ./Test788895.app/Contents/MacOS/Test788895 100755 0/0 202608 1379559329 ./Test788895.app/Contents/PkgInfo 100644 0/0 8 742937289 ./Test788895.app/Contents/Resources 40755 0/0 ./Test788895.app/Contents/Resources/MainMenu.nib 100644 0/0 14262 622228364 ./Test788895.app/Contents/_CodeSignature 40755 0/0 ./Test788895.app/Contents/_CodeSignature/CodeResources 100644

Please file a bug about this specific case (system r/o NTFS driver blocks r/w FSKit driver) and then post that bug number back here. I have filed a bug: FB18230524 You might also try including -t nontfs. I haven't tried it, but I believe that would exclude the kernel NTFS driver while leaving yours as an option. It looks like mount (without -F) tries to use literal non-existent nontfs filesystem in this case: $ mount -t nontfs disk2s2 ./mnt mount: exec /Library/Filesystems/nontfs.fs/Contents/Resources/mount_nontfs for /Users/user/temp/fstest/mnt: No such file or directory mount: /Users/user/temp/fstest/mnt failed with 72 You ran mount as root, correct? I currently run mount as a normal administrator user (otherwise this workaround would need a helper with elevated privileges to be used in the app). However, I also attempted to run it as root. In that case the mount -F command fails without providing a specific error message. $ sudo mount -F -t abcd_ntfs disk11 ./mnt mount: Unable to invoke task # mount -F -t

Thanks for that crash report. We’ve definitely seen similar crash reports but they seem to be pretty uncommon, and I don’t see any indication that there’s been a big increase with macOS 15.5. Thread 3 of your crash report suggests that you’re using a custom crash reporter. I fundamentally mistrust such things, for the reasons I explain in Implementing Your Own Crash Reporter. Any chance I can convince you to remove it? Have you been able to reproduce this in-house? Or are you limited to crash reports coming in from the field? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I confirmed upon restore the sqlite file exists but sqlite-wal does not - it won’t open without that file. Correct. For context, WAL stands for Write-Ahead Logging and is part of the architecture sqlite uses to maintain data integrity. I guess/suspect that it's not be backed up because, assuming the database is being properly managed, it should generally be empty anytime it would have been backed up (because the contents were merged into the file at close/suspend). You can read more about it here: https://www.sqlite.org/wal.html But the critical point is: ...Beginning with version 3.22.0 (2018-01-22), a read-only WAL-mode database file can be opened if the -shm and -wal files already exist or those files can be created or the database is immutable. SO, basically, yes, what you're seeing is expected behavior. Shifting to the workaround side, I would to three things: (1) Implement a fallback there's a problem, open the app UI. It's likely that you've identified the primary (possibly only) issue here, but I'm a