“build disappears”

[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.

I tested Xcode 26.5 beta 1 (build 17F5012f), released on 2026-03-30, and the issue remains unchanged: app-hosted unit tests still fail on the same physical iOS 16 device with Logic Testing Unavailable.

Thanks Quinn, that was exactly the right pointer. We traced through the disassembly of xzm_main_malloc_zone_init_range_groups on macOS 26.3.1 and correlated it with the open source in rel/libmalloc-792 (xzone_segment.c:1210-1250). Here's what we found: The CONFIG_MACOS_RANGES path computes: ptr_reservation_size = XZM_RANGE_SEPARATION + XZM_POINTER_RANGE_SIZE + XZM_RANGE_SEPARATION = 4G + 16G + 4G = 24 GiB ptr_start = 16GiB + (entropy % 736) * 32MiB It then calls mach_vm_map with VM_FLAGS_FIXED for 24 GiB at ptr_start. The 736 granules cover [16 GiB, 39 GiB), ensuring the reservation fits under the 63 GiB commpage limit. Why dylibs land above 16 GiB: The binary is a Chromium component-build test binary (browser_tests) that loads 516 Chromium dylibs plus system libraries (1543 images total). The main executable alone consumes 5.54 GiB of VA (4 GiB __PAGEZERO, 517 MiB __TEXT, 1.04 GiB __LINKEDIT). The 516 Chromium dylibs add another 10.19 GiB of aggregate VM (2.26 GiB __TEXT, 3.86 GiB __LINKEDIT). Combi