“build disappears”

ACTUALLY doing #2 for every call is a terrible idea for both performance and coherence issues, but that means we're basically stuck trying to sort out when to reset, not if we're going to cache. I agree. IMO the problem is not that NSURL is caching the problem is the way it caches. The way it caches forces me to cache on top of it. The documentation claims it only caches for 1 run loop turn but as previously mentioned that is not always the case and certain values tend to get 'stuck.' Building a cache on top of NSURL resource values which may or may not be stale can cause all sorts of weird behavior if you don't call -removeCacheResourceValues so I can cache on the true value...but NSURL I assume makes its cache thread safe so -removeCacheResourceValues probably isn't so cheap. Doesn't that mean the url cache is costing me performance by requiring me to clear it to get to the true values I really want to cache? Huh. That's really weird. How did you construct those URLs? Originally the URL came throug

Future iOS/tvOS/macOS version may send SPC v3. There are no additional client-side requirements to trigger SPC v3. You cannot test SPC v3 today. Before official release of iOS it will be first available in beta builds. That will allow you to test your Key Server implementation and submit feedback.

Thanks for all the extra info. I have a couple of comments. [quote='877572022, dolfs, /thread/816619?answerId=877572022#877572022, /profile/dolfs'] I cleaned everything out manually. [/quote] How exactly? I try to avoid testing this stuff on my development machine because the constant build / run / debug cycle exposes edge cases that are rarely seen on normal user machines. I explain my standard approach for this sort of testing in Testing a Notarised Product. It’s discussing a different technology, but the general approach will work here. IMPORTANT Most VM apps don’t virtualise Wi-Fi, so you won’t be able to test the Core WLAN side of this. But you can test the Core Location side, and I think that’s what’s key here. [quote='877571022, dolfs, /thread/816619?answerId=877571022#877571022, /profile/dolfs'] Agent requests location authorization [/quote] Have you tried requesting location authorisation from the container app? That should work because the app is just a normal GUI application. And I’m hopin

I'm really desperate. My app ranks at the top across Europe, and in preparation for in-app purchases (donations), I changed my status to Trader. There was no warning that my apps would disappear from the stores, and support hasn’t been able to help. It just can’t be that Apple needs several days to verify an ID and, in doing so, causes massive financial and reputational damage to developers. I can hardly believe it.

I'm facing the same issue. I submitted my revised build for review on February 18th, and it's still at Waiting for Review. I don't have a clear picture of when the app will be reviewed, and I have to keep delaying my product launch. My first submission was on February 3rd.

Same here, I cannot download the container. I thought my app was broken then I realized the xcode version change caused it. Full error: The specified file could not be transferred. Domain: com.apple.dt.CoreDeviceError Code: 7000 User Info: { DVTErrorCreationDateKey = 2026-02-27 07:44:43 +0000; NSURL = file:///Users/cihadturhan/Downloads/xxx.xxx.xxx%202026-02-27%2010:44.28.643.xcappdata/AppData/Library/Caches/; } -- The specified file could not be transferred. Domain: com.apple.dt.CoreDeviceError Code: 7000 User Info: { NSURL = file:///Users/cihadturhan/Downloads/xxx.xxx.xxxx%202026-02-27%2010:44.28.643.xcappdata/AppData/Library/Caches/; } -- Failed to perform I/O operations. Domain: com.apple.dt.remoteservices.error Code: 11001 Failure Reason: Cannot open destination file /Users/cihadturhan/Downloads/xxxx 2026-02-27 10:44.28.643.xcappdata/AppData/Library/Caches/com.apple.dyld/xxx.dyld4: Permission denied -- System Information macOS Version 26.2 (Build 25C56) Xcode 26.2 (24553) (Build 17C52)

Thanks again for your guidance. I’m following up with concrete implementation details and current repro logs because we still cannot read SSID via CoreWLAN from our agent process. Environment: macOS 26.3 (build 25D125) Xcode 26.2 (17C52) Wi-Fi interface: en0 Agent bundle ID: com.acme.SSIDInspector.Agent App bundle ID: com.acme.SSIDInspector How we launch the agent: We use SMAppService.agent(plistName:) from the main app. Embedded LaunchAgent plist path in app bundle: com.acme.SSIDInspector.Agent.plist Plist details: Label = com.acme.SSIDInspector.Agent BundleProgram = Contents/Resources/SSIDInspectorAgent.app/Contents/MacOS/SSIDInspectorAgent MachServices includes com.acme.SSIDInspector.Agent RunAtLoad = true, KeepAlive = true We call register()/unregister() on SMAppService, and use XPC (NSXPCConnection to mach service) to verify the agent is running/reachable. Privacy/authorization setup: Agent Info.plist usage strings are present: NSLocationAlwaysUsageDescription NSLocationUsageDescription NSLocati

Splitting for length, part 1... I will also attach a sample crash report. So, let me start there. All three logs have threads blocked in dispatch_sync, with the worst case having 35 threads blocked in this code chunk waiting for another thread to clear the block: 6 libdispatch.dylib 0x7ff80f50468e _dispatch_sync_f_slow + 175 7 com.proofpoint.itm.prevention 0x10a102a81 8 com.proofpoint.itm.prevention 0x10a0ff5cb 9 com.proofpoint.itm.prevention 0x10a0ff482 10 com.proofpoint.itm.prevention 0x10a0c5716 11 libdispatch.dylib 0x7ff80f4f76b9 _dispatch_call_block_and_release + 12 The other two logs are that extreme, but both of them also show blocks in dispatch_sync and one of them also shows the same contentions (though not as extreme). I have some general comments below, but the critical next step here is to fully symbolicate these logs and figure out what your client is actually doing. You're clearly bottlenecking on something and figuring out what that is is obviously an important first step. I obviously don't kno