Thank you for the response! However, I've found the actual root cause of the issue.
To clarify: I'm not using iOS 26 beta or arm64e architecture - I verified this multiple times in my build settings. My app targets iOS 15+ and uses standard architectures.
Root Cause Identified:
The web browser engine entitlement requirement is being incorrectly triggered by a complex async pattern in my SwiftUI code. Specifically, this .task block with nested withCheckedContinuation, actor, and withObservationTracking:
.task {
if isLoading {
// Wait for AuthManager to complete user state determination
print("🕐 SkydenApp: Waiting for AuthManager to complete user state determination...")
// Use withObservationTracking to wait for isUserStateReady
await withCheckedContinuation { (continuation: CheckedContinuation<Void, Never>) in
actor ContinuationState {
private var hasResumed = false
func tryResume(_ continuation: CheckedContinuation<Void, Never>) -> Bool {
if !hasResumed {
hasResumed = true
continuation.resume()
return true
}
return false
}
func shouldContinue() -> Bool {
return !hasResumed
}
}
let state = ContinuationState()
@MainActor func checkReadyState() {
withObservationTracking {
let isReady = appContext.authManager.isUserStateReady
print("🔍 SkydenApp: AuthManager.isUserStateReady = \(isReady)")
if isReady {
Task {
if await state.tryResume(continuation) {
print("✅ SkydenApp: AuthManager user state ready!")
}
}
}
} onChange: {
// Re-check when state changes, but only if we haven't resumed yet
Task {
if await state.shouldContinue() {
await MainActor.run {
checkReadyState()
}
}
}
}
}
// Start checking on main actor
Task { @MainActor in
checkReadyState()
}
}
// Non-blocking: Start app initialization in background
Task {
await performAppInitialization()
}
isLoading = false
// Small delay to ensure main content is ready before fade
try? await Task.sleep(for: .milliseconds(500))
// Trigger fade out animation
shouldFadeOutSplash = true
}
}
When I simplified this to a basic async pattern, the entitlement requirement disappeared completely.
This appears to be a bug in Apple's static analysis/validation tools - they're incorrectly flagging this complex async pattern as requiring web browser engine capabilities, when it's actually just waiting for an observable property to change.
Impact: This could affect other developers using similar advanced async patterns with SwiftUI observation, even when they have no web browser functionality in their apps.
Reproduction: The above code should reliably reproduce the issue when validating with App Store Connect.
I hope this helps the validation team identify and fix this edge case in the static analysis tools!
