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.

Hi everyone, I’ve filed a Feedback report (FB20986470) for a serious issue affecting the Call Directory database when add phone numbers for call blocking. When adding blocking numbers to a Call Directory extension, the system’s CallKit database (/private/var/mobile/Library/CallDirectory/CallDirectory.db) becomes corrupted. The reload call (reloadExtensionWithIdentifier) fails with error code 11 when the system tries to insert blocking entries, and the Console app on macOS shows the following errors: database corruption page 2265525 of /private/var/mobile/Library/CallDirectory/CallDirectory.db at line 81343 of [f0ca7bba1c] database corruption at line 79387 of [f0ca7bba1c] Error Domain=com.apple.callkit.database.sqlite Code=11 "sqlite3_step for query 'INSERT INTO PhoneNumberBlockingEntry (extension_id, phone_number_id) VALUES (?, (SELECT id FROM PhoneNumber WHERE (number = ?))), (?, (SELECT id FROM PhoneNumber WHERE (number = ?))),...)'" After this happens, CallKit becomes fully corrupted on the device and no further numbers can be added, even after: Disabling and re-enabling the extension Restarting the device (either force or soft restart) Reinstalling the app Waiting for a couple of minutes after this issue happens (that CallKit could possibly self-recovered) I also tested other call-blocking apps, and they all fail with the same error. The only thing that recovers the system is a full “Reset All Settings.” This issue has been reported by many users of my app, across multiple iOS versions and devices. Similar related issue reported by another developer: https://developer.apple.com/forums/thread/806129 Steps to Reproduce: Enable the Call Directory extension from a call-blocking app. Add and reload blocking numbers (a few thousand entries). Perform multiple reloads between additions. Check the Console, the corruption errors appear. From this point, all insert attempts fail system-wide. Expected Result: Entries should be inserted successfully, or the system should self-recover without persistent corruption. Actual Result: sqlite3_step fails with Code=11, and the Call Directory database remains corrupted until the user resets all settings. Additional Notes: All numbers are sorted and deduplicated before insertion. Happens intermittently after multiple reloads. The system log always shows internal database failure. Environment: Device: iPhone 16 Plus iOS 18.2 Beta (23C5027f) Xcode 16.1 (17B55) Attachments (included in Feedback FB20986470): sysdiagnose captured immediately after the failure (with Phone app General Profile) It seems like a system-level corruption affecting all Call Directory extensions once it occurs.

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?

Hi Is there a way to create a dynamic app clip card experience? I have advanced app clip experiences set up and working fine already and but I am looking to provider a more dynamic experience. For example, my invocation url now is https://mycompany.com/profile/<profile_slug>, this URL shows the app clip card with the title, subheading, and cover image as configured in app store connect which is right. But I would like to show a different title, subheading, and cover image based on the <profile_slug> in the invocation URL. Like we can show the name as the title, job title as the subheading, and profile's banner image as the cover image for the app clip It seems like this is possible as I have seen one company do this for their product. Apple has no mention for such a thing in their documentation from what I have seen. Any help would be appreciated. Thanks

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?

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.)

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)

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.

Hi Apple, Currently we want to have enhancement for SMS OTP that we want to implement OTP Autofill, But after do some research we're stuck with option that the OTP only show in keyboard suggestion, is there any way for making OTP is automatically filled without user have to click the keyboard suggestion when receiving the SMS. Thanks Best Regards, Admiral Sultano Harly.

For a long time our app had this creation of a URLRequest: var urlRequest = URLRequest(url: url, cachePolicy: .reloadIgnoringLocalAndRemoteCacheData, timeoutInterval: timeout) But since iOS 26 was released we started to get crashes in this call. It is created on a background thread. Thread 10 Crashed: 0 libsystem_malloc.dylib 0x00000001920e309c _xzm_xzone_malloc_freelist_outlined + 864 (xzone_malloc.c:1869) 1 libswiftCore.dylib 0x0000000184030360 swift::swift_slowAllocTyped(unsigned long, unsigned long, unsigned long long) + 56 (Heap.cpp:110) 2 libswiftCore.dylib 0x0000000184030754 swift_allocObject + 136 (HeapObject.cpp:245) 3 Foundation 0x00000001845dab9c specialized _ArrayBuffer._consumeAndCreateNew(bufferIsUnique:minimumCapacity:growForAppend:) + 120 4 Foundation 0x00000001845daa58 specialized static _SwiftURL._makeCFURL(from:baseURL:) + 2288 (URL_Swift.swift:1192) 5 Foundation 0x00000001845da118 closure #1 in _SwiftURL._nsurl.getter + 112 (URL_Swift.swift:64) 6 Foundation 0x00000001845da160 partial apply for closure #1 in _SwiftURL._nsurl.getter + 20 (<compiler-generated>:0) 7 Foundation 0x00000001845da0a0 closure #1 in _SwiftURL._nsurl.getterpartial apply + 16 8 Foundation 0x00000001845d9a6c protocol witness for _URLProtocol.bridgeToNSURL() in conformance _SwiftURL + 196 (<compiler-generated>:974) 9 Foundation 0x000000018470f31c URLRequest.init(url:cachePolicy:timeoutInterval:) + 92 (URLRequest.swift:44)# Live For Studio Any idea if this crash is caused by our code or if it is a known problem in iOS 26? I have attached one of the crash reports from Xcode: 2025-10-08_10-13-45.1128_+0200-8acf1536892bf0576f963e1534419cd29e6e10b8.crash

Hello, When using ASWebAuthenticationSession with an HTTPS callback URL (Universal Link), I receive the following error: Authorization error: The operation couldn't be completed. Application with identifier jp.xxxx.yyyy.dev is not associated with domain xxxx-example.go.link. Using HTTPS callbacks requires Associated Domains using the webcredentials service type for xxxx-example.go.link. I checked Apple’s official documentation but couldn’t find any clear statement that webcredentials is required when using HTTPS callbacks in ASWebAuthenticationSession. What I’d like to confirm: Is webcredentials officially required when using HTTPS as a callback URL with ASWebAuthenticationSession? If so, is there any official documentation or technical note that states this requirement? Environment iOS 18.6.2 Xcode 16.4 Any clarification or official references would be greatly appreciated. Thank you.

I’m integrating the Declared Age Range feature to tailor our app’s experience based on a user’s age range. I’m currently in the testing phase and would like to repeatedly test the consent flow and different outcomes from AgeRangeService.shared.requestAgeRange(...). However, once I go through the consent flow and choose to share, the age-range sharing sheet no longer appears on subsequent attempts—so it’s hard to validate edge cases (e.g., changed gates, declined flow, re-prompt behavior). Could you advise on the recommended way to reset or re-prompt during development? In particular: Is there a supported way to clear per-app consent so the system prompts again? Under what conditions should the “Share Age Range Again” control appear in Settings, and is there an equivalent way to trigger it for testing? Are there best practices for QA (e.g., using Ask First at the system level, testing on real devices vs. Simulator, using a separate bundle ID for dev builds, or other steps)? Any other guidance for validating different requestAgeRange results (e.g., declined/not available) would be appreciated.

I'm trying to digest and understand the new set of APIs relating age verification that were released last week. I have say that without some cohesive overview, example app, just a simple diagram showing the relationship of everything, its not at all clear to me what's going on nor what an app developer is expected to do to use these apis (I'm a senior engineer with 15 year's iOS experience, but hey maybe I'm just a bit slow in the head). I have a few questions, but the topic of this post is what is the relationship between age verification i.e. between the declared age range/significant change and Permission Kit? The documentation for the former mentions the Significant Change API/Topic (https://developer.apple.com/news/?id=2ezb6jhj / https://developer.apple.com/documentation/PermissionKit/SignificantAppUpdateTopic). Now the Significant Change Topic is documented as being part of PermissionKit, however the documentation for that (https://developer.apple.com/documentation/permissionkit) States emphatically at the top: "Communication experiences using the PermissionKit framework are only available using iMessage." Meaning you can't use PermissionKit for anything other than iMessage? If it doesn't mean that, then why does it state so? If it does mean that, then how does an app which has nothing to do with iMessage make use of Significant Change - because this documentation:https://developer.apple.com/news/?id=2ezb6jhj Is talking about using significant change for all apps, not iMessage. So there is a contradiction here.

I have a UICollectionView using a UICollectionViewCompositionalLayout with an orthogonally scrolling section. When selecting a cell, I present a modal view controller with a zoom transition. If I scroll quickly in that section after dismissing the presented view controller, the cells briefly overlap. See the attached screenshot. This issue occurs only on iOS 26 and does not occur on iOS 18. Has anyone found a way to mitigate this? Sample project: https://github.com/antiraum/iOS26_UICollectionViewZoomTransitionIssue Feedback FB21022192

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!

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 }

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.

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) } }

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.