Overview

We're seeing a sporadic crash (~2-3% of spawns) when launching a large Mach-O binary via posix_spawn(). The crash happens inside libsystem_malloc.dylib during __malloc_init, before any application code runs. The process never reaches main(). Environment: macOS 26.3.1 (25D2128), Apple Silicon (ARM64) Crash signature BUG IN LIBMALLOC: pointer range initial reservation failed, Abort Cause 3 #0 libsystem_malloc.dylib: xzm_main_malloc_zone_init_range_groups.cold.1 #1 libsystem_malloc.dylib: xzm_main_malloc_zone_init_range_groups #2 libsystem_malloc.dylib: xzm_main_malloc_zone_create #3 libsystem_malloc.dylib: __malloc_init #4 libSystem.B.dylib: libSystem_initializer #5 dyld: dyld4::Loader::findAndRunAllInitializers The binary It's a Chromium component-build test binary (browser_tests): ~1.5 GiB on disk, 5.54 GiB total VA footprint (__TEXT 517 MiB, __LINKEDIT 1.04 GiB, __PAGEZERO 4 GiB) Links 527 dylibs via @rpath All images span ~16.4 GiB of VA when loaded A simple loop that spawns this binary 200 times via posix_spawn() reliably shows 2-5 crashes. Spawning /bin/cat 1000 times produces zero failures. Investigation We did extensive analysis to understand the root cause: ASLR is irrelevant. We disabled ASLR using _POSIX_SPAWN_DISABLE_ASLR (flag 0x0100) and the failure rate is unchanged (~2% with or without). With ASLR disabled, the library addresses are identical across all crashes, confirming the VA layout itself isn't the problem. Plenty of free VA space is available. We compared the memory layout of crashing processes (from crash reports) with successful ones (via vmmap): In successful spawns, XZone places its MALLOC zones (SMALL, LARGE, metadata) in the large free regions after the loaded dylibs — for example at 0x784400000 and 0xD32000000, with 13-22 GiB contiguous free gaps available. In crashing processes, the same free regions exist (the image layout is identical), but xzm_main_malloc_zone_init_range_groups fails to reserve into them. Based on libmalloc/tests/memory_pressure.c, XZone needs 8 GiB for pointer ranges and 10 GiB for data ranges. The free gaps after the dylibs are far larger than this, yet the reservation sporadically fails. No workarounds exist. MallocNanoZone=0 has no effect (the crash is before zone configuration). The crash is entirely within system code. Questions Is this a known issue in XZone malloc on macOS 26.x? Is there any environment variable or entitlement that could work around this? Any guidance on what makes xzm_main_malloc_zone_init_range_groups fail non-deterministically when contiguous VA space is clearly available?

Hi everyone, I am experiencing an unusual delay with my app update. I submitted version 1.0.3 of my app, "MarketNow", on March 12, 2026, but it has been stuck in the "Waiting for Review" status for 9 days now. Typically, updates are reviewed within 24–48 hours, so this 9-day wait is quite concerning. I have already sent a formal inquiry through App Store Connect but haven't received a specific update yet. Is anyone else seeing long wait times for updates this week? Could this be related to a backlog before the April SDK deadline, or is there a known issue with the Finance category review queue? Any insights would be helpful. Thanks!

Hello everyone, I’m looking for some clarification and advice regarding an unexpected App Review rejection under Guideline 4.1 – Copycats. My app has been live on the App Store since May 2024, and during that time, it has maintained the same core flow, structure, UI, and feature set. There have been no major redesigns or attempts to imitate any other app. Recently, I submitted a new version (v3.2) with only minor changes related to ad logic implementation (no UI/UX changes, no branding changes, no metadata changes). However, this update was rejected with the following reason: “This app or its metadata appears to be misrepresenting itself as another popular app or game…” This has left me quite confused for a few reasons: The app has been approved and publicly available for nearly 2 years There were no significant design or branding changes in this submission The rejection seems unrelated to the actual changes made in this version My questions: Has anyone experienced a situation where an app was flagged as a copycat after being live for a long time? Is it possible that Apple updated their internal policies or comparisons, causing older apps to be re-evaluated? Could this be triggered by similar metadata (keywords, screenshots, descriptions) rather than the app itself? What would be the best way to respond in App Store Connect Resolution Center in this case? I fully respect Apple’s guidelines and have no intention of copying or misleading users. I’d really appreciate any insights or suggestions on how to resolve this properly. Thank you!

Note: This document is specifically focused on what happens after a DEXT has passed its initial code-signing checks. Code-signing issues are dealt with in other posts. Preliminary Guidance: Using and understanding DriverKit basically requires understanding IOKit, something which isn't entirely clear in our documentation. The good news here is that IOKit actually does have fairly good "foundational" documentation in the documentation archive. Here are a few of the documents I'd take a look at: IOKit Fundamentals IOKit Device Driver Design Guidelines Accessing Hardware From Applications Special mention to QA1075: "Making sense of IOKit error codes",, which I happened to notice today and which documents the IOReturn error format (which is a bit weird on first review). Those documents do not cover the full DEXT loading process, but they are the foundation of how all of this actually works. Understanding the IOKitPersonalities Dictionary The first thing to understand here is that the "IOKitPersonalities" is called that because it is in fact a fully valid "IOKitPersonalities" dictionary. That is, what the system actually uses that dictionary "for" is: Perform a standard IOKit match and load cycle in the kernel. The final driver in the kernel then uses the DEXT-specific data to launch and run your DEXT process outside the kernel. So, working through the critical keys in that dictionary: "IOProviderClass"-> This is the in-kernel class that your in-kernel driver loads "on top" of. The IOKit documentation and naming convention uses the term "Nub", but the naming convention is not consistent enough that it applies to all cases. "IOClass"-> This is the in-kernel class that your DEXT attaches to and works through. This is where things can become a bit confused, as some families work by: Routing all activity through the provider reference so that the DEXT-specific class does not matter (PCIDriverKit). Having the DEXT subclass a specific subclass which corresponds to a specific kernel driver (SCSIPeripheralsDriverKit). This distinction is described in the documentation, but it's easy to overlook if you don't understand what's going on. However, compare PCIDriverKit: "When the system loads your custom PCI driver, it passes an IOPCIDevice object as the provider to your driver. Use that object to read and write the configuration and memory of your PCI hardware." Versus SCSIPeripheralsDriverKit: Develop your driver by subclassing IOUserSCSIPeripheralDeviceType00 or IOUserSCSIPeripheralDeviceType05, depending on whether your device works with SCSI Block Commands (SBC) or SCSI Multimedia Commands (SMC), respectively. In your subclass, override all methods the framework declares as pure virtual. The reason these differences exist actually comes from the relationship and interactions between the DEXT families. Case in point, PCIDriverKit doesn't require a specific subclass because it wants SCSIControllerDriverKit DEXTs to be able to directly load "above" it. Note that the common mistake many developers make is leaving "IOUserService" in place when they should have specified a family-specific subclass (case 2 above). This is an undocumented implementation detail, but if there is a mismatch between your DEXT driver ("IOUserSCSIPeripheralDeviceType00") and your kernel driver ("IOUserService"), you end up trying to call unimplemented kernel methods. When a method is "missing" like that, the codegen system ends up handling that by returning kIOReturnUnsupported. One special case here is the "IOUserResources" provider. This class is the DEXT equivalent of "IOResources" in the kernel. In both cases, these classes exist as an attachment point for objects which don't otherwise have a provider. It's specifically used by the sample "Communicating between a DriverKit extension and a client app" to allow that sample to load on all hardware but is not something the vast majority of DEXT will use. Following on from that point, most DEXT should NOT include "IOMatchCategory". Quoting IOKit fundamentals: "Important: Any driver that declares IOResources as the value of its IOProviderClass key must also include in its personality the IOMatchCategory key and a private match category value. This prevents the driver from matching exclusively on the IOResources nub and thereby preventing other drivers from matching on it. It also prevents the driver from having to compete with all other drivers that need to match on IOResources. The value of the IOMatchCategory property should be identical to the value of the driver's IOClass property, which is the driver’s class name in reverse-DNS notation with underbars instead of dots, such as com_MyCompany_driver_MyDriver." The critical point here is that including IOMatchCategory does this: "This prevents the driver from matching exclusively on the IOResources nub and thereby preventing other drivers from matching on it." The problem here is that this is actually the exceptional case. For a typical DEXT, including IOMatchCategory means that a system driver will load "beside" their DEXT, then open the provider blocking DEXT access and breaking the DEXT. DEXT Launching The key point here is that the entire process above is the standard IOKit loading process used by all KEXT. Once that process finishes, what actually happens next is the DEXT-specific part of this process: IOUserServerName-> This key is the bundle ID of your DEXT, which the system uses to find your DEXT target. IOUserClass-> This is the name of the class the system instantiates after launching your DEXT. Note that this directly mimics how IOKit loading works. Keep in mind that the second, DEXT-specific, half of this process is the first point your actual code becomes relevant. Any issue before that point will ONLY be visible through kernel logging or possibly the IORegistry. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Hello all Synopsis: document based SwiftData app breaks document handling after first save due to internal error saving the -shm file. Long: i am working on a small document based SwiftData app for macOS. The UI works well as long as the document was not saved. After saving the document and reopening it, I get an error consistently in console: BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: /Users/vrunkel/Library/Containers/de.ecoobs.CurtailmentAnalyzer/Data/tmp/TemporaryItems/NSIRD_CurtailmentAnalyzer_mrXKMs/NewDocument/StoreContent-shm So somehow the -shm file is still referenced to NewDocument created when the app opens an untitled document and resides in the temporary folder. I have saved the document to my documents folder. After reopening and the above error deletion or addition of items crashes the app with a long backtrace to view updating: Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread. I am not creating any threads or do background work. If I do not save the document but work within the new untitled document no problems occur. Even closing the app and reopening the untitled new doc (happens automatically) all is fine. To rule out any influence of my existing view structure I have created the most simple test case - Xcode -> New Project -> macOS document based app configured to use SwiftData. Same behaviour. After saving a new document the addition/deletion of items causes the thread-induced crash and shows the error in console when opening the document. I am using latest versions of Xcode 15.0 and macOS 14.0 Any ideas? thx, volker

Thanks all for reading my post. A bit of context: We just finished an app transfer to our developer account. We successfully signed and generated the new release. We are already able to roll it out in testflight were we found an issue. We store valuable data in the Keychain like Authentication tokens, once the new app is installed over the old one we are experiencing a loss of all data as the keychain become "untrusted". This is worst case scenario for us because all users will immediately lose the access to the app and hence the whole system. Questions: Is there a way to solve this issue, something like migration of the Keychain data? We came to know the standard migration path: Release a version that copies items from the old access groups to a new group based on com.apple.security.application-groups (App Groups). Wait for most users to update and run the migration. Then perform the App ID prefix change. Is this still the best method? Any improvements or new tools available since the 2022 DTS post? The problem with this is that the app is already on our account and that might need to rollback the transfer. Right? How long should we realistically wait for user migration before making the prefix change? Is there a way to measure migration completion? Thank you in advance!

Hola, compre el 25 de marzo la membresía de desarrollador, pero aun mi cuenta sale pendiente, no subo datos de empresa ya que soy freelance. Cuanto podría tardar la aprobación de la cuenta. Ya mande dos ticket a soporte pero nada responden

When launching an app, AppStore Connect has some very specific requirements to the media (screenshots) used for the store listing. Right now the primary screenshots requires a 6.5 inch size. This is fine, of course, but why doesnt it list which iphones has this size, so I dont have to google my way to this answer? Its such a small thing, but would help so much

20 days passed since I released the app. According to Trends it has 30+ installs and 10 In-App purchases. When will I finally get analytics? Can't wait to see it, because I'm actively promoting my app and I wish to know the marketing performance. All that I see now in App Store Connect is this message: Other apps have no signs of this issue, I assume that the analytics is missing because the app is new. The question is "when"? :)

DTS regularly receives questions about how to preserve keychain items across an App ID change, and so I thought I’d post a comprehensive answer here for the benefit of all. If you have any questions or comments, please start a new thread here on the forums. Put it in the Privacy & Security > General subtopic and tag it with Security. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" App ID Prefix Change and Keychain Access The list of keychain access groups your app can access is determined by three entitlements. For the details, see Sharing Access to Keychain Items Among a Collection of Apps. If your app changes its App ID prefix, this list changes and you’re likely to lose access to existing keychain items. This situation crops up under two circumstances: When you migrate your app from using a unique App ID prefix to using your Team ID as its App ID prefix. When you transfer your app to another team. In both cases you have to plan carefully for this change. If you only learn about the problem after you’ve made the change, consider undoing the change to give you time to come up with a plan before continuing. Note On macOS, the information in this post only applies to the data protection keychain. For more information about the subtleties of the keychain on macOS, see On Mac Keychains. For more about App ID prefix changes, see Technote 2311 Managing Multiple App ID Prefixes and QA1726 Resolving the Potential Loss of Keychain Access warning. Migrate From a Unique App ID Prefix to Your Team ID Historically each app was assigned its own App ID prefix. This is no longer the case. Best practice is for apps to use their Team ID as their App ID prefix. This enables multiple neat features, including keychain item sharing and pasteboard sharing. If you have an app that uses a unique App ID prefix, consider migrating it to use your Team ID. This is a good thing in general, as long as you manage the migration process carefully. Your app’s keychain access group list is built from three entitlements: keychain-access-groups — For more on this, see Keychain Access Groups Entitlement. application-identifier (com.apple.application-identifier on macOS) com.apple.security.application-groups — For more on this, see App Groups Entitlement. Keycahin access groups from the third bullet are call app group identified keychain access groups, or AGI keychain access groups for short. IMPORTANT A macOS app can only use an AGI keychain access group if all of its entitlement claims are validated by a provisioning profile. See App Groups: macOS vs iOS: Working Towards Harmony for more about this concept. Keychain access groups from the first two bullets depend on the App ID prefix. If that changes, you lose access to any keychain items in those groups. WARNING Think carefully before using the keychain to store secrets that are the only way to access irreplaceable user data. While the keychain is very reliable, there are situations where a keychain item can be lost and it’s bad if it takes the user’s data with it. In some cases losing access to keychain items is not a big deal. For example, if your app uses the keychain to manage a single login credential, losing that is likely to be acceptable. The user can recover by logging in again. In other cases losing access to keychain items is unacceptable. For example, your app might manage access to dozens of different servers, each with unique login credentials. Your users will be grumpy if you require them to log in to all those servers again. In such situations you must carefully plan your migration. The key thing to understand is that an app group is tied to your team, not your App ID prefix, and thus your app retains access to AGI keychain access groups across an App ID prefix change. This suggests the following approach: Release a version of your app that moves keychain items from other keychain access groups to an AGI keychain access group. Give your users time to update to this new version, run it, and so move their keychain items. When you’re confident that the bulk of your users have done this, change your App ID prefix. The approach has one obvious caveat: It’s hard to judge how long to wait at step 2. Transfer Your App to Another Team Historically there was no supported way to maintain access to keychain items across an app transfer. That’s no longer the case, but you must still plan the transfer carefully. The overall approach is: Identify an app group ID to transfer. This could be an existing app group ID, but in many cases you’ll want to register a new app group ID solely for this purpose. Use the old team (the transferor) to release a version of your app that moves keychain items from other keychain access groups to the AGI keychain access group for this app group ID. Give your users time to update to this new version, run it, and so move their keychain items. When you’re confident that the bulk of your users have done this, initiate the app transfer. Once that’s complete, transfer the app group ID you selected in step 1. See App Store Connect Help > Transfer an app > Overview of app transfer > Apps using App Groups. Publish an update to your app from the new team (the transferee). When a user installs this version, it will have access to your app group, and hence your keychain items. WARNING Once you transfer the app group, the old team won’t be able to publish a new version of any app that uses this app group. That makes step 1 in the process critical. If you have an existing app group that’s used solely by the app being transferred — for example, an app group that you use to share state between the app and its app extensions — then choosing that app group ID makes sense. On the other hand, choosing the ID of an app group that’s share between this app and some unrelated app, one that’s not being transferred, would be bad, because any updates to that other app will lose access to the app group. There are some other significant caveats: The process doesn’t work for Mac apps because Mac apps that have ever used an app group can’t be transferred. See App Store Connect Help > Transfer an app > App transfer criteria. If and when that changes, you’ll need to choose an iOS-style app group ID for your AGI keychain access group. For more about the difference between iOS- and macOS-style app group IDs, see App Groups: macOS vs iOS: Working Towards Harmony. The current transfer process of app groups exposes a small window where some other team can ‘steal’ your app group ID. We have a bug on file to improve that process (r. 171616887). The process works best when transferring between two teams that are both under the control of the same entity. If that’s not the case, take steps to ensure that the old team transfers the app group in step 5. When you submit the app from the new team (step 6), App Store Connect will warn you about a potential loss of keychain access. That warning is talking about keychain items in normal keychain access groups. Items in an AGI keychain access group will still be accessible as long as you transfer the app group. Alternative Approaches for App Transfer In addition to the technique described in the previous section, there are a some alternative approaches you should at consider: Do nothing Do not transfer your app Get creative Do Nothing In this case the user loses all the secrets that your app stored in the keychain. This may be acceptable for certain apps. For example, if your app uses the keychain to manage a single login credential, losing that is likely to be acceptable. The user can recover by logging in again. Do Not Transfer Another option is to not transfer your app. Instead, ship a new version of the app from the new team and have the old app recommend that the user upgrade. There are a number of advantages to this approach. The first is that there’s absolutely no risk of losing any user data. The two apps are completely independent. The second advantage is that the user can install both apps on their device at the same time. This opens up a variety of potential migration paths. For example, you might ship an update to the old app with an export feature that saves the user’s state, including their secrets, to a suitably encrypted file, and then match that with an import facility on the new app. Finally, this approach offers flexible timing. The user can complete their migration at their leisure. However, there are a bunch of clouds to go with these silver linings: Your users might never migrate to the new app. If this is a paid app, or an app with in-app purchase, the user will have to buy things again. You lose the original app’s history, ratings, reviews, and so on. Get Creative Finally, you could attempt something creative. For example, you might: Publish a new version of the app that supports exporting the user’s state, including the secrets. Tell your users to do this, with a deadline. Transfer the app and then, when the deadline expires, publish the new version with an import feature. Frankly, this isn’t very practical. The problem is with step 2: There’s no good way to get all your users to do the export, and if they don’t do it before the deadline there’s no way to do it after. Revision History 2026-03-31 Rewrote the Transfer Your App to Another Team section to describe a new approach for preserving access to keychain items across app transfers. Moved the previous discussion into a new Alternative Approaches for App Transfer section. Clarified that a macOS program can now use an app group as a keychain access group as long as its entitlements are validated. Made numerous editorial changes. 2022-05-17 First posted.

There does not appear to be any way to use or create iCloud passkeys with a Safari Web Extension, either using the navigator.credentials API in an extension origin webpage such as the popover, or using the AuthenticationServices framework in the SafariWebExtensionHandler. I've setup an associated domain for my plugin, and I know it works for the host application. But I get errors trying to do so in the web extension target. createCredentialRegistrationRequests results in the following error: Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Application with identifier <ID> is not associated with domain <RPID> The other problem, assuming the entitlement works correctly for the web extension, is that there is no NSWindow to use as the presentation target from the SafariWebExtensionHandler. Trying to use the navigator.credentials.create JS API (which is the preferred method, frankly, in a web extension) results in the following error: NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. Chrome has a great solution for this that I believe should be adopted by Safari. If an extension has host permissions for a relying party it wants to claim, or if it has an associated domain entitlement for it, webauthn operations should be allowed.

I have purchased membership for personal use to see how publishing app works. The cost was taken from the credit card I had given. but when i check my account its still reflecting the same "Purchase your membership" and ask me to purchase again

Hello My app got rejected with the message "We noticed your app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences." In short, my app is a vpn app built entirely by me. In Russia almost all vpn protocols are blocked: wireguard, openvpn etc. And the only protocol they could not block was vless. It was hard to implement it, i spent like 3 weeks on it writing my own package on flutter. The app first was uploaded to android and shared through testflight with some of my friends. And everyone switched to my app, because it works perfect for their needs: accessing instagram, twitter etc. Those apps are blocked here. So on my first attempt publishing i got 2 errors: Vpn should be published on the account that is organization Spam rejection I registered a company and switched from individual account to a company. I also changed the ui of the app (although i agree most vpns share the same concept design). I got rejected again with only "Guideline 4.3(a) - Design - Spam". I appealed with a question why was it it rejected, explaining that the app was built by me, and of course, i use some libraries. I got the same roboting response. After that i added some features: Built in private browser Network connection speed Today submitted the new version hoping it would pass, but yet again got "Guideline 4.3(a) - Design - Spam". I'm really frustrated, because i spent 3 months developing the app. I understand there are dozens of vpns. But vpn is not exactly the simple feature app. Some are bad, some are good, and some doesn't work at all. My app doesn't have any ads and paid subscriptions. I also renamed my app to "Incognito - Browser, VPN". But can't get pass. Would like to get some advices. Please help P.S. Sorry for my bad grammar

When using a ScrollView inside some sort of navigation (stack or split view), large navigation titles seem to get clipped to the width of the scroll content for some reason? Minimal example: struct ContentView: View { var body: some View { NavigationStack { ScrollView { Text("Scroll Content") } .navigationTitle("Navigation Title") } } } Results in: Is this a bug in the beta, or has something changed and now I’m doing things wrong?

I’m developing an app that includes a navigation bar with a centered title and a single right bar button item. I’ve noticed that when both the navigation bar title and the right bar button item’s title are relatively long, the navigation bar title becomes hidden. This issue only occurs on iOS 26. When running the same code on iOS 18, the layout behaves as expected, with both elements visible. Has anyone else experienced this behavior on iOS 26? Is this a known layout change or a possible bug?

Hi everyone, I am an iOS developer from Ecuador and I am writing to ask if there's any way to fix my issue. After some initial struggling with my phone number not being able to receive Apple verification messages, I was able to register an Apple ID and use that Apple ID to enroll into the Apple Developer Program. Currently, I am stuck at the step of paying the subscription fee. When I try to pay for the 99$ enrollment fee, I receive an "Order Acknowledgement" e-mail from Apple but the payment is never processed. I have tried with multiple debit cards: 2 times with my main crypto debit card emitted from a Hong Kong bank 1 time with a debit card emitted from a local Ecuadorian bank 1 time with a debit card emitted from a US bank In all these cases the result is the same: the same order acknowledgement e-mail but nothing more happens. I even tried asking the support via e-mail (the only method that is supported in my country), but no one replies. Does anyone have any tip on how to overcome this situation?

Hello, I am facing a critical technical blocker regarding the Family Controls (Screen Time API) entitlement for my app extensions. Current Situation: My parent app (com.hayashikento.FocusPact) is already approved for the Family Controls (Distribution) entitlement. However, the associated DeviceActivityMonitorExtension (com.hayashikento.FocusPact.FocusPActMonitor) and ReportExtension (com.hayashikento.FocusPact.ReportExtension) are still pending entitlement approval. Technical Issue: Because the extensions lack the Distribution entitlement, ManagedSettings and DeviceActivity triggers (like intervalWillEndWarning) are ignored by the system when testing via TestFlight or in a non-development environment. As a result, I am unable to verify the core "automatic re-blocking" logic and "usage reporting" features in a real-world scenario. This has completely halted the final QA and TestFlight phase of my project. Requests: Could an Apple engineer verify if these extension IDs can be linked to my existing approved parent app entitlement? Is there a specific process to expedite the "linking" of extensions when the main app is already authorized? App Details: Parent App Bundle ID: com.hayashikento.FocusPact Extension IDs: com.hayashikento.FocusPact.FocusPActMonitor, com.hayashikento.FocusPact.ReportExtension Apple ID (App)6759132649 I have already submitted the web request forms, but the lack of synchronization between the parent app and extensions is preventing my MVP launch. Any assistance would be greatly appreciated. Thank you.

Hello. Our application performs encoding and decoding of large json files which sometimes may take up to 1,5GB of RAM memory. We understand that this may be a problem for devices with low RAM memory (3GB). But before iOS 26.4 we didn't have much occurrences (3 for the last 90 days). Starting from iOS 26.4 it started to crash a lot. Can the reason be that iOS 26.4 occupies more RAM memory so there is less memory left for our app? Or maybe starting from iOS 26.4 there is less RAM memory allocated per app? The crash message is Fatal error: failed to allocate 392 bytes of memory with alignment 8

After iOS app overlay installation widget process killed OSLaunchdJob | handle= start succeeded, info=spawn failed, error=111: Invalid or missing Program/ProgramArguments,widget kill and liveactivity dismiss ，infomation ： 默认 chronod [com.jd.jinrong.JDJRWidget] Creating session... 默认 chronod [DFB1D11C]: activityHandler ended 默认 iconservicesagent [0x5e2812320] activating connection: mach=false listener=false peer=true name=com.apple.iconservices.peer.0x5e2812320 默认 runningboardd <OSLaunchdJob | handle=DCD4DC2C-32B3-4340-94F7-72C8C150F82C>: start succeeded, info=spawn failed, error=111: Invalid or missing Program/ProgramArguments 错误 runningboardd Process start failed with Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed} 默认 runningboardd <OSLaunchdJob | handle=DCD4DC2C-32B3-4340-94F7-72C8C150F82C>: remove failed with error 144 Requestor lacks required entitlement 错误 runningboardd Job remove after failed start failed with Error Domain=OSLaunchdErrorDomain Code=144 "Requestor lacks required entitlement" UserInfo={NSLocalizedFailureReason=Requestor lacks required entitlement} 错误 runningboardd Launch failed with Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed} 默认 runningboardd Executing launch request for xpcservice<com.jd.jinrong.JDJRWidget([osservice<com.apple.chronod>:2892])> (Launching extension com.jd.jinrong.JDJRWidget(BFEC114A-32BF-4A62-97F3-8B0C3FE6AB70) for host 2892) 默认 runningboardd Checking PreventLaunch: global:0 exPath:(null) predicates:(null) allow:(null) 默认 runningboardd Skipping preflight as <RBSLaunchRequest| xpcservice<com.jd.jinrong.JDJRWidget([osservice<com.apple.chronod>:2892])>; "Launching extension com.jd.jinrong.JDJRWidget(BFEC114A-32BF-4A62-97F3-8B0C3FE6AB70) for host 2892"> is not an app 默认 runningboardd Creating and launching job for: xpcservice<com.jd.jinrong.JDJRWidget([osservice<com.apple.chronod>:2892])> 默认 runningboardd <OSLaunchdJob | handle=3BD97E17-E46A-41F7-B794-520044BCD36D>: submitExtension created a job 默认 runningboardd <OSLaunchdJob | handle=3BD97E17-E46A-41F7-B794-520044BCD36D>: createInstance created a job <OSLaunchdJob | handle=3B5CA561-A268-4A5C-BAFF-819801EB4465> 默认 runningboardd <OSLaunchdJob | handle=3B5CA561-A268-4A5C-BAFF-819801EB4465>: start succeeded, info=spawn failed, error=111: Invalid or missing Program/ProgramArguments 错误 extensionkitservice RBSLaunchRequest error launching extension com.jd.jinrong.JDJRWidget error: Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0xca4d04aa0 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}} 错误 runningboardd Process start failed with Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed} 默认 runningboardd <OSLaunchdJob | handle=3B5CA561-A268-4A5C-BAFF-819801EB4465>: remove failed with error 144 Requestor lacks required entitlement 错误 runningboardd Job remove after failed start failed with Error Domain=OSLaunchdErrorDomain Code=144 "Requestor lacks required entitlement" UserInfo={NSLocalizedFailureReason=Requestor lacks required entitlement} 错误 runningboardd Launch failed with Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed} 错误 chronod -[_EXServiceClient launchWithConfiguration:error:]_block_invoke failed with error: Error Domain=com.apple.extensionKit.errorDomain Code=2 "(null)" UserInfo={NSUnderlyingError=0xde6b31c10 {Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0xde6b328e0 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}}} 错误 chronod New process is nil. 错误 chronod Failed to create extensionProcess for extension 'com.jd.jinrong.JDJRWidget' error: Error Domain=com.apple.extensionKit.errorDomain Code=2 "(null)" UserInfo={NSUnderlyingError=0xde6b31c10 {Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0xde6b328e0 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}}}. 默认 chronod [com.jd.jinrong.JDJRWidget] Failed to launch extension with error: Error Domain=com.apple.extensionKit.errorDomain Code=2 UserInfo={NSUnderlyingError=0xde6b31c10 {Error Domain=RBSRequestErrorDomain Code=5 UserInfo={NSLocalizedFailureReason=, NSUnderlyingError=0xde6b328e0 {Error Domain=NSPOSIXErrorDomain Code=111 UserInfo={NSLocalizedDescription=}}}}}.

Hey everyone, I’m completely stuck and hoping someone here (or an Apple rep) can help, because Developer Support is just sending me the exact same template replies at this point. I submitted a standard version update for my app (Hadiyyati - Luxury Gifts) back on February 7th. It has now been over 45 days, and the status is still permanently frozen on "Waiting for Review." Here is the loop I am stuck in: I've had an Expedited Review requested and approved 3 separate times. Support gives me a case number, says they contacted the App Review Board, and tells me to wait. Weeks pass, nothing happens, and when I follow up, I get: "At this time, your app review is proceeding normally, and there is no further action you need to take." 45 days for a store update is not "proceeding normally." I strongly suspect my submission (ID: aeadea76-8fb4-437c-9c04-60171b909f3e) is bugged, corrupted, or locked in a "ghost state" on the App Store Connect backend. Has anyone dealt with a completely frozen submission like this? Is there a specific magic word or channel to get Tier 2 tech support to actually check the server status without me rejecting the build and starting all over? Any advice is hugely appreciated!