smb big sur

Apologies for the delayed update. Yesterday, we completed the rollout of your workaround solution, and our metrics indicate its effectiveness. The issue count has decreased significantly during the implementation, dropping from 6000 per day to 1000 per day as of today. Fabulous, that's great to hear and thank you for sharing concrete numbers. I was fairly confident it would work, but it's good to get independent confirmation. We would like to express our gratitude for the workaround solution you provided. You're very welcome. Currently, we have implemented the workaround only for incoming calls, as these were the primary source of issues observed in our app. We plan to extend the implementation to outbound calls as well. I don't know this for certain, but my guess is that the difference between the incoming/outgoing rate is mostly due to usage patterns and the details of your existing implementation. In particular, these two factors: I suspect most calls originate from the foreground (the user opening your ap

Code merged, now working on macOS 11. The next big thing will be arm64 support.

However, when opening Safari & scrolling through some webpages, the App is killed because of Terminated due to memory issue. I profiled the App & followed advice when it comes to reducing the memory footprint of the App. Are there any additional steps I can take to prevent the App being killed? To be honest, I think you're looking at this issue the wrong way. Terminating suspended apps to free memory is part of the system’s normal architecture, not necessarily a bug or problem. Similarly, reducing your memory usage is certainly valuable and appreciated, but it isn't really possible to reduce it to the point where the system will NEVER terminate your app. That's just not how the system works. Are there any recommendations for periodically scheduled Tasks when it comes to the Interval? Do more frequent Tasks (30min compared to one or two hours) have any impact? I tried many different schedules but none seem to make a difference. I wouldn't expect this to make much difference. That leads to here: Any hin

Hi Albert, Thank you for the links. After reviewing both documentation pages, I've implemented a complete test following the specifications, but password autofill is not working. Test Implementation AASA File (accessible at http://localhost:8080/.well-known/apple-app-site-association): { webcredentials: { apps: [ZW962TGA3F.com.test.PasswordAutofillTest] } } ✅ Served with Content-Type: application/json ✅ Verified accessible via curl ✅ Team ID matches Apple Developer account Associated Domains Entitlement: webcredentials:localhost:8080 ✅ Configured in both Debug and Release entitlements ✅ Bundle ID: com.test.PasswordAutofillTest SwiftUI Implementation: TextField(Email, text: $email) .textContentType(.username) SecureField(Password, text: $password) .textContentType(.password) Authentication Flow: App sends POST to http://localhost:8080/login with credentials Server returns 200 OK App displays Login successful Server logs confirm request received and processed Result ❌ No Save Password prompt appears ❌ No autofi

Sorry I didn’t reply sooner; older versions of DevForums had a bug that meant that I didn’t see updates on this thread (that’s fixed now, so yay!). [quote='785947022, Najjii, /thread/675290?answerId=785947022#785947022, /profile/Najjii'] edit the trust settings to be able to use it normally. [/quote] Monkeying with trust settings on a code-signing certificate is a bad idea. It can trigger the dreaded errSecInternalComponent. I talk more about this in Fixing an untrusted code signing certificate. [quote='794668022, olvrwn, /thread/675290?answerId=794668022#794668022, /profile/olvrwn'] Is there any information why this does not work with iCloud Keychain? [/quote] Not really. Keychain Access is very much on the way out as a user-level feature. Witness, for example, its recent move from Applications > Utilities to /System/Library/CoreServices/Applications. Given that, it’s easy to see why big picture issues like this aren’t being addressed. Having said that, the file-based keychain is also on its way

Thank you for all of that information Greg and for answering each query individually. That exception is being thrown because isMatchingFrameRateSupported is reporting false for your external display, but your AVCaptureExternalDisplayConfiguration specified true for shouldMatchFrameRate. What determines 'isMatchingFrameRateSupported'? I use the same USB Hub and External Display on a MacBook Pro and I can go to Settings -> Displays and change the resolution and frame rate. I tested 1920 x 1080 at 60fps, 50fps, 30fps and 25fps and they all work. When I use that exact same hardware on an M4 iPad Pro it returns 'false' for 'isMatchingFrameRateSupported', presumably iPadOS is limiting this? Great to know that I can use CAMetalLayer for this purpose. That would mean it could work for a Metal Backed Live Video Feed if I can get the display to work as per the above. Though I think given the limitation of this functionality to AVCaptureDevice and that it wouldn't be respected when the user plays back video from with

Also would love to be able to use Apple Music with my custom DJ apps. But looks like Apple only allows a few companies to have access to this feature putting all other developers in a great disadvantage and killing any chance to anyone else succeeding in this field. Its disappointing to see critical services like this be restricted just to a few picked developers instead on being open to everyone, another clear gatekeeping monopoly case that prevents any innovation in this field and is benefiting just a few companies. I've been trying this for years and only a big lawsuit can force them to be fair with all developers.

Update: I just tried replacing the child progress with a URLSessionDelegate that updates the progress completedUnitCount directly, and it seems to be more stable (but I only tried this once). Potentially a bug with using Child Progresses to keep alive BGContinuedProcessingTasks? Yes, that's very likely. This is something that should work, but there are also a lot of edge cases and details to cover. I expect this will improve over time; however, please file a bug on this and post the bug number back here. Having said that, my other question is what does the progress UI look like during this time? The primary purpose of progress here isn't to keep your app awake; it's to make sure the user knows what's going on. Similarly, I suspect the big problem here isn't that your task is expiring; it's that your progress bar isn't showing any progress! __ Kevin Elliott DTS Engineer, CoreOS/Hardware

So… there’s a lot to unpack here. The reason why kSecRevocationRequirePositiveResponse is causing you grief is that: The server’s certificate was issued by Let’s Encrypt. Let’s Encrypt has stopped supporting OCSP. You can learn about that directly from them in “Ending OCSP Support in 2025” [1]. Apple client’s don’t support CRLs directly. Apple clients learn about revocation via a separate path. My understanding is that we don’t document this path in detail. We did talk about it in WWDC 2017 Session 701 Your Apps and Evolving Network Security Standards [2], and I encourage you to watch that (start around 17:40). There have also been third-party folks who’ve dug into this in more detail [3] [4]. Of course, from Apple’s perspective all of these are implementation details, and we encourage folks to rely on APIs instead. Now, the issue here is that the APIs aren’t doing what you want. Before I go there, however, I want to clarify this bit: [quote='808875021, dhoelzl, /thread/808875, /profile/dhoelzl'] On the same

Does Finder's I/O behavior trigger specific SCSI command sequences or timing issues that CLI tools do not? Sort of. The difference here isn't caused by any fundamental difference between the Finder and “CLI tools“ - at the level you're interacting with, they're both just processes doing reads and writes. Indeed, ironically, I believe we moved copying out of process a few releases ago, so as far as most of the system can tell, the actual copying is occurring from very similar components. What is different is that they’re almost certain to have different I/O patterns. On the CLI side, I'd cp is using copyfile() and as are many of our higher-level APIs (notably, I believe NSFileManager has converted to it). On the other hand, the Finder uses its own copy engine both because it's older and because the details of its behavior are different than most APIs (for example, it preflights copies and uses VNOP_COPYFILE for smb copies). The big thing I'd keep in mind here is that the reason you tend to se

In general, the simulator uses the host’s TCP/IP implementation. So, for example, if you use URLSession to run a request in the simulator, that’ll use the simulator’s CFNetwork which uses the simulator’s Network framework which uses BSD Sockets which ends up in the host kernel. From there, the simulator looks like any other (big) BSD Sockets client. As to why it’s causing the host’s networking stack to fail, I’ve got no good theories. However, I suspect it’s somehow tied to your NE providers, because if this were failing in general there’d be a lot more grumbling. But that doesn’t mean that your NE providers are at fault. It could just as easily be a latent system bug that happens to be triggered by your NE providers. How reproducible is this? If you can reproduce it reasonably reliably, one option would be to replace your NE providers with simple ‘pass through’ versions. If the problem persists, then that’d form a good basis of a bug report. Alternatively, if that eliminates the problem then you hav