Overview

My game supports both GameCenter, setting up a custom host and local games against bots. To log in to GameCenter and be able to handle invitations from other players, I set GKLocalPlayer.local.authenticateHandler after the app finished loading. But it seems that whenever I’m disconnected from the internet for more than 24 hours, setting GKLocalPlayer.local.authenticateHandler causes the whole window to be obfuscated by an alert telling me that I have no internet connection. When this happens, if I connect to the internet and disconnect again, the alert is not shown anymore. This is a huge problem because the alert prevents a user from using any other feature of the app unrelated to GameCenter, since there's no way to dismiss it. Is this really intended behaviour or how is a user supposed to continue using the app that supports GameCenter and does not rely on it, while being disconnected from the internet? I created FB22951946.

Mac Store search results now default to IOS Apps, devastating Mac Catalyst sales. To compound this issue, there is no way for Mac Catalyst developers to remove their Mac Catalyst version so that their IOS app (for iPad) will appear. They are invisible. I've contacted Apple but no reply yet. Any thoughts?

FB22844728 Xcode 26.5, macOS 26.5, MacStudio M1 64 GB The disaster of S-L-O-W T-Y-P-I-N-G that plagued Xcode several years ago returns. I guess all the ultra-advanced LLM neuroneirowebs still can't advise those at Apple who develop the Xcode app how to provide this uber-exotic, unheard-of functionality: JUST TYPING THE CODE. This disaster doesn't affect all projects, but it does affect the exact one I'm working on, and I need to type a lot of code there. Significant time is already wasted. I performed all the recommended steps like relaunching, restarting, and deleting deprived data with no effect. Hope something can be done about it..

Hi everyone, I’m based in Europe, and I’m trying to fully understand the current App Store payment rules for an iOS app that sells digital services or premium functionality used inside the app. My goal is not to bypass App Store rules, but to implement the correct, compliant payment flow depending on the user’s region and the App Store requirements that apply there. The app would offer things like premium features, credits, or access to digital functionality inside the iOS app. The payment flow I would ideally like to support, where allowed, is: iOS app -> Cloud ahndling -> Stripe Checkout page -> user pays -> Stripe handling -> my backend marks the user as premium What I’m trying to understand is whether this flow is allowed, restricted, or prohibited depending on the user’s App Store storefront / region. My questions are: For digital goods, subscriptions, credits, or premium features used inside an iOS app, is Apple In-App Purchase still required by default? In which regions, exactly, can an iOS app use or link to an external payment provider such as Stripe for digital services used inside the app? For users in the United States, after the Epic Games v. Apple changes, can an app show an external payment option such as “Subscribe on the web” or “Pay with Stripe”? If yes, what are the exact requirements, limitations, wording rules, Apple fees, or reporting obligations? For users in the European Union, under the DMA-related rules, does Apple allow external purchases through Stripe or a web checkout? If yes, do I need specific Apple entitlements, StoreKit External Purchase APIs, Apple approval, transaction reporting, or payment of Apple fees? For the rest of the world, should I assume that Apple IAP is mandatory for digital content, subscriptions, credits, and premium app functionality unless Apple has a specific regional program allowing external payments? What is the correct way to determine which payment flow a user should see? Should this be based on the user’s App Store storefront / StoreKit storefront, rather than IP address, device locale, billing address, or country selected manually by the user? Would a regional routing approach like this be compliant? if App Store storefront == US: show Apple-compliant external purchase link / Stripe option if allowed elif App Store storefront is in the EU and the app has the required Apple entitlement: show Apple-compliant external purchase flow else: show Apple In-App Purchase only If a user pays through Stripe or another external checkout in a region where external payments are allowed, can my backend unlock premium features inside the iOS app? Or are there restrictions on granting access inside the app when the purchase was not completed through Apple IAP? For a first App Store release, is the safest approach to launch with Apple IAP only, then later add external payment options only in regions where Apple explicitly allows them? For developers who have recently submitted apps with external payment links for digital services: Which countries or storefronts were accepted? Did App Review require special entitlements? Were there specific wording or UI requirements? Did Apple require transaction reporting or apply additional fees? Were there differences between the US, EU, and other regions? In short, I’m trying to understand the practical compliant architecture: iOS app = Apple IAP by default external Stripe / web checkout = only where regionally allowed by Apple backend = unlock premium access after valid payment, whether Apple IAP or approved external payment payment UI = adapted based on App Store storefront / region I would really appreciate answers from developers, App Review experiences, or anyone familiar with the current Apple rules after the Epic ruling, DMA changes, and Apple’s External Purchase Link / StoreKit External Purchase programs. Thanks!

After a 2.3.2 rejection (two promoted subscriptions had identical display name + description), I withdrew the review submission to edit the subscription metadata. The app version moved to "Developer Rejected," but both auto-renewable subscriptions stayed stuck in "In Review." There is no active review submission attached to them anymore, yet: The subscription metadata (display name / description) is locked / not editable. There is no "Remove from Review" control on the subscription page or the version page. The version page no longer shows an "In-App Purchases and Subscriptions" section. Has anyone hit this orphaned "In Review" state? Is there a developer-side way to release a subscription from review, or is contacting Developer Support the only path? Appreciate any pointers, I'm on a deadline. App: Mossly: Plant Care Journal - Apple ID 6770594348 Subscription Group: Mossly Premium - 22098178 Subscriptions, both stuck: Mossly Premium - Monthly - 6770598241 (com.mossly.app.monthly) Mossly Premium - Yearly - 6770599597 (com.mossly.app.annual1)

We are adding tap2pay as a payment method to our existing POS app. Our app is distributed business to business via Custom Apps. To get a production entitlement there's a checklist, in this checklist there are several sections. For Section 3, "Requirements for Enabling Tap to Pay on iPhone" there's a paragraph: If you distribute your app with programs such as Unlisted apps, Custom apps, or the Apple Developer Enterprise Program (ADEP) these requirements are applicable only if users are expected to accept terms and conditions using an Apple Account on the iPhone. We are using Custom Apps but its unclear what 'terms and conditions' refer to, does this refer to our own t&cs and not Apple's t&cs?

Posting because I have run out of changes to make and Apple is still hitting me with the same guideline. I run Bot Binder (App Store ID 6771506484), a fan-built collection-tracking app for action-figure collectors. No Hasbro license. No trademarked wordmark in the app name or icon. One developer, paid account, side project. Three 4.1(a) Copycats rejections in six days. May 30, vc109 rejected. Subtitle "Transformers Collection Hub" and keywords led with "transformers." Acknowledged. I rewrote the subtitle, scrubbed the keywords, shipped vc114 with a Hasbro attribution disclaimer modeled on Dex and Yugipedia, plus a Resolution Center reply citing 15 live App Store comparables. June 1, vc114 rejected. Same guideline. Flagged screenshot was the dashboard hero, which still rendered marketing text and a Hasbro figure in the featured spot. Acknowledged. I gated every brand-bearing UI surface behind an iOS check, swapped the iOS feature pool to third-party and upgrade-kit figures only, replaced the original mascot in both the iOS app icon and the in-app head graphic with a new abstract design, regenerated the splash, and shipped vc132. The mascot replacement was a real concession. That mascot is the visual identity of the brand on web and Android. I changed it on iOS specifically because the reviewer signaled the icon area was in scope. June 4, vc132 submitted with full scorched-earth metadata. Description rewritten end to end, zero third-party brand/character/trademark references anywhere (verifiable in the live appStoreReviewDetail record). Promotional text and keywords generic. Screenshots reshot from the gated iOS build with no franchise overlays or characters in hero positions. In-app disclaimer footer on every iOS screen. Public support page hosts the same disclaimer. Age rating bumped 4+ to 12+. June 5, 1:41 AM. Rejected again. Two notes: 4.1(a): "The metadata appears to contain potentially misleading references to third-party content. Specifically, the metadata still includes content that resembles Transformers without the necessary authorization. … If you do not have the necessary rights to the third-party content, it would be appropriate to revise the metadata to remove the third-party content before resubmitting for review." 2.3.3: "The iPhone and iPad screenshots do not show the actual app in use in the majority of the screenshots. Marketing or promotional materials that do not reflect the UI of the app are not appropriate for screenshots." This is the third time the rejection has cited "the metadata" without naming a single specific field. After three rounds my description has zero third-party references, promotional text has none, keywords have none, and screenshots are stripped. There is nothing left in the listing to act on. Before redesigning the mascot for vc132 I sent App Review a direct question asking for any guidance on the icon and mascot direction. The full reply: Hello, We appreciate your efforts to comply with the App Review Guidelines. We are not able to provide feedback on app concepts or features, but we recommend evaluating your suggestions against the App Review Guidelines, the Apple Developer Program License Agreement, and the Human Interface Guidelines. Additionally, if you are considering implementing any of the following functionality, we recommend reviewing all associated reference material: Apple Developer Apple Copyright and Trademark Guidelines Game Center iCloud In-App Purchase You may also choose to post a question in the Apple Developer Forums. Best regards, App Review That reply, taken with three rejection notes that name no specific field, reads exactly like a large language model behind a developer-relations endpoint. Nothing app-specific. References functionality with no bearing on my submission (Game Center, iCloud, In-App Purchase). Closes by redirecting me to this forum, which is the only reason I am writing the post. The whole exchange feels like I am talking to a system, not a person. If a human reviewer is on the other end of this thread, I am asking you to engage as one. One sentence naming the specific flagged surface resolves this thread today. The two notes also contradict each other on remediation. 2.3.3 wants screenshots showing the actual app in use, not marketing. 4.1(a) wants third-party-resembling content removed from "the metadata." Once the listing copy is generic and the screenshots show the real UI, what those screenshots show is the in-app catalog. So the only third-party-resembling content the reviewer can still be pointing at is the catalog itself, a different scope than how metadata versus in-app content has historically been drawn. What that means in practice: Bot Binder has over 1000 active users with new collectors joining every day, and the in-app catalog contains more than 10,000 figures. If 4.1(a) is pointing at the catalog, the only remediation Apple's note is offering me is to remove that content, which isn't viable. The catalog is the product. Stripping 10,000 catalog entries invalidates the collections, wishlists, and trade data of every existing user. There is no version of this app that satisfies that interpretation and still functions. Either the scope is different than I'm reading, or 4.1(a) is being applied to a category of app that cannot exist on the App Store, in which case I need that stated directly so I can stop iterating. What I need. App Review staff, if a person is reading this: name the surface. Which field, which screenshot, which paragraph still flags as third-party-resembling? One sentence. If the answer is "the in-app catalog," say so and I will stop submitting. Developers running unlicensed-IP collector apps on the App Store, particularly iCollect Action Figures (656405076, "Transformers" in subtitle), The Ark TFC86 by Chris Sudac, My G.I. Joes (1606553734), Dex (1555489854), Yugipedia (1026470546), Brick by Brick (525328219), Pokellector (600580227). What got you through 4.1(a)? Disclaimer language, or did you have to remove franchise content from the iOS build itself? Asking because some of you are doing exactly what I am being rejected for and your apps are live. Anyone who has booked an App Review Appointment for 4.1(a): did you get surgical guidance, or the same template? Full submission timeline, build IDs, screenshots, and the appStoreReviewDetail record available on request. After six days of taking every revision step Apple has asked for and landing in the same place, I just need actual specificity from somebody.

Hello Apple Staff, I am writing again because my app review issue is still unresolved, and I am becoming increasingly concerned that the submission may not be properly moving through the normal App Review queue. App ID: 6760743106 Submission ID: 6950ecff-f833-404d-b04b-ac34ec552b85 Current status: Waiting for Review At first, I waited for approximately two days with no progress. Since the status did not move at all, I submitted a new build and resubmitted the app, thinking there may have been an issue with the previous submission. However, it has now been nearly one week since the resubmission, and the app is still stuck in Waiting for Review. The status has not moved to In Review. I have already tried multiple official support channels: I contacted Apple Developer Support by phone. I submitted an email support request. I posted on the Developer Forums. I submitted an expedited review request. Unfortunately, nothing has changed so far, and I have not received any clear confirmation that the current submission is properly queued for review. I fully understand that App Review times can vary, and I sincerely respect the work of the App Review team. However, this situation is becoming very serious for us. The update is important for our users, and the continued delay is creating significant operational and business impact. At this point, I am not asking to cancel the submission or resubmit the app again. I am asking whether Apple can please verify the following: Whether the current submission is properly queued for App Review. Whether there is any internal processing or queueing issue preventing the review from starting. Whether there is any action required from my side that is not visible in App Store Connect. If possible, could an Apple Staff member please escalate this case to the App Review team or confirm that the submission is correctly queued? I would be extremely grateful for any help or clarification. We are feeling very stuck because we have tried every support channel available to us, but the app remains in Waiting for Review with no progress. Thank you very much for your time and support.

My app stuck in "Waiting for Review" for over a month now. During this time I have published multiple updates on Android, and other platforms (Garmin). iOS users constantly asking me: where is the update? As a result, I receive a LOT of negative reviews on other platforms, because people are expecting iOS app and it missed all the possible deadlines and it's completely out of my hands. All of this, so Apple can cut 30% of my profits. I'm actually fed up. I can not rely on Apple anymore. I don't understand why we are paying $99 and for what. Just a quick browse through the forum, and I can see I am not the only one. Apple just don't care. "Nothing can be done, just pay and shut up" attitude should no longer be tolerated by Apple's developer community.

Hello fellow developers and Apple Review Team, I am reaching out to the community and any Apple App Review representatives here as a matter of absolute business urgency. Our essential health app, BeatO Diabetes Management (App ID: 1070739458), has been effectively paralyzed in the review queue for nearly 40 days (since late April 2026), severely impacting thousands of chronic care patients who rely on our ecosystem daily for blood glucose tracking. We are completely aligned with Apple’s rigorous safety standards, but we have reached an operational dead end where detailed, compliant answers are met with week-long silence. ⏱️ The Timeline of the Review Deadlock: Late April 2026: Initial build submitted. Flagged under Guideline 1.4.1 (Safety - Physical Harm) regarding our connection to external hardware (a CE-certified glucometer). May 12, 2026: We provided absolute regulatory documentation: official CE certifications, supplier details, clinical validation reports, and proof of prominent American Diabetes Association (ADA) threshold disclaimers inside the UI. May 15, 2026: Apple responded stating: "Your submission's review will require additional time... We do not require any further information at this time." May 26/27, 2026: After a prolonged freeze, we halted the initial release to clear the pipe and submitted a completely fresh build (Submission ID: a0bf3856-693b-4577-adc7-9199a5f9fe34) hoping to reset any stuck internal states. May 27, 2026: Apple requested information under Guideline 2.1 (Information Needed) asking two specific questions about algorithmic personalization and our "tailored diabetes program" marketing text. May 27, 2026: Within a couple of hours, we provided an exhaustive, definitive response: Clarified ADA Guidelines: Confirmed that high/low glucose classifications are strictly based on standard published clinical data (ADA Standards of Care) and explicitly disclosed in our Terms & Conditions, not personalized by an algorithm. Clarified Program Architecture: Proved that 0% of the program is generated by an algorithm. The app acts purely as an introductory storefront/brochure. The actual care management is fulfilled entirely offline directly by human doctors and certified medical professionals. It is definitively not an algorithmic medical device feature. May 28, 2026 to Present: The app was re-entered into the "In Review" state and has sat completely frozen ever since. 🛑 The Core Problem & Business Impact We have successfully provided every piece of documentation Apple has asked for - legal, medical, clinical, and architecture definitions. The reviewer explicitly stated they have everything they need, yet we are trapped in an endless manual review loop. Because our app manages active diabetic health metrics, this prolonged delay prevents us from deploying critical performance optimizations and bug fixes. Our patient support lines are flooding, and our operational product roadmap for the quarter is completely stalled. 🙏 Request to the Community / Apple Engineers Has anyone else dealing with health hardware/software integration hit this specific wall where your answers are fully compliant, but the review desk simply stops processing the ticket? If any Apple App Review moderators or App Store Connect engineers see this, we respectfully request an internal escalation or an App Review Appointment to unblock this build. We are ready to jump on a call immediately to provide any final clarity required. App Name: BeatO Diabetes Management App ID: 1070739458 Latest Submission ID: a0bf3856-693b-4577-adc7-9199a5f9fe34 Thank you for your time and guidance. Regards, Sanketkumar Biswas

hello app review: My app was submitted for review at 11:07 PM on June 1st, and as of now, on the afternoon of June 4th, it has not yet entered the review process. Please urge the review team to proceed with the review as soon as possible. If there are any areas that need to be rectified, we will immediately make the necessary changes. Thank you

It has been weeks since our app update has moved forward in review. After waiting several days, we also submitted an expedited review request, but the issue remains unresolved. We have contacted App Review through review notes, Apple Developer Support calls, emails, and prior forum posts. After our second forum post, calls with Apple Developer Support, and two additional email requests, we are writing here one more time because we still have not received a clear update or resolution. As we have mentioned before, this is a financial app, and with that comes a responsibility to provide users with the most reliable and up-to-date version possible. Our pending update includes important fixes that our users are waiting for. We have also noticed other apps in our category continue moving through review and releasing updates recently, so we would appreciate any guidance on whether there is something specific blocking our review. app id is id 6753857720

I have a @Query which I would like to sort using a custom criterion. I would like to use an array of SortDescriptors where I can specify a key path and a CUSTOM SortComparator. (I.e., I can write SortComparators which do what I want, but I can't use them in a SortDescriptor because there is no initializer which takes a SortCompartor which is not a String.StandardComparator.) This is not a question about dynamic sorting, which has well-known solutions. I am trying to perform a sort which cannot be satisfied by any existing SortDescriptor (or array of SortDescriptors). Any thoughts about how to resolve this situation?

Mac: MacBook Pro 16-inch (Intel, 2019) macOS: Tahoe 26.5.1 I'm trying to determine whether this is expected behavior or a bug. Setup I purchased a new 2TB SSD to use exclusively for Time Machine. Before configuring Time Machine, I manually erased the SSD in Disk Utility and formatted it as: APFS (non-case-sensitive) Encrypted I specifically did not choose APFS (Case-sensitive). What happened After selecting the SSD as a Time Machine destination and allowing macOS to prepare the disk, I later checked the volume information and found: File System Personality: Case-sensitive APFS and: APFS Volume Disk (Role): Backup Name: Brad Mac Backups SSD (Case-sensitive) The volume appears to have been converted to a dedicated APFS Backup volume and is now reported as case-sensitive. Additional observations After backups complete: tmutil status reports: Running = 0 indicating Time Machine is no longer running. However, Spotlight processes (mds and mds_store) continue accessing the backup volume for many hours afterwards, preventing normal ejection of the SSD. Using: sudo lsof | grep "/Volumes/Brad Mac Backups SSD" shows Spotlight processes holding the drive open. Finder's "Force Eject" works successfully. Questions Is it expected behavior in macOS Tahoe for Time Machine to create a Case-sensitive APFS Backup volume, even when the destination was originally formatted as standard APFS? Has anyone else observed a Time Machine destination changing from APFS (non-case-sensitive) to APFS (Case-sensitive) during setup? Could the case-sensitive APFS format be related to Spotlight continuously indexing the backup volume and preventing normal ejection? Relevant Output diskutil info disk3s2 returns: File System Personality: Case-sensitive APFS and: diskutil apfs list shows: APFS Volume Disk (Role): Backup Name: Brad Mac Backups SSD (Case-sensitive) Mount Point: /Volumes/Brad Mac Backups SSD 1 Any insight would be appreciated, as Apple Support was unable to explain why the backup volume became case-sensitive.

App Store Connect returns the following message when the NSExtensionPointIdentifier key in the Info.plist of a Device Activity Monitor extension contains an invalid value: ITMS-90349: Invalid Info.plist value - The value of the NSExtensionPointIdentifier key, <value>, in the Info.plist of ".../PlugIns/...appex" is invalid. To resolve this issue, set NSExtensionPointIdentifier to com.apple.deviceactivity.monitor-extension. The expected Info.plist structure for a Device Activity Monitor extension is: <plist version="1.0"> <dict> <key>NSExtension</key> <dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.deviceactivity.monitor-extension</string> <key>NSExtensionPrincipalClass</key> <string>$(PRODUCT_MODULE_NAME).DeviceActivityMonitorExtension</string> </dict> </dict> </plist> After you apply this fix, build and archive your app, then re-upload to App Store Connect to confirm the error is resolved.

Calling contactAccessPicker results in a blank sheet and a jetsam error, rather than the expected contact picker, using Apple’s sample code, only on device with iOS 26.2.1. This is happening on a iPhone 17 Pro Max running 26.2.1, and not on a simulator. I’m running Apple's sample project Accessing a person’s contact data using Contacts and ContactsUI Steps: Run the sample app on device running iOS 26.2.1. Use the flow to authorize .limited access with 1 contact: Tap request access, Continue, Select Contacts. Select a contact, Continue, Allow Selected Contact. This all works as expected. Tap the add contact button in the toolbar to add a second contact. Expected: This should show the Contact Access Picker UI. Actual: Sheet is shown with no contents. See screenshot of actual results on iOS device running 26.2.1. Reported as FB21812568 I see a similar (same?) error reported for 26.1. It seems strange that the feature is completely broken for multiple point releases. Is anyone else seeing this or are the two of us running into the same rare edge case? Expected Outcome, seen on simulator running 26.2 Actual outcome, seen on device running 26.2.1

I don't remember if i deployed the changes in my cloudkit schema to production when I uploaded the version 2 of my existing app. since then i had accidentally reseted the environment while trying to do the same for another app. This was in haste, without checking the group identifier in the console. How do I know if everything is fine on the user's end?

I would like to explain the current situation regarding our subscriptions and ask a few clarification questions to ensure that our implementation fully complies with App Store requirements. Current Status We have successfully configured our subscriptions in App Store Connect. All subscription products currently appear as “Waiting for Review.” Paid Apps Agreement has been accepted and is active. Banking and tax information are completed and active. RevenueCat integration is working correctly. In TestFlight, the app is now able to: Fetch products successfully Display localized Turkish pricing Open the native Apple purchase sheet Start sandbox purchase flow successfully We can now see Apple’s native TestFlight subscription purchase popup with the correct products and prices, which indicates that StoreKit communication is functioning correctly. However, we are still confused about the review/submission relationship between: The app version submission The first subscription review Existing “Waiting for Review” subscription states Questions Since the subscriptions already show “Waiting for Review,” does this mean they are correctly attached to the currently reviewed app version? Or do we still need to create an entirely new app version submission and manually re-add all subscriptions from the “In-App Purchases and Subscriptions” section before review can continue? The subscriptions are already accessible in TestFlight sandbox purchase flow. Does this confirm that our StoreKit configuration is now technically valid for review? If there is still a configuration issue on our side, could you please clarify exactly which step is missing: attaching subscriptions to a specific binary, submitting the first subscription with a new app version, or another App Store Connect configuration requirement? Our goal is to fully comply with App Store policies and avoid submitting another incorrect review build.

It is outrageous that when you enrol in the Apple Developer Program, you have to pay for it, but it is not activated. This is a serious problem that needs to be addressed immediately. Does anyone know how to get Apple to get back to me about this? My money was taken very quickly, but I haven't received anything in return.

Hello, We have a security solution which intercepts network traffic for inspection using a combination of Transparent Proxy Provider and Content filter. Lately we are seeing reports from the market that on M5 Macbooks and A18 Neos the system will kernel panic using our solution, even though it never happens on M1-M4 and no significant code changes were made in the mean time. All crashes seem to be related to an internal double free in the kernel: panic(cpu 0 caller 0xfffffe003bb68224): skmem_slab_free_locked: attempt to free invalid or already-freed obj 0xf2fffe29e15f2400 on skm 0xf6fffe2518aaa200 @skmem_slab.c:646 Debugger message: panic Memory ID: 0xff OS release type: User OS version: 25D2128 Kernel version: Darwin Kernel Version 25.3.0: Wed Jan 28 20:54:38 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T6050 Additionally, from further log inspection, before panics we find some weird kernel messages which seem to be related to some DMA operations gone wrong in the network driver on some machines: 2026-03-30 14:11:21.779124+0300 0x30f2 Default 0x0 873 0 Arc: (Network) [com.apple.network:connection] [C9.1.1.1 IPv4#e5b4bb04:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi, flow divert agg: 1, LQM: good)] event: flow:start_connect @0.075s 2026-03-30 14:11:21.780015+0300 0x1894 Default 0x0 0 0 kernel: (402262746): No more valid control units, disabling flow divert 2026-03-30 14:11:21.780017+0300 0x1894 Default 0x0 0 0 kernel: (402262746): Skipped all flow divert services, disabling flow divert 2026-03-30 14:11:21.780102+0300 0x1894 Default 0x0 0 0 kernel: SK[2]: flow_entry_alloc fe "0 proc kernel_task(0)Arc nx_port 1 flow_uuid D46E230E-B826-4E0A-8C59-4C4C8BF6AA60 flags 0x14120<CONNECTED,QOS_MARKING,EXT_PORT,EXT_FLOWID> ipver=4,src=<IPv4-redacted>.49703,dst=<IPv4-redacted>.443,proto=0x06 mask=0x0000003f,hash=0x04e0a750 tp_proto=0x06" 2026-03-30 14:11:21.780194+0300 0x1894 Default 0x0 0 0 kernel: tcp connect outgoing: [<IPv4-redacted>:49703<-><IPv4-redacted>:443] interface: en0 (skipped: 0) so_gencnt: 14634 t_state: SYN_SENT process: Arc:873 SYN in/out: 0/1 bytes in/out: 0/0 pkts in/out: 0/0 rtt: 0.0 ms rttvar: 250.0 ms base_rtt: 0 ms error: 0 so_error: 0 svc/tc: 0 flow: 0x9878386f 2026-03-30 14:11:21.934431+0300 0xed Default 0x0 0 0 kernel: Hit error condition (not panicking as we're in error handler): t8110dart <private> (dart-apcie0): invalid SID 2 TTBR access: level 1 table_index 0 page_offset 0x2 2026-03-30 14:11:21.934432+0300 0xed Default 0x0 0 0 kernel: [ 73.511690]: arm_cpu_init(): cpu 6 online 2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.511696]: arm_cpu_init(): cpu 9 online 2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.569033]: arm_cpu_init(): cpu 6 online 2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.569038]: arm_cpu_init(): cpu 9 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.577453]: arm_cpu_init(): cpu 7 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.586328]: arm_cpu_init(): cpu 5 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.586332]: arm_cpu_init(): cpu 8 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.621392]: (dart-apcie0) AppleT8110DART::_fatalException: dart-apcie0 (<ptr>): DART DART SID exception ERROR_SID_SUMMARY 0x00003000 ERROR_ADDRESS 0x0000000000009800 2026-03-30 14:11:21.934443+0300 0xed Default 0x0 0 0 kernel: [ 73.621397]: Hit error condition (not panicking as we're in error handler): 2026-03-30 14:11:21.934443+0300 0xed Default 0x0 0 0 kernel: t8110dart <ptr> (dart-apcie0): invalid SID 2 TTBR access: level 1 table_index 0 page_offset 0x2Expect a `deadbeef` in the error messages below 2026-03-30 14:11:21.934452+0300 0xed Default 0x0 0 0 kernel: Expect a `deadbeef` in the error messages below 2026-03-30 14:11:21.934456+0300 0xed Default 0x0 0 0 kernel: (AppleEmbeddedPCIE) apcie[0:centauri-control]::_dartErrorHandler() InvalidPTE caused by read from address 0x9800 by SID 2 (RID 2:0:1/useCount 1/device <private>) 2026-03-30 14:11:21.934469+0300 0xed Default 0x0 0 0 kernel: (AppleT8110DART) Ignored dart-apcie0 (0xfbfffe18820b0000): DART(DART) error: SID 2 PTE invalid exception on read of DVA 0x9800 (SEG 0 PTE 0x2) ERROR_SID_SUMMARY 0x00003000 TIME 0x11242d43fd TTE 0xffffffffffffffff AXI_ID 0 We do not have any correlation between machines, usage pattern or installed applications. Uninstalling the network protection features seem to largely fix the issues, even though we have heard of crashes happening even in safe mode or with our network extension disabled from system settings. We weren't able to reproduce internally and it seems to happen completely random on client machines, but often enough to be disrupting. Can you tell us please if this is a known problem and if there's a workaround or what can we do to narrow it down? Thanks.