smb big sur

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.

Nothing to do with networking is ever “basic” |-: [quote='788567021, Cassian93, /thread/788567, /profile/Cassian93'] [what’s] the best way to take consenting users' Watch data from Apple Health Kit and send it to our central server? [/quote] The best approach depends on the networking protocol spoken by your server. Presuming it’s HTTPS, I generally recommend using URLSession directly from your app. URLSession supports two style of session: Standard sessions Background sessions A standard session is best for small amounts of data where latency is critical. A background session is best for situations where latency isn’t such a big deal, or where you have a lot of data to upload. URLSession is one of our better documented APIs. Start with URL Loading System. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The screens are both HDMI TV's, no USB hub. Interesting. How similar* are the two TVs? *Age, manufacturer, etc. The gap between these events is every 2-10 seconds. CGDisplayIsActive and Online returns true and Asleep returns false for all screen representations, physical or virtual. Huh. Further clarifying, what state is the machine tending to live in? In other words, which screen is it claiming to be attached to most of the time (while the display is off)? Also, the big question here is still this: Is the machine supposed to be asleep? __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Just wanted to check here to see if anyone else is running into the issue of CarPlay not working at all on iOS 26 Beta 1, even with the update on Friday. I plug my phone in (wired) and CarPlay never shows up. I've seen a Reddit thread where other folks are seeing the same thing. Have you filed a bug on this and, if so, what is the bug number? One thing to keep in mind here is that whether or not other people are experiencing a given issue doesn't actually matter when it comes to file bugs on our beta seeds. If think* you're experiencing a problem, then you should file a bug. That's true if you're the only person who seems to be having a given problem or if you find lots of people on the internet complaining about the problem. That's because, among many other reasons: It's entirely possible for a variety of unrelated problems to present the same way at the end user level. Even if EXACTLY the same problem is happening on all devices, it's entirely possible that the specific circumstances and details are very di