“build disappears”

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.' FYI, I think there are actually two different issues at work here: The run loop itself doesn't actually turn at a predictable rate. Depending on how your app is architected and the overall app state, it's entirely possible for an app to go seconds or even minutes without the main thread ever running. The documentation says that values are automatically removed after each pass through the run loop, but that's not quite accurate. NSURL is tracking the main loop activity through a runloop observer, but it doesn't actually flush the cache until the first time something tries to access that URL from the main thread. If nothing on the main thread accesses that URL, then it could theoretically return the old values forever. ...with #2 obviously being the most significant issue. Building a cache on top of NSURL resource values, which may or may not be

Odd because for me it's the opposite - the macOS build was approved in 36 hours and the iOS build is waiting for 18 days lol.

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