Does iOS 26 support HDR images for app icons to be rendered in High Dynamic Range for Springboard or not?

I’m building a React Native 0.72.10 iOS app and hitting build errors. Environment: macOS: Apple M4, Sequoia 15.7.2 Xcode: 26.1.1 React Native: 0.72.10 Errors: Could not delete /Users/.../ios/build because it was not created by the build system Unable to write file '/Users/.../ios/build/Pods.build/Debug-iphonesimulator/...': Operation not permitted (Multiple Pods / React Native framework headers affected) What I’ve tried: bash rm -rf ios/build rm -rf ~/Library/Developer/Xcode/DerivedData xattr -w com.apple.xcode.CreatedByBuildSystem true ios/build pod deintegrate && pod install sudo chown -R $(whoami) ios/build Observations: ios/build is recreated automatically. Some files have com.apple.xcode.CreatedByBuildSystem: true. 3.Xcode have Full disk access authorisation. Why does Xcode fail to delete / write to ios/build even though it’s recreated automatically by the build system? Is this caused by Xcode itself, macOS permissions? Any recommended fix or workaround for these “Operation not permitted” errors?

Hello, I’m developing a third-party VoIP app called Heyno and trying to support Siri-initiated calls so they behave like WhatsApp / FaceTime, especially from the lock screen. Target behavior From the locked device, the user says: “Hey Siri, call <contact> using Heyno” Expected result: • System CallKit audio-call UI appears. • No “continue in ” sheet, no forced unlock or foregrounding. • Our app handles the VoIP leg in the background via CXProviderDelegate. WhatsApp already does this with: “Hey Siri, call <contact> on WhatsApp” I’m trying to reproduce that behavior for Heyno using public APIs. I have followed the SiriKit + CallKit VoIP docs but cannot get a clean Siri → CallKit → app flow from the lock screen without either: Being forced into .continueInApp (unlock + foreground), or Hitting CallKit transaction errors when starting the call from the app in response to the intent. Current implementation Intents extension (INStartCallIntentHandling) • resolveContacts(for:with:) normalizes to E.164 and returns INPersonResolutionResult.success. • resolveDestinationType → .success(.normal). • resolveCallCapability → .success(.audioCall). Confirm / handle currently: func confirm(intent: INStartCallIntent, completion: @escaping (INStartCallIntentResponse) -> Void) { completion(INStartCallIntentResponse(code: .ready, userActivity: nil)) } func handle(intent: INStartCallIntent, completion: @escaping (INStartCallIntentResponse) -> Void) { completion(INStartCallIntentResponse(code: .ready, userActivity: nil)) } Earlier, I used .continueInApp with an NSUserActivity carrying the normalized number and metadata, but that always produced a “Continue in Heyno” sheet that requires unlock and foreground, which breaks the lock-screen Siri flow. App target – CallKit provider In the app I have CXProvider + CXProviderDelegate, which work correctly when calls are initiated from inside the app: func provider(_ provider: CXProvider, perform action: CXStartCallAction) { let handle = action.handle.value // Start VoIP / WebRTC / LiveKit / Asterisk call here provider.reportOutgoingCall(with: action.callUUID, startedConnectingAt: Date()) provider.reportOutgoingCall(with: action.callUUID, connectedAt: Date()) action.fulfill() } If I construct a CXStartCallAction and submit it via CXCallController.request(...) from the app, CallKit UI appears and our pipeline runs correctly. What I tried and what fails Starting CallKit from the Intents extension Calling CXCallController.request(...) directly from handle(intent:completion:) in the extension always yields: com.apple.CallKit.error.requesttransaction error 1 (unentitled) The extension does not have the CallKit entitlement, and the docs say not to initiate calls from the extension, so this path seems unsupported. Using .continueInApp + NSUserActivity Pattern: • handle(intent:) builds NSUserActivity (activityType = NSStringFromClass(INStartCallIntent.self), title = "Heyno Start Call", userInfo with E.164 handle, etc.). • Returns INStartCallIntentResponse(code: .continueInApp, userActivity: activity). • App receives the activity, then starts CallKit + VoIP. Functionally this works, but iOS always requires unlock + foreground (“Continue in Heyno”), which is not acceptable for a Siri lock-screen call. App group + Darwin notification (extension → app → CallKit) Experiment: • Extension writes the normalized number into an app-group UserDefaults. • Extension posts a Darwin notification. • App (if running) listens, reads the number, and initiates CXStartCallAction + VoIP. Observed: • Works only when the app is already running in the background; a killed app is not woken. • In some states I see CXErrorCodeRequestTransactionError.invalidAction (error 6) if I try to issue a CXStartCallAction while CallKit is already doing something as part of the Siri flow. • Siri sometimes replies “There was a problem with the app,” likely because CallKit rejects the transaction or sees duplicate/conflicting actions. My understanding so far • The Intents extension should resolve/confirm the intent but not start the call. • The source of truth for starting a call should be: Siri → CallKit → app’s CXProviderDelegate.provider(_:perform: CXStartCallAction) • The app then starts the VoIP leg, reports started/connected, and fulfills. Where I am stuck What is not clear is how Siri is supposed to route an INStartCallIntent into CallKit for a third-party VoIP app on a locked device without using .continueInApp. If my extension simply: • resolves the contact, • confirm → .ready, • handle → .ready (no NSUserActivity, no CallKit), I do not see a documented mechanism that causes: “Hey Siri, call <contact> using Heyno” on the lock screen to: • Present a CallKit audio call bound to Heyno, and • Deliver CXStartCallAction to my CXProviderDelegate while the app stays in the background. Questions For third-party VoIP apps today, is it recommended to implement INStartCallIntentHandling at all, or should we rely only on CallKit registration and Siri’s built-in support for “Call with ” (no SiriKit extension)? If an INStartCallIntentHandling extension is still the intended pattern: • Should confirm/handle simply return .ready and never start CallKit or set NSUserActivity? • In that case, is Siri expected to invoke CallKit on our behalf and create a CXStartCallAction targeting our provider, even when the device is locked and the app is not foreground? Is there any supported way for a Siri-triggered third-party VoIP call to start from the lock screen via CallKit without: • using .continueInApp (unlock + foreground), and • starting CallKit directly from the Intents extension (unentitled)? Is there any additional configuration, entitlement, provisioning profile flag, or Info.plist key required so that Siri can map “Call using Heyno” directly to our CallKit provider and background VoIP implementation? Current options: • .continueInApp + NSUserActivity → works, but always requires unlock + app UI. • Start CallKit from the extension → fails with “unentitled” and appears unsupported. • Extension → app-group + notification → app → CallKit → VoIP → fragile, with intermittent CXErrorCodeRequestTransactionError.invalidAction. • Remove the extension and hope Siri/CallKit auto-routes to our provider → unclear if this is supported for third-party VoIP apps or reserved for privileged apps. I would appreciate guidance on the intended architecture for this scenario, and whether the “Siri from lock screen → CallKit UI → background VoIP call” flow is achievable for an App Store VoIP app like Heyno using public APIs only.

I have an iOS app that can display a USDZ model downloaded from the Internet (and cached locally) via an ARView. I would like to light that model with an image based light (IBL) also downloaded from the Internet. However, as far as I can tell, ARView can only create an IBL from a resource that has been compiled into the Xcode project and loaded with EnvironmentResource(named:in:) or EnvironmentResource.load(named:in:). Is there a way to create an EnvironmentResource from an HDRI via a file URL to use in ARView in iOS?

After the iOS 26 update, unwanted animations appear on UIButton. I'm using the attributedTitle property of UIButton.Configuration to change the button's text, and an animation appears after iOS 26. (It's unclear whether it's after iOS 26.0 or iOS 26.1, but it likely started with 26.1.) The peculiar thing is that the animation only starts appearing on buttons that have been pressed once. I tried using UIView.performWithoutAnimation and CATransaction's begin(), setDisableActions(true), commit(), but it didn't work. How should I solve this? Below is the code for changing the button's text. func updateTitle() { let keys = type.keys if keys.count == 1 { guard let key = keys.first else { return } if key.count == 1 { if Character(key).isLowercase { self.configuration?.attributedTitle = AttributedString(key, attributes: AttributeContainer([.font: UIFont.systemFont(ofSize: 24, weight: .regular), .foregroundColor: UIColor.label])) } else if Character(key).isUppercase { self.configuration?.attributedTitle = AttributedString(key, attributes: AttributeContainer([.font: UIFont.systemFont(ofSize: 22, weight: .regular), .foregroundColor: UIColor.label])) } else { self.configuration?.attributedTitle = AttributedString(key, attributes: AttributeContainer([.font: UIFont.systemFont(ofSize: 22, weight: .regular), .foregroundColor: UIColor.label])) } } else { self.configuration?.attributedTitle = AttributedString(key, attributes: AttributeContainer([.font: UIFont.systemFont(ofSize: 18, weight: .regular), .foregroundColor: UIColor.label])) } } else { let joined = keys.joined(separator: "") self.configuration?.attributedTitle = AttributedString(joined, attributes: AttributeContainer([.font: UIFont.systemFont(ofSize: 22, weight: .regular), .foregroundColor: UIColor.label])) } }

Device: iPhone 11 iOS Version: 17.2.1 Frameworks: UIKit, Auto Layout App Behavior: App supports Arabic (RTL). User can switch language in-app. When language is switched, the app sets UIView.appearance().semanticContentAttribute and fully rebuilds the window’s rootViewController. Problem Summary I update the global semantic direction only when the user explicitly switches language inside the app — e.g.: // Only run when user switches language inside the app UIView.appearance().semanticContentAttribute = .forceRightToLeft // or .forceLeftToRight // then rebuild the window's rootViewController I do not change UIView.appearance().semanticContentAttribute during navigation transitions. Despite that, after switching the language (and rebuilding the root), the app sometimes crashes during a subsequent UINavigationController push/pop animation. The crash appears to be caused by UIKit’s Auto Layout engine removing or updating directional constraints while a navigation transition is running. Crash Log (most relevant portion) Crashed: com.apple.main-thread 0 CoreAutoLayout 0x1372c -[NSISEngine positiveErrorVarForBrokenConstraintWithMarker:errorVar:] + 212 1 CoreAutoLayout 0x121d4 -[NSISEngine removeConstraintWithMarker:] + 1028 2 CoreAutoLayout 0x11d78 -[NSLayoutConstraint _removeFromEngine:] + 148 3 UIKitCore 0x124ba9c __58-[UIView _updateDirectionalConstraintsIfNeededWasFlipped:]_block_invoke_2 + 56 4 UIKitCore 0x484d4 ___UIViewEnumerateLayoutConstraintsAndAdjustForSelectedLayoutVariables_block_invoke + 296 5 UIKitCore 0x4801c -[UIView(AdditionalLayoutSupport) _withUnsatisfiableConstraintsLoggingSuspendedIfEngineDelegateExists:] + 112 6 UIKitCore 0x60830 -[UIView _updateDirectionalConstraintsIfNeededWasFlipped:] + 356 7 UIKitCore 0x60494 -[UIView setSemanticContentAttribute:] + 148 8 CoreFoundation 0x31794 __invoking___ + 148 9 CoreFoundation 0xe6360 -[NSInvocation invokeUsingIMP:] + 332 10 UIKitCore 0x1d93ec __workaround10030904InvokeWithTarget_block_invoke + 68 11 UIKitCore 0x250ec +[UIView _performSystemAppearanceModifications:] + 72 12 UIKitCore 0x3f008 applyInvocationsToTarget + 1004 13 UIKitCore 0x3dcd4 +[_UIAppearance _applyInvocationsTo:window:matchingSelector:onlySystemInvocations:] + 1180 14 UIKitCore 0x3d744 __88-[UIView(Internal) _performUpdatesForPossibleChangesOfIdiom:orScreen:traverseHierarchy:]_block_invoke + 68 15 UIKitCore 0x3d6c4 -[UIView _performUpdatesForPossibleChangesOfIdiom:orScreen:traverseHierarchy:] + 216 16 UIKitCore 0x3d5a0 -[UIView _didChangeFromIdiomOnScreen:traverseHierarchy:] + 112 17 UIKitCore 0x11644 -[UIView(Internal) _didMoveFromWindow:toWindow:] + 1220 18 UIKitCore 0x1142c -[UIView(Internal) _didMoveFromWindow:toWindow:] + 684 19 UIKitCore 0x1142c -[UIView(Internal) _didMoveFromWindow:toWindow:] + 684 20 UIKitCore 0x1142c -[UIView(Internal) _didMoveFromWindow:toWindow:] + 684 21 UIKitCore 0x10eb4 __45-[UIView(Hierarchy) _postMovedFromSuperview:]_block_invoke + 124 22 CoreAutoLayout 0xa514 -[NSISEngine withBehaviors:performModifications:] + 84 23 UIKitCore 0x10ddc -[UIView _postMovedFromSuperview:] + 504 24 UIKitCore 0xfa24 -[UIView(Internal) _addSubview:positioned:relativeTo:] + 2200 25 UIKitCore 0x7a63b8 __53-[_UINavigationParallaxTransition animateTransition:]_block_invoke_2 + 1252 26 UIKitCore 0x41a70 +[UIView(Animation) performWithoutAnimation:] + 76 27 UIKitCore 0x7a5e84 __53-[_UINavigationParallaxTransition animateTransition:]_block_invoke + 240 28 UIKitCore 0x12749c +[UIView _performBlockDelayingTriggeringResponderEvents:forScene:] + 176 29 UIKitCore 0x7a5990 -[_UINavigationParallaxTransition animateTransition:] + 952 30 UIKitCore 0x291098 ___UIViewControllerTransitioningRunCustomTransition_block_invoke_3 + 52 31 UIKitCore 0x29100c +[UIKeyboardSceneDelegate _pinInputViewsForKeyboardSceneDelegate:onBehalfOfResponder:duringBlock:] + 96 32 UIKitCore 0x290f70 ___UIViewControllerTransitioningRunCustomTransition_block_invoke_2 + 196 33 UIKitCore 0x1d8c8c +[UIView(Animation) _setAlongsideAnimations:toRunByEndOfBlock:] + 180 34 UIKitCore 0x1d851c _UIViewControllerTransitioningRunCustomTransition + 484 35 UIKitCore 0x6f5a84 -[UINavigationController _startCustomTransition:] + 3292 36 UIKitCore 0x1182a8 -[UINavigationController _startDeferredTransitionIfNeeded:] + 496 37 UIKitCore 0x1179a0 -[UINavigationController __viewWillLayoutSubviews] + 96 38 UIKitCore 0x117904 -[UILayoutContainerView layoutSubviews] + 172 39 UIKitCore 0x3297c -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1528 40 QuartzCore 0x66aa8 CA::Layer::layout_if_needed(CA::Transaction*) + 500 41 QuartzCore 0x66630 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 144 42 QuartzCore 0x6cb60 CA::Context::commit_transaction(CA::Transaction*, double, double*) + 464 43 QuartzCore 0x65e3c CA::Transaction::commit() + 648 44 QuartzCore 0x65ae4 CA::Transaction::flush_as_runloop_observer(bool) + 88 45 CoreFoundation 0x3583c __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 36 46 CoreFoundation 0x34244 __CFRunLoopDoObservers + 548 47 CoreFoundation 0x33960 __CFRunLoopRun + 1028 48 CoreFoundation 0x33478 CFRunLoopRunSpecific + 608 49 GraphicsServices 0x34f8 GSEventRunModal + 164 50 UIKitCore 0x22c62c -[UIApplication _run] + 888 51 UIKitCore 0x22bc68 UIApplicationMain + 340 52 MyApp 0x46a040 main + 44 (AppDelegate.swift:44) 53 ??? 0x1c8d52dcc (缺少) Questions / Requests Recommended patterns for in-app language switching (LTR ⇄ RTL) to avoid direction/constraint races during animations? For example: Should semantic direction be applied to the window/root view controller only? Should we avoid rebuilding root during an active transition? Any suggested synchronization (e.g., wait for transitions to finish) or APIs to call after rebuilding?

In third-party keyboard app, the app is crashed when call [[UIInputViewController textDocumentProxy] keyboardAppearance]. Environment) iOS 26 crash dump call stack Thread 0 Crashed: 0 libobjc.A.dylib 0x0000000198433008 objc_msgSend + 8 1 UIKitCore 0x00000001a1cea570 -[_UITextDocumentInterface _controllerState] + 68 2 UIKitCore 0x00000001a1ceaef0 -[_UITextDocumentInterface documentIdentifier] + 20 3 ThirtPartyKeyboardApp 0x0000000104aad190 -[NKBKeyboardViewController _updateThemeCenterAppearanceModeIfNeeds] + 56 (NKBKeyboardViewController.m:164)

After installing the app from App Store or TestFlight, when the user opens the app and then force-kills it multiple times, the app sometimes gets permanently stuck on a black screen at launch. This issue does NOT happen on Flutter 3.24.5 — works perfectly on all tested iOS devices. The problem started only after migrating to Flutter 3.35.6. This issue happens only in real production installs (App Store / TestFlight). It does not reproduce in Debug mode or through Xcode run / Android Studio run. Expected behavior App should show native splash → render Flutter UI normally. Actual behavior Sometimes after killing the app repeatedly: Native splash shows briefly → then screen turns completely black and stays stuck Steps to Reproduce: Install the app from App Store or TestFlight Launch the app Force-kill the app using app switcher Repeat launch + kill multiple times After 3–7 attempts, app gets stuck on black screen on launch Is this a known issue with the latest Flutter iOS engine? Could this be related to Flutter engine warm-up, pre-warming isolates, or native splash transition? Is there any recommended fix or workaround on iOS side? (e.g., ApplicationDidBecomeActive callbacks, UIWindow setup, GPU thread rendering flush, etc.)

I am encountering an issue where I am unable to install the app from TestFlight. The installation fails or does not proceed as expected. Please advise on how this can be resolved. I have tried restarting the device and reinstalling TestFlight and reinvite the users but the problem persists.

I’m experiencing an issue after building the project with Xcode 26.1.1. In my code, I have a UICollectionView that contains multiple cells, and each cell has a slider. When I move a slider in one cell, sliders in other cells also move. This issue does not occur in Xcode 16.4 – it works perfectly there. If anyone has a solution or knows if this is related to Xcode 26 changes, please let me know. Thanks!

iOS BGProcessingTask + Background Upload Not Executing Reliably on TestFlight (Works in Debug) Description: We are facing an issue with BGTaskScheduler and BGProcessingTask when trying to perform a background audio-upload flow on iOS. The behavior is inconsistent between Debug builds and TestFlight (Release) builds. Summary of the Problem Our application records long audio files (up to 1 hour) and triggers a background upload using: BGTaskScheduler BGProcessingTaskRequest Background URLSession (background with identifier) URLSession background upload task + AppDelegate.handleEventsForBackgroundURLSession In Debug mode (Xcode → Run on device), everything works as expected: BGProcessingTask executes handleEventsForBackgroundURLSession fires Background URLSession continues uploads reliably Long audio files successfully upload even when the app is in background or terminated However, in TestFlight / Release mode, the system does not reliably launch the BGProcessingTask or Background URLSession events. Technical Details We explicitly register BGTaskScheduler: BGTaskScheduler.shared.register( forTaskWithIdentifier: "example.background.process", using: nil ) { task in self.handleBackgroundProcessing(task: task as! BGProcessingTask) } We schedule it using: let request = BGProcessingTaskRequest(identifier: "example.background.process") request.requiresNetworkConnectivity = true request.requiresExternalPower = false try BGTaskScheduler.shared.submit(request) We also use Background URLSession: let config = URLSessionConfiguration.background(withIdentifier: sessionId) config.sessionSendsLaunchEvents = true config.isDiscretionary = false AppDelegate.handleEventsForBackgroundURLSession is implemented correctly and works in Debug. Issue Observed (TestFlight Only) In TestFlight builds: BGProcessingTask rarely triggers, or the system marks it as NO LONGER RUNNING. Background upload tasks sometimes never start or complete. No logs appear from our BGProcessingTask handler. system logs show messages like: NO LONGER RUNNING bgProcessing-example.background.process Tasks running in group [com.apple.dasd.defaultNetwork] are 1! This occurs most frequently for large audio uploads (30–60 minutes), while small files behave normally. What We Have Verified Proper Info.plist values: Permitted background modes: processing, audio, fetch BGTaskSchedulerPermittedIdentifiers contains our identifier BGProcessingTask is being submitted successfully (no errors) App has microphone permission + background audio works Device plugged/unplugged doesn’t change outcome Key Question for Apple We need clarification on: Why BGProcessingTask behave differently between Debug and TestFlight builds? Are there additional restrictions or heuristics (related to file size, CPU usage, runtime, network load, or power constraints) that cause BGProcessingTask to be throttled or skipped in Release/TestFlight? How can we guarantee a background upload continues reliably for large files (100MB–500MB) on TestFlight and App Store builds? Is there an Apple-recommended pattern to combine BGProcessingTask + Background URLSession for long-running uploads? Expected Result Background uploads should continue reliably for long audio files (>30 minutes) when the app goes to background or is terminated, in the same way they currently function in Debug builds.

Description of the current implementation: A section, UIView, has been added to UITableView. This section is a UICollectionView that displays an array of images. Each UICollectionViewCell is an image displayed via a UIImageView. Issue: When UITableView is scrolled vertically, the section with the image collection flickers. Attempts made to solve the problem: if #available(iOS 26.0, *) { tableView.bottomEdgeEffect.isHidden = true tableView.topEdgeEffect.isHidden = true tableView.leftEdgeEffect.isHidden = true tableView.rightEdgeEffect.isHidden = true } else { // Fallback on earlier versions } This helped with a similar issue. I tried it on UITableView and UICollectionView, but it didn't work.

I am experiencing a critical issue with my TestFlight builds and the App Store Connect submission process. I need urgent assistance as all my testing builds are currently expired. To fix the expiration, I increased the build number to Build 5 (Version 1.0.3) and uploaded it. I then tried to Submit for Review. The submission process failed, and I received an error message Has anyone experienced a widespread issue like this recently? What steps can I take to troubleshoot the submission error, and why would all my builds expire simultaneously, just days after a new upload? Thank you for your help!

My app allows to save user-selected URLs in a list and browse them with a tap. A user reported that the app often shows that when browsing their saved entry for "On My iPad", it's apparently empty (it contains no files). I saved "On My iPad" in my own list some time ago and noticed that the same issue occurs. The URL seems to be correctly resolved from the saved bookmark data, but I noticed that url.startAccessingSecurityScopedResource() returns false. The other URL I saved some time ago is iCloud Drive, which I can access without issues. If I select "On My iPad" again in a file importer, create new bookmark data from it and resolve the URL from it, access works correctly. I create bookmark data like this: let data = try url.bookmarkData(includingResourceValuesForKeys: [.localizedNameKey, .pathKey, .volumeIsLocalKey]) and resolve URLs like this: let url = try URL(resolvingBookmarkData: data, bookmarkDataIsStale: &bookmarkDataIsStale) bookmarkDataIsStale is false for both the working and not working URLs for "On My iPad". The two bookmark data are different though, even if url.path is the same. What could be the issue?

I'm building a progressive web app (PWA) and came to the conclusion that almost nobody knows that this feature exists - Add to Home Screen. Not many people even understand what a PWA is or that you can add it to the home screen. This feels unnatural compared to installing an app from a store. Why do we make it so hard for users? Could we not make this easier by having the ability to call this installation or show an install notification? Right now, when users visit a PWA on iOS, there's no way for developers to let them know they can install it. The "Add to Home Screen" option is tucked away in the Share menu, and most users never find it. I'd really like to be able to show them a friendly prompt. Comparing to other browsers, this is possible via the beforeinstallprompt event. This would make a huge difference for user experience. Right now the only way is to show iOS users a separate set of instructions with screenshots, which feels clunky compared to what's possible on other platforms. I'm curious - is there any reason why this hasn't been added to Safari yet? Other browsers have supported this for years now. Is there any progress being made on this, or is it being considered for the roadmap? It would be really helpful to know if this is something that will be worked on in the future. I know there's a lot on the roadmap, but this would really help developers create better installation experiences for our users. Thanks for considering this!

We are observing an issue where the iOS Notification Service Extension (NSE) is terminated by the system during startup, before either didReceive(_:withContentHandler:) or serviceExtensionTimeWillExpire(_:) is invoked. When this occurs, the notification is delivered without modification (for example, an encrypted payload is shown to the user). System logs frequently contain the message “Extension will be killed because it used its runtime in starting up”. During testing, we observed that CPU-intensive operations or heavy initialization performed early in the extension lifecycle — especially inside init() or directly on the main thread in didReceive often cause the system to kill the NSE almost immediately. These terminations happen significantly earlier than the commonly observed ~30-second execution window where the OS normally invokes serviceExtensionTimeWillExpire(_:) before ending the extension. When these early terminations occur, there is no call to the expiry handler, and the process appears to be forcefully shut down. Moving the same operations to a background thread changes the behavior: the extension eventually expires around the usual 30-second window, after which the OS calls serviceExtensionTimeWillExpire(_:). We also observed that memory usage plays a role in early termination. During tests involving large memory allocations, the system consistently killed the extension once memory consumption exceeded a certain threshold (in our measurements, this occurred around 150–180 MB). Again, unlike normal time-based expiration, the system did not call the expiry handler and no crash report was produced. Since Apple’s documentation does not specify concrete CPU, memory, or startup-cost constraints for Notification Service Extensions or any other extensions beyond the general execution limit, we are seeking clarification and best-practice guidance on expected behaviors, particularly around initialization cost and the differences between startup termination. NSE Setup: class NotificationService: UNNotificationServiceExtension { static var notificationContentHandler: ((UNNotificationContent) -> Void)? static var notificationContent: UNMutableNotificationContent? static var shoudLoop = true override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) { NotificationService.notificationContentHandler = contentHandler NotificationService.notificationContent = request.content.mutableCopy() as? UNMutableNotificationContent NotificationService.notificationContent!.title = "Weekly meeting" NotificationService.notificationContent!.body = "Updated inside didReceive" // Failing scenarios } override func serviceExtensionTimeWillExpire() { NotificationService.shoudLoop = false guard let handler = NotificationService.notificationContentHandler, let content = NotificationService.notificationContent else { return } content.body = "Updated inside serviceExtensionTimeWillExpire()" handler(content) } }

Broken TabView + NavigationStacks functionality on iOS 26.1. Even the most basic navigation made impossible. Example: TabView { Tab(...) { NavigationStack(path: $homePath) { HomeView() .navigationDestination { ... } } } Tab(...) { NavigationStack(path: $settingsPath) { SettingsView() .navigationDestination { ... } } } } Anything passed to settingsPath is just ignored and would never appear onscreen. (26.0 and prior versions work as expected.) Are there any workarounds?

we have uploaded only 1 app a day to testflight for the past 12 days, however for past 2 days I am unable to upload any files via transporter app, and getting the below error iOS issue : Validation failed (409) Upload limit reached. The upload limit for your account has been reached. Please wait 1 day and try again.

I implemented BGContinuedProcessingTask in my app and it seems to be working well for everyone except one user (so far) who has reached out to report nothing happens when they tap the Start Processing button. They have an iPhone 12 Pro Max running iOS 26.1. Restarting iPhone does not fix it. When they turn off the background processing feature in the app, it works. In that case my code directly calls the function to start processing instead of waiting for it to be invoked in the register block (or submit catch block). Is this a bug that's possible to occur, maybe device specific? Or have I done something wrong in the implementation? func startProcessingTapped(_ sender: UIButton) { if isBackgroundProcessingEnabled { startBackgroundContinuedProcessing() } else { startProcessing(backgroundTask: nil) } } func startBackgroundContinuedProcessing() { BGTaskScheduler.shared.register(forTaskWithIdentifier: taskIdentifier, using: .main) { @Sendable [weak self] task in guard self != nil else { return } startProcessing(backgroundTask: task as? BGContinuedProcessingTask) } let request = BGContinuedProcessingTaskRequest(identifier: taskIdentifier, title: title, subtitle: subtitle) request.strategy = .fail if BGTaskScheduler.supportedResources.contains(.gpu) { request.requiredResources = .gpu } do { try BGTaskScheduler.shared.submit(request) } catch { startProcessing(backgroundTask: nil) } } func startProcessing(backgroundTask: BGContinuedProcessingTask?) { // FIXME: Never called for this user when isBackgroundProcessingEnabled is true }

90714: Invalid binary. The app contains one or more corrupted binaries. Please rebuild the app and resubmit. 我开发的OC项目，三个月前打包分发还没有问题，半个月前开始就一直报这个错。查了很多资料都无法解决，所有的SDK也都升级了，还是报这个错，麻烦Apple的工程师帮忙指正一下问题，如何解决这个问题。