“build disappears”

Hi Quinn and those following along: The just released 26.5 beta (build 25F5042g) seems to - mostly - solve FB21858319 (After macOS reboots, multicast traffic might not be received by app even with Local Network permitted), what a relief! Now after a reboot, apps directly receive Local Network traffic, no need to toggle permission off and on or restart the app. I've tested a couple of apps across many reboots, seems to behave as expected. One issue (at least) remains: when multiple versions of the app coexist on a machine, the latest installed version won't receive Local Network traffic after macOS reboot until its socket is closed and reopened. The previously installed versions receive Local Network immediately, only the latest version needs a socket restart. It's already much more stable than previously (users had to toggle off and on the Local Network permission and restart the app for traffic to appear), we can now programmatically restart the socket and we're good. This looks more related to unre

[quote='882567022, WangZiYuan, /thread/817264?answerId=882567022#882567022, /profile/WangZiYuan'] But when I disable the content filter, the process does not stop. [/quote] OK. That’s not unexpected, give my understanding of how NE relates to the sysex infrastructure. [quote='882567022, WangZiYuan, /thread/817264?answerId=882567022#882567022, /profile/WangZiYuan'] When I manually kill the original process … the process ID definitely changes, but the issue persists. [/quote] Blat! I was hoping that the bogus state would be stored in the sysex process, and thus this would clear it. Given this finding, the only path forward I see is a bug report. [quote='880612022, kunal_a, /thread/817264?answerId=880612022#880612022, /profile/kunal_a'] I submitted FB19734992 [/quote] Thanks. I can’t go into all the details here, but the executive summary is: For internal reasons, we have an internal bug tracking the fix (r. 172870187). That fix is not in any currently released or seeded version of macOS. Even when that fix land

I’m not aware of any known issue that matches these symptoms. As you’ve noted, iOS is expected to preserve app group containers across OS and app installs. This certainly works for most apps and most users, but that doesn’t preclude there being a bug that causes this problem for some users of some apps. To investigate this we need to see a sysdiagnose log taken immediately after the user notices the problem. That’s gonna be tricky to acquire given that this problem isn’t obviously reproducible. I have a bunch of background on this in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. Key to that process is the ability to quickly and reliably identify that the problem has occurred. If I were in your shoes I’d add specific code for that, code that’s not tied to UserDefaults or Core Data. Both of those are big, complex subsystems, which makes it hard to know whether you’re hitting a problem with that subsystem or something more fundamental. Rather, I recommend that you store this state in files that y

I've hit a very similar issue with CoreML model loading hanging on the MLE5ProgramLibrary.lazyInitQueue after OS updates. A few things that helped me work around it: 1. Pre-compile to .mlmodelc instead of loading .mlpackage at runtime The AOT recompilation path (which is what's hanging) gets triggered when the on-device compiled cache is invalidated by the OS update. If you ship a pre-compiled .mlmodelc built with the matching Xcode/SDK version, it often skips recompilation entirely: // Compile once at build time or first launch let compiledURL = try MLModel.compileModel(at: mlpackageURL) // Then load from compiled let model = try MLModel(contentsOf: compiledURL, configuration: config) 2. Load on a background thread with a timeout Since the hang is on a serial dispatch queue and the C++ exception bypasses Swift error handling, wrapping the load in a Task with a timeout at least lets you fail gracefully instead of getting watchdog-killed: let loadTask = Task { try MLModel(contentsOf: modelURL, configu

Started to crash also on AppStore builds

I am an individual developer. I submitted my first app for review on March 14, 2026. It remained without a meaningful response until March 31, 2026. During this time, I sent three expedite review requests, but none of them helped. At the same time, I submitted my second app on March 22, 2026. I also requested an expedite review for that app, but it is still in Waiting for Review as well. Because nothing moved, I withdrew the previous submission and uploaded a third build for the same app. However, the app is still stuck in review flow. I am afraid you have done everything that one should not have done. You flood them with support and expedite request tickets. Yesterday, I read a topic where one claimed that he had sent about 20 support tickets to the company. You flood them with these tickets. I opened a support ticket several weeks ago after two of my apps were ready to distribute but were automatically removed from the store for no reason. I received a reply some two weeks ago where an Apple lady s

Has this been an issue for ten years? I am still in a rejection loop, can't see the IAP/Sub section in the version. After creating a new sub product, re-building to change the product code the IAP/Sub section appeared, I linked the sub product to the app, added new build submitted for review and the link went away and of course because the product wasn't approved with the binary the in app purchase can't ever work

Hi, App crashes on launch on iOS 26.3.1 after building with Xcode 26.4. dyld: Symbol not found: MetricKit.mxSignpost Works fine on iOS 26.4+. FB: FB22384135 Anyone else seeing this or any workaround? Thanks.