“build disappears”

I'm developing a macOS security tool using NEFilterDataProvider as a system extension. On macOS 26 beta (25E241), sysextd consistently rejects my extension with: sysextd: no policy, cannot allow apps outside /Applications Configuration: App installed in /Applications/ Signed with Developer ID Application (693DSH8GN5) Entitlement: com.apple.developer.networking.networkextension = content-filter-provider com.apple.developer.system-extension.install = true Developer Mode enabled on test machine Comparison with Little Snitch: Little Snitch runs correctly on the same machine. Key differences I found: Little Snitch uses content-filter-provider-systemextension instead of content-filter-provider Little Snitch has com.apple.security.app-sandbox = false Both signed with Developer ID Application When I switch to content-filter-provider-systemextension, Xcode rejects every provisioning profile because none match that entitlement value, and the Developer Portal doesn't expose fine-grained control over the Network Extensio

I've been rejected a couple of times for Guidelines 5.1.1(i) and 5.1.2(i) regarding third-party AI data sharing consent. Each time, the reviewer states they cannot see the consent prompt, even though it is the first screen displayed on every app launch. My app (GymFusion) uses Anthropic's Claude AI for features like meal scanning, body composition analysis, and workout coaching. Here is exactly what I've implemented: IN-APP CONSENT (embedded in view hierarchy, not a sheet/popup): In my RootView.swift, the consent is a conditional view that blocks the entire app: } else if !consentManager.hasConsented && !consentManager.hasSeenConsent { AIConsentView() } else if auth.isAuthenticated { MainTabView() } The hasSeenConsent flag is reset to false on every app launch in the App's init(), so the consent screen appears on every launch until the user accepts: init() { UserDefaults.standard.set(false, forKey: user_ai_consent_seen) AIConsentManager.shared.hasSeenConsent = false FirebaseApp.configure() } THE CONSE

0 0x1001bd52c __assert_rtn + 252 1 0x100132054 void std::__1::__introsort(ld::Atom const**, ld::Atom const**, ld::AliasAddressOrderer&, std::__1::iterator_traits::difference_type, bool) + 0 2 0x1001319a4 ld::LayoutLinkedImage::assignAtomOffsetsInSection(ld::SectionLayout&, unsigned int, bool) + 680 3 0x100136724 void dispatchForEach(std::__1::span, unsigned long, ld::LayoutLinkedImage::sortAtomsWithinSections()::$_0)::'lambda'(unsigned long)::operator()(unsigned long) const + 7852 4 0x19dca8aec _dispatch_client_callout2 + 16 5 0x19dca37f8 _dispatch_apply_invoke3 + 336 6 0x19dca8ad4 _dispatch_client_callout + 16 7 0x19dc91a60 _dispatch_once_callout + 32 8 0x19dca2938 _dispatch_apply_invoke + 252 9 0x19dca8ad4 _dispatch_client_callout + 16 10 0x19dcc59dc _dispatch_channel_invoke.cold.5 + 32 11 0x19dca113c _dispatch_root_queue_drain + 736 12 0x19dca1784 _dispatch_worker_thread2 + 180 13 0x19de47e10 _pthread_wqthread + 232 ld snapshot written at /tmp/****app.debug.dylib-2026-03-24-092748.ld-snapshot ld: A

Hello, At work, we want to release a new version of our cross-platform desktop application this week. Unfortunately, I've had issues getting the dmg signed by the Apple notary service, which will delay the release until it's successful. However, I remade and successfully signed the previously released version (also dmg) with the same credentials, so I know it's not a problem with the file format or my account. I have tried the following to no avail: Lots of Googling Running xcrun notarytool submit with the -v option (verbose) to see more error messages Going to the URL given (appstoreconnect.apple.com/notary/v2/submissions/{submission_id}) and examining the file it downloaded (not much info, let alone helpful info) Contacting Apple developer support over the phone (they couldn't help with this particular issue, since it's code-level support) The only big change we made this time was switching to Maven for our build tool and dependency management (we previously used Ant with manual dependency manageme

My team is evaluating an iOS companion app for our own network-connected device, and we want to understand whether the planned architecture would likely create an App Review problem under Guideline 2.5.17. Our situation is: We are building our own device and our own companion app. We do not intend to market the device as a Matter-certified device initially. We do not intend to support Apple Home or broad third-party Matter ecosystem interoperability in the first release. We are under a tight schedule and are considering reusing Matter/CSA-derived libraries, data models, and protocol concepts internally to reduce engineering effort and move faster toward eventual certification. Our current understanding is that there are already many iOS apps that communicate with LAN-connected devices using proprietary protocols, so our initial assumption is that a vendor-specific local-network device workflow should generally be acceptable. The point we are trying to clarify is whether that changes if the implementa

Hello everyone, I’m submitting an iOS app to App Review and received Guideline 2.1(b) – Information Needed. Apple says it appears the app may access or include paid digital content/subscriptions and they want details about the business model. In my project, a paywall / premium UI exists in the codebase, and subscription products are configured in App Store Connect for a future release, but in the build currently submitted: The paywall is disabled (not reachable through any UI flow / feature flags are off). There is no purchase flow (no way to subscribe in-app). There is no external purchase (no website/Stripe/etc.). Users cannot access any previously purchased subscriptions (no entitlement access / restore not exposed). Questions: Can the mere presence of a paywall screen / IAP-related code in the binary (even if disabled/unreachable) block App Review or trigger repeated 2.1(b) requests? Is it recommended to remove paywall/IAP code entirely from the review build if it’s not used yet, or is a

Hello everyone, I recently submitted my iOS app for review, but it was unfortunately rejected under Guideline 2.1(a) - Performance - App Completeness. For context, my app is a healthcare application built with Ionic. According to the App Review team's message, they found the app to be incomplete. They stated they were unable to review the app because they couldn't get past the login screen. The Root Cause: Upon investigating, we discovered the issue is related to IP Geo-blocking. Because the app handles sensitive healthcare data, our API provider strictly blocks all network traffic originating from outside of Italy to legally comply with European GDPR regulations. Since the App Review team tests from the US, their requests are being entirely blocked by the firewall, causing the login to fail and the app to look broken on their end. What I have verified so far: I have provided valid demo account credentials in the App Store Connect App Review Information section. I have tested the app thoroughly on physical de