smb big sur

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

However, since the default NTFS read-only driver is already present in macOS, this introduces an additional challenge. 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. While the basic behavior (prioritizing KEXTs over FSKit) is reasonably justifiable and difficult to address, I think the specific issue around r/o NTFS is important (and narrow) enough that we might want to consider a special cased solution. So, the proper solution (using DiskArbitration) seems to be blocked architecturally Note that there is also a bug in DiskArb that is preventing FSKit volumes from working correctly. See this thread for more details. This leaves mount -F as the only means to mount the NTFS volume via FSKit. 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. However, even that doesn't work for volumes on real (non-RAM) disks due to permission iss

After multiple testing of my solution above I ran into other issues (that occur on iOS 18.0 no matter if this fix is in place or not). A view is pushed back after I pop from it. Any help would be greatly appreciated. It might be because I am using @Environment(.dismiss) var dismiss but the app is too big to completely break it apart just because Apple broke the navigation of SwiftUI in iOS 18.0. Guess I have to accept it and show some message to users on this specific iOS version.

Perhaps you may be able to get at the data you're interested in by extracting the NSBitmapImageRep from your NSImage and accessing the data you want in there. Yes, I can do that, but then I'm not sure whether I'm dealing with big-endian or little-endian data, whether alpha is first or last, maybe even whether the data is 16 bit or floating-point, so it's a pain. The trouble with vImageUnpremultiplyData_ARGB8888 is that unpremultiplying is a lossy operation. In the extreme case, if the alpha value is zero, you have no idea what the original RGB values were.