“build disappears”

Hello RanLearns, Please create a bug report on Feedback Assistant to send us sysdiagnose logs. Once you open the bug report, please post the FB number here for my reference. The sysdiagnose should be generated shortly after the build of your app has terminated, even if the logs can't be synced off the device until later. Important: Note the date and time the issue occurred and include this information with your sysdiagnose. This information is vital in helping us pinpoint the issue being captured in the sysdiagnose log file. For information on generating and retrieving a sysdiagnose click the link below and choose the appropriate platform from the search results: https://developer.apple.com/bug-reporting/profiles-and-logs/?name=sysdiagnose A sysdiagnose may be too large to send in e-mail. If you don't have the ability to send large files, let us know so that we can send you instructions for our Box account. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why

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

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