Our iOS app supports CarPlay capability with the Driving task. The app is also configured to wake in the background on geofence entry or exit events, even from a terminated (killed) state. We would like to understand how to detect whether CarPlay is connected to the iPhone when the app wakes up or runs in the background. In this case, the CarPlay app is not actively running in the Car infotainment system foreground. Requirement: The app should perform a background task only when CarPlay is connected, including when launched in the background or from a killed state due to a geofence trigger. Could you please advise on the recommended way or API to determine CarPlay connection status in this background scenario? Thanks for the support!

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

I hope you are doing well. I am reaching out to follow up regarding my app, which has been under App Review for an unusually long period of time. I have contacted Apple Developer Support several times through both phone calls and emails, but so far, there has been no effective resolution or progress. Below are the case references from the last few weeks: • Case ID: 102741157121 — App Store Connect Users and Roles • Case ID: 102745063464 — Program Enrolment • Case ID: 102744897406 — Other Membership or Account Questions • Case ID: 102742872512 — App Review Status • Case ID: 102742874797 — App Review Status • Case ID: 102743079324 — Developer Team Management • Case ID: 102738804525 — Feedback and Other Topics • Case ID: 102735998715 — Agreements and Contracts • Case ID: 102735996938 — App Review Status • Case ID: 102725767721 — Other App Review Questions • Case ID: 102725766192 — App Review Status • Case ID: 102729318336 — My Issue Is Not Listed • Case ID: 102723997813 — Program Enrolment As you can see, I have made numerous attempts to resolve this matter, yet I have not received any concrete response or outcome. My app continues to remain in the “In Review” state without any progress or communication from your team. This repeated delay is affecting my project timeline and business operations. I respectfully request that this issue be escalated to a senior App Review specialist or higher-level reviewer who can take direct action. Please review the above case history and provide a clear resolution or update at the earliest possible. Thank you for your attention and understanding.

All of these issues appear when the search controller is set on the view controller's navigationItem and the search controller's searchBar has its scopeButtonTitles set. So far the following issues are affecting my app on iOS/iPadOS 26 as of beta 7: When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .integratedButton, and the searchBarPlacementAllowsToolbarIntegration is set to false (forcing the search icon to appear in the nav bar), on both iPhones and iPads, the scope buttons never appear. They don't appear when the search is activated. They don't appear when any text is entered into the search bar. FB19771313 I attempted to work around that issue by setting the scopeBarActivation to .manual. I then show the scope bar in the didPresentSearchController delegate method and hide the scope bar in the willDismissSearchController. On an iPhone this works though the display is a bit clunky. On an iPad, the scope bar does appear via the code in didPresentSearchController, but when any scope bar button is tapped, the search controller is dismissed. This happens when the app is horizontally regular. When the app on the iPad is horizontally compact, the buttons work but the search bar's text is not correctly aligned within the search bar. Quite the mess really. I still need to post a bug report for this issue. But if issue 1 above is fixed then I don't need this workaround. When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .stacked, and the hidesSearchBarWhenScrolling property of the navigationItem is set to false (always show the search bar), and this is all used in a UITableViewController, then upon initial display of the view controller on an iPhone or iPad, you are unable to tap on the first row of the table view except on the very bottom of the row. The currently hidden scope bar is stealing the touches. If you activate and then cancel the search (making the scope bar appear and then disappear) then you are able to tap on the first row as expected. The initially hidden scope bar also bleeds through the first row of the table. It's faint but you can tell it's not quite right. Again, this is resolved by activating and then canceling the search once. FB17888632 When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to integrated or .integratedButton, and the toolbar is shown, then on iPhones (where the search bar/icon appears in the toolbar) the scope buttons appear (at the top of the screen) the first time the search is activated. But if you cancel the search and then activate it again, the search bar never appears a second (or later) time. On an iPad the search bar/icon appears in the nav bar and you end up with the same issue as #1 above. FB17890125 Issues 3 and 4 were reported against beta 1 and still haven't been fixed. But if issue 1 is resolved on iPhone, iPad, and Mac (via Mac Catalyst), then I personally won't be affected by issues 2, 3, or 4 any more (but of course all 4 issues need to be fixed). And by resolved, I mean that the scope bar appears and disappears when it is supposed to each and every time the search is activated and cancelled (not just the first time). The scope bar doesn't interfere with touch events upon initial display of the view controller. And there are no visual glitches no matter what the horizontal size class is on an iPad. I really hope the UIKit team can get these resolved before iOS/iPadOS 26 GM.

In our app, there is a UIWindow makeKeyAndVisible crash, and for now, it appears once, crash stack: the crash detail: crash.txt in the RCWindowSceneManager class's makeWindowKeyAndVisible method, we check and set a window's windowScene and makeKeyAndVisible: public func makeWindowKeyAndVisible(_ window: UIWindow?) { guard let window else { return } if let currentWindowScene { if window.windowScene == nil || window.windowScene != currentWindowScene { window.windowScene = currentWindowScene } window.makeKeyAndVisible() } } and I set a break point at a normal no crash flow, the stack is: why it crash? and how we avoid this, thank you.

Our iOS/iPad app is built with React Native. We use Axios as our HTTP client. Our app has been out on the app store for 2+ years and we've never had issues with reviews. Since iOS 26 came out, our app has been constantly getting rejected because the Apple tester keeps facing network timeout issues when our app makes requests to our API services. Our API stack is already configured to support IPv6 networks, and our regular user base does not run into the issues the Apple tester is seeing. None of our developers nor our internal testers have been able to reproduce the issue the Apple tester is facing. We've tried a number of things to debug the potential issue: Added a ping check on app startup. We used the native fetch present in React Native apps as well as our Axios client (with the default XHR/HTTP adapter). None of the pings make it to our API services. Added higher timeouts on app startup to let the Apple tester have more time to reach our services while their simulator device is able to connect. We've read that the environment that Apple testers use can sometimes take longer to establish an initial connection, even though packages like NetInfo from React Native report that they are connected to WiFi as soon as the app starts. Switched our Axios client adapter to use the native fetch. We did this since we noticed that Mixpanel, our tracking library, uses the native fetch in their React Native SDK and we've confirmed that requests on their end do make it through when the Apple tester is testing our app. We're running out of ideas since the issue is pretty obscure and we haven't been able to reproduce it yet, not even by following the Apple guide to set up a local IPv6 NAT64 network to be as close to their environment as possible. We've also tried testing the app while connected to VPNs from different locations to no avail. Like I said before, we noticed that this issues started for the Apple tester with the release of iOS 26, so we're wondering if there are known issues in the community that might relate to what we're experiencing. The most recent finding we've made is that some other developers report new issues with HTTP 3/QUIC on iOS. We've seen recommendations about turning off explicit support for HTTP 3 on our services, which seems to have helped other developers.

On this page: https://developer.apple.com/documentation/storekit/testing-age-assurance-in-sandbox It says: Start with a Sandbox account. What is a Sandbox account and how does one set one up? Just it just simply mean an Apple account id used for testing, or something else?

This is really odd. If you setup a UISearchController with a preferredSearchBarPlacement of .stacked and you setup the search bar with scope buttons, then when the view controller is initially displayed, the currently hidden scope buttons block touch events from reaching the main view just below the search bar. But once the search is activated and dismissed, then the freshly hidden scope buttons no longer cause an issue. This is easily demonstrated by putting a UITableViewController in a UINavigationController. Setup the table view to show a few simple rows. Then setup a search controller using the following code: func setupSearch() { // Setup a stacked search bar with scope buttons // Before the search is ever activated, the hidden scope buttons block any touches in the main view controller // in the area just below the search bar. // Once the search is activated and dismissed, the problem goes away. It seems that displaying and hiding the // scope buttons at least once fixes the issue that exists beforehand. // This issue only exists in iOS/iPadOS 26, not iOS/iPadOS 18 or earlier. let search = UISearchController(searchResultsController: UIViewController()) search.hidesNavigationBarDuringPresentation = true search.obscuresBackgroundDuringPresentation = true search.scopeBarActivation = .onSearchActivation // Ensure button appear immediately let searchBar = search.searchBar searchBar.scopeButtonTitles = [ "One", "Two", "Three" ] self.navigationItem.searchController = search self.navigationItem.hidesSearchBarWhenScrolling = false // Issue appears even if this is true self.navigationItem.preferredSearchBarPlacement = .stacked } When first shown, before any attempt is made to activate the search, any attempt to tap on the upper 2/3 of the first row in the table view (which is just below the search bar) fails. If you tap on the lower 1/3 of the first row it works fine. If you then activate the search (now the scope buttons appear) and then dismiss the search (now the scope buttons are hidden again), then there is no issue tapping anywhere on the first row of the table. But if you restart the app, the problem starts over again. This problem happens on any iPhone or iPad, real or simulated, running iOS/iPadOS 26 RC. This is a regression from iOS 18 or earlier.

Light shining effects can repeatedly be observed on older iPhone devices (12/13/14). This change is often seen after the device is rebooted or after a SystemMemoryReset.ips (System Analysis Data). It changes very often...

I've being playing aground with long press gesture in scroll view and noticed gesture(LongPressGesture()) doesn't seem to work with scroll view's scrolling which doesn't seem to be the intended behavior to me. Take the following example: the blue rectangle is modified with onLongPressGesture and the red rectangle is modified with LongPressGesture (_EndedGesture<LongPressGesture> to be specific). ScrollView { Rectangle() .fill(.blue) .frame(width: 200, height: 200) .onLongPressGesture { print("onLongPressGesture performed") } onPressingChanged: { _ in print("onLongPressGesture changed") } .overlay { Text("onLongPressGesture") } Rectangle() .fill(.red) .frame(width: 200, height: 200) .gesture(LongPressGesture() .onEnded { _ in print("gesture ended") }) .overlay { Text("gesture(LongPressGesture)") } } If you start scrolling from either of the rectangles (that is, start scrolling with your finger on either of the rectangles), the ScrollView will scroll. However, if LongPressGesture is modified with either onChanged or .updating, ScrollView won't respond to scroll if the scroll is started from red rectangle. Even setting the maximumDistance to 0 won't help. As for its counter part onLongPressGesture, even though onPressingChanged to onLongPressGesture, scrolling still works if it's started from onLongPressGesture modified view. ScrollView { Rectangle() .fill(.blue) .frame(width: 200, height: 200) .onLongPressGesture { print("onLongPressGesture performed") } onPressingChanged: { _ in print("onLongPressGesture changed") } .overlay { Text("onLongPressGesture") } Rectangle() .fill(.red) .frame(width: 200, height: 200) .gesture(LongPressGesture(maximumDistance: 0) // scroll from the red rectangle won't work if I add either `updating` or `onChanged` but I put both here just to demonstrate // you will need to add `@GestureState private var isPressing = false` to your view body .updating($isPressing) { value, state, transaction in state = value print("gesture updating") } .onChanged { value in print("gesture changed") } .onEnded { _ in print("gesture ended") }) .overlay { Text("gesture(LongPressGesture)") } } This doesn't seem right to me. I would expect the view modified by LongPressGesture(), no matter if the gesture has onChanged or updating, should be able to start scroll in a scroll view, just like onLongPressGesture. I observed this behavior in a physical device running iOS 26.1, and I do not know the behavior on other versions.

When my Bluetooth peripheral device has both HID and MIDI services, the iOS Bluetooth host repeatedly sends different "Control Opcode: LL_CONNECTION_UPDATE_IND" to the peripheral, updating approximately every 100ms. The Bluetooth peripheral cannot handle such high-frequency update requests and typically disconnects with an error 0x28. My Bluetooth device uses the NRF52832 chip, and I have communicated with NORDIC and replicated this issue. This problem only occurs on iOS 26; it does not happen on earlier versions. I think it might be caused by the HID service in iOS requesting faster connection parameters for low latency, which then gets erroneously reverted for an unknown reason, leading to repeated competition and entering into a deadlock. Here is the communication record with NORDIC: https://devzone.nordicsemi.com/f/nordic-q-a/124994/ios-26-bluetooth-disconnect-issues This is the screenshot captured using the Bluetooth sniffer:

We are preparing to implement document signing using USB tokens on iOS and macOS. Several other applications already support this feature. From my testing and development efforts, I've been unable to reliably access or utilize certificates stored on a smartcard through the iOS APIs. Here are the specifics: Environment iOS: 15 and later Xcode: Versions 18 and 26 Smartcard/Token: ePass 2003 (eMudhra), Feitien token (Capricorn) Observed Issue : The token is recognized at the system level, with certificates visible in Keychain Access. However, programmatic access to the private keys on the smartcard from within the app is not working. Signing attempts result in Error 6985 and CACC errors. Approaches Tried: Updated provisioning profiles with the following entitlements: com.apple.developer.smartcard com.apple.security.device.usb TKSmartCard Employed TKSmartCard and TKSmartCardSession for interaction. The token is detected successfully. A session can be established, but there's no straightforward method to leverage it for certificate-based signing. Access to signing functions is unavailable; operations yield Error 6985 or CACC errors. if let smartCard = TKSmartCard(slot: someSlot) { smartCard.openSession { session, error in if let session = session { let command: [UInt8] = [0x00, 0xA4, 0x04, 0x00] session.transmit(Data(command)) { response, error in print("Response: \(String(describing: response))") print("Error: \(String(describing: error))") } } } } TokenKit (macOS/iOS) - Utilized TKTokenWatcher to identify available tokens on macOS (not available on iOS). watcher.setInsertionHandler { tokenID in print("Token detected: \(tokenID)") } CryptoKit / Security Framework - Attempted to retrieve SecCertificate using SecItemCopyMatching queries, which succeeded on macOS but failed on iOS. let query: [CFString: Any] = [ kSecClass: kSecClassCertificate, kSecReturnRef: true, kSecMatchLimit: kSecMatchLimitAll ] var items: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &items) print("Status: \(status)") // macOS succeeds, iOS fails ExternalAccessory Framework (EAAccessory) * Investigated using EAAccessory and EASession for external token communication, but it did not function as expected. This functionality is critical for my project. Has anyone successfully implemented smartcard-based signing on iOS? Any guidance, sample code, or references to relevant Apple documentation would be greatly appreciated.

I am developing an IOS App that allow users to scan rooms, view the scans on device, and add notes. I need to preserve actual geometry (odd angles, chamfers, fixtures), not simplified RoomPlan boxes. Are there any easy ways to incorporate high quality texture mapping or PBR? Where is the documentation for scene reconstruction?

Hi, we've observed a weird behavior for a small amount of our user that we keep receiving the same token from APNs despite it's shown as Unregistered. When we try to send push to the token, we got an Unregistered error so we remove that token from our server. However, later we would receive an add token request from the client with the same token we just removed, and when we try to send to the token it returns Unregistered again so we remove the token again. This happened 3 times for a user in an hour. The identifierForVendor remains the same for all the requests. We also owns the client and I've checked client code that it's sending the token it received from didRegisterForRemoteNotificationsWithDeviceToken to the server.

Starting with iOS 18, UITabBarController no longer updates tab bar item titles when localized strings are changed or reassigned at runtime. This behavior worked correctly in iOS 17 and earlier, but in iOS 18 the tab bar titles remain unchanged until the app restarts or the view controller hierarchy is reset. This regression appears to be caused by internal UITabBarController optimizations introduced in iOS 18. Steps to Reproduce Create a UITabBarController with two or more tabs, each having a UITabBarItem with a title. Localize the tab titles using NSLocalizedString(): tabBar.items?[0].title = NSLocalizedString("home_tab", comment: "") tabBar.items?[1].title = NSLocalizedString("settings_tab", comment: "") Run the app. Change the app’s language at runtime (without restarting), or manually reassign the localized titles again: tabBar.items?[0].title = NSLocalizedString("home_tab", comment: "") tabBar.items?[1].title = NSLocalizedString("settings_tab", comment: "") Observe that the tab bar titles do not update visually.

I would like to know whether BGContinuedProcessingTaskRequest supports executing asynchronous tasks internally, or if it can only execute synchronous tasks within BGContinuedProcessingTaskRequest? Our project is very complex, and we now need to use BGContinuedProcessingTaskRequest to perform some long-running operations when the app enters the background (such as video encoding/decoding & export). However, our export interface is an asynchronous function, for example video.export(callback: FinishCallback). This export call returns immediately, and when the export completes internally, it calls back through the passed-in callback. So when I call BGTaskScheduler.shared.register to register a BGContinuedProcessingTask, what should be the correct approach? Should I directly call video.export(nil) without any waiting, or should I wait for the export function to complete in the callback? For example: BGTaskScheduler.shared.register(forTaskWithIdentifier: "com.xxx.xxx.xxx.xxx", using: nil) { task in guard let continuedTask = task as? BGContinuedProcessingTask else { task.setTaskCompleted(success: false) return } let scanner = SmartAssetsManager.shared let semaphore = DispatchSemaphore(value: 0) continuedTask.expirationHandler = { logError(items: "xwxdebug finished.") semaphore.signal() } logInfo(items: "xwxdebug start！") video.export { _ in semaphore.signal() } semaphore.wait() logError(items: "xwxdebug finished！") }

I have the main app that saves preferences to UserDefaults.standard. So I have this one preference that the user is able to toggle - isRawOn UserDefaults.standard.set(self.isRawOn, forKey: "isRawOn") Now, I have LockedCameraCaptureExtension which is required know if that above setting on or off during launch. Also if it's toggled within the extension, the main app should know about it on the next launch. The main app and the extension runs on separate containers and the preferences are not shared due to privacy reasons. Apple mentions of using appContext of CameraCaptureIntent, but not sure how above scenario is possible through that....unless I am missing something. Apple Reference What I have for CameraCaptureIntent: @available(iOS 18, *) struct LaunchMyAppControlIntent: CameraCaptureIntent { typealias AppContext = MyAppContext static let title: LocalizedStringResource = "LaunchMyAppControlIntent" static let description = IntentDescription("Capture photos with MyApp.") @MainActor func perform() async throws -> some IntentResult { .result() } }

My app is a SwiftUI document based app using DocumentGroupLaunchScene. In iOS(iPadOS) 18.4, when it launches, it has duplicate toolbar items, and when I close the current document and open other documents, it adds more duplicates. It also shows a wrong document name, which shows the first opened document name. This issue can be reproduced in the sample code (Building a document-based app with SwiftUI). I have submitted Feedback (FB17025216), but not sure if this is a known bug or if I'm missing anything.

iPhone7 : iOS 14.0 Beta 5 Xcode-beta Mac OS : 10.15.5 (19F101) crash info : ** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[PHPhotoLibrary presentLimitedLibraryPickerFromViewController:]: unrecognized selector sent to instance xxxxxx' terminating with uncaught exception of type NSException my code: (void)viewDidAppear:(BOOL)animated {   [super viewDidAppear:animated];   if (@available(iOS 14, *)) {     [[PHPhotoLibrary sharedPhotoLibrary] presentLimitedLibraryPickerFromViewController:self];   } }

On iOS 18.0+ simulators, tap any share link button from any app, select "Save to Files", the "Save" button is disabled. In all previous simulator versions this works. This behavior even happens with default Apple apps like Photos. Simulator: Version 16.0 (1037) XCode: Version 16.1 beta (16B5001e) macOS: 14.6.1 (23G93)