On iOS 18 and lower version, my application supports automatically switching to [System settings - Personal Hotspot] directly. But on iOS 26, my application will be redirected to [System settings- Apps]. Does iOS 26 disable the behavior of directly jumping to the system hotspot page? If support, could you share the API for iOS 26?

iOS Intermittent Bug: UserDefaults Preferences Loading Issue Problem Summary We're experiencing an intermittent issue where UserPreferences.shared.preferences returns inconsistent values even after calling getPreferences(). The behavior is unpredictable and affects critical functionality. Environment iOS Version: 15+ Language: Objective-C with Swift interop Storage: UserDefaults with App Group (group.com.jci.tyco.glss) Architecture: Singleton pattern for UserPreferences (Swift class) The Issue When a push notification arrives and triggers the showEvent: method, user preferences are sometimes loaded correctly and sometimes return nil or default values: Scenario A (Works - ~60% of time): Scenario B (Fails - ~40% of time): Observed Pattern From extensive logging over multiple test runs: Key Observation: At app launch: Preferences often load successfully Seconds later when push arrives: Same preferences become unavailable User navigates to another screen and back: Preferences suddenly work again Code Structure Objective-C AppDelegate.m - (void)showEvent:(FMEvent *)event eventReadSource:(FMEventReadSourceType)eventSource { BOOL isUserRoleEndUser = [[FMUserRolesRepository instance] userRoleAvailable:FMUserRoleEndUser]; UserPreferences *userPrefs = [UserPreferences shared]; [userPrefs getPreferences]; // ← Called here // Immediately after, sometimes nil! bool hasFireAudio = [userPrefs.preferences.fireAudio.lowercaseString isEqual:@"true"]; NSLog(@"isUserRoleEndUser: %d | Fire Audio: %d", isUserRoleEndUser, hasFireAudio); // Decision logic based on preferences if ([FMConstants getUserRegion] == UserRegionUK && isUserRoleEndUser && userPrefs.preferences && // ← Sometimes nil here hasFireAudio) { // Show Screen A } else { // Show Screen B } } ```class UserPreferences: NSObject { static let shared = UserPreferences() var preferences: FMUserPreferencesInfo? // ← This becomes nil intermittently func getPreferences() { let userDefaults = UserDefaults(suiteName: "group.com.jci.tyco.glss") if let data = userDefaults?.data(forKey: "UserPreferences") { // Decode and set preferences self.preferences = // decoded object } else { // Create default preferences with fireAudio = "false" self.preferences = FMUserPreferencesInfo() } } }

Is there any way to forcibly disable using QUIC? I've noticed this ends up causing issues with our ISP / router, and noticed for many of our customers as well. Creating an ephemeral session doesn't change things, and setting the request to "assumeHttp3Capable" to false doesn't fix things either. We are using Cloudflare Workers as the URL we are hitting, and thus aren't able to disable this server-side.

I am currently encountering a problem: during the process of uploading a large file, I have moved the file that was not successfully uploaded to the trash can. These two operations have been tested to be serial (triggering the 'create Item' callback first, followed by the 'modify Item' callback), which means that the file must be uploaded before it can be moved to the recycle bin (which can also result in the file being stored in the cloud recycle bin). I want to implement: directly interrupt this upload process and then do not complete the upload. How can I achieve this? Please help me. Thank you

A user of one of my apps reported that since the update to macOS 26.1 they are no longer able to scan Macintosh HD: the app used to work, but now always reports that Macintosh HD contains a single empty file named .nofollow, or rather the path is resolved to /.nofollow. Initially I thought this could be related to resolving the file from the saved bookmark data, but even restarting the app and selecting Macintosh HD in an open panel (without resolving the bookmark data) produces the same result. The user tried another app of mine with the same issue, but said that they were able to scan Macintosh HD in other App Store apps. I never heard of this issue before and my apps have been on the App Store for many years, but it looks like I might be doing something wrong, or the APIs that I use are somehow broken. In all my apps I currently use getattrlistbulk because I need attributes that are not available as URLResourceKey in all supported operating system versions. What could be the issue? I'm on macOS 26.1 myself and never experienced it.

I try saving the value of NSURLVolumeURLKey when creating a bookmark. When resolving the bookmark later I pass the bookmark data to +resourceValuesForKeys:fromBookmarkData: but always pull out "file:///" which is wrong. In contrast the value for NSURLVolumeURLForRemountingKey is properly saved and restored using the same method.

Recently I noticed an app called “Lookus”. Even if I force‑kill it, it still seems to obtain information such as my charging status and network status, and it can even send real‑time notifications. I’m curious how this is technically possible. Does anyone know how this could be achieved?

I have an Xcode app where currently txt files in the project display text data as a list. I can search through the lists and have buttons that will swap between different lists of information that you can look through. The next task is I have URL connections to docx files on a SharePoint site. I am trying to use an URLsession function to connect to the URL links to download the documents to the document directory then have the application read the doc information to then be displayed as the txt info would. The idea is that the docx files are a type of online update version of the data. So when the app is used and on wifi, the app can update the list data with the docx files. I have code set up that should access the URL files but I am struggling to figure out how to read the data and access from this Documents directory. I have been looking online and so far I am at a loss on where to go here. If anyone can help or provide some insight I would greatly appreciate it. I can try and provide code samples to help explain things if that is needed.

"We are developing an application use case that requires us to prompt the user to restart their device. We plan to use the system uptime value provided by [NSProcessInfo processInfo].systemUptime to determine if a restart has occurred. Apple's documentation defines this API as 'The amount of time the system has been awake since the last time it was restarted.' Our questions are: Can we reliably use this API, in conjunction with persistent storage, to detect a device restart? Are there any known limitations or considerations when accessing or relying on this API while the application is running in the background?"

With the RC version of macOS 26, an issue persists when you try to create a bookmark with security scope for the root folder "/". This leads to an error "The file couldn’t be opened.". However, you can create bookmark for /Applications, /System, /Users... This is quite annoying for one of my app because a user can create a cartography of his disk usage, and the access to the root folder "/" is the only way to do so! Is there a workaround? PS: reported the issue with ID FB20186406 let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true openPanel.canChooseFiles = false openPanel.beginSheetModal(for: self.view.window!) { (result) in guard result == .OK, let folderURL = openPanel.url else { return } openPanel.close() do { let data = try folderURL.bookmarkData(options: .withSecurityScope, includingResourceValuesForKeys: nil, relativeTo: nil) print("Bookmark data was created for \(folderURL.path)") } catch (let error) { print("Error creating bookmark for \(folderURL.path), with error: \(error.localizedDescription)") } }

I've experimentally seen that the notifications(named:) API of NotificationCenter appears to buffer observed notifications internally. In local testing it appears to be limited to 8 messages. I've been unable to find any documentation of this fact, and the behavior seems like it could lead to software bugs if code is not expecting notifications to potentially be dropped. Is this behavior expected and documented somewhere? Here is a sample program demonstrating the behavioral difference between the Combine and AsyncSequence-based notification observations: @Test nonisolated func testNotificationRace() async throws { let testName = Notification.Name("TestNotification") let notificationCount = 100 var observedAsyncIDs = [Int]() var observedCombineIDs = [Int]() let subscribe = Task { @MainActor in print("setting up observer...") let token = NotificationCenter.default.publisher(for: testName) .sink { value in let id = value.userInfo?["id"] as! Int observedCombineIDs.append(id) print("🚜 observed note with id: \(id)") } defer { extendLifetime(token) } for await note in NotificationCenter.default.notifications(named: testName) { let id: Int = note.userInfo?["id"] as! Int print("🚰 observed note with id: \(id)") observedAsyncIDs.append(id) if id == notificationCount { break } } } let post = Task { @MainActor in for i in 1...notificationCount { NotificationCenter.default.post( name: testName, object: nil, userInfo: ["id": i] ) } } _ = await (post.value, subscribe.value) #expect(observedAsyncIDs.count == notificationCount) // 🛑 Expectation failed: (observedAsyncIDs.count → 8) == (notificationCount → 100) #expect(observedCombineIDs == Array(1...notificationCount)) print("done") }

I have an iOS app with ExtensionFoundation. It runs well on my local device, but when I upload on the AppStore it gets rejected with: Validation failed Invalid Info.plist value. The value of the EXExtensionPointIdentifier key, AsheKube.app.a-Shell.localWebServer, in the Info.plist of “a-Shell.app/Extensions/localWebServer.appex” is invalid. Please refer to the App Extension Programming Guide at https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/Action.html#/apple_ref/doc/uid/TP40014214-CH13-SW1. (ID: ae8dd1dd-8caf-4a48-9651-7a225faed4eb) The Info.plist in my Extension is: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>EXAppExtensionAttributes</key> <dict> <key>EXExtensionPointIdentifier</key> <string>com.example.example-extension</string> </dict> </dict> </plist> so the Info.plist that causes the issue has been automatically generated by Xcode. I can access it as well, and it says: { "BuildMachineOSBuild" => "25A354" "CFBundleDevelopmentRegion" => "en" "CFBundleDisplayName" => "localWebServerExtension" "CFBundleExecutable" => "localWebServer" "CFBundleIdentifier" => "AsheKube.app.a-Shell.localWebServerExtension" "CFBundleInfoDictionaryVersion" => "6.0" "CFBundleName" => "localWebServer" "CFBundlePackageType" => "XPC!" "CFBundleShortVersionString" => "1.0" "CFBundleSupportedPlatforms" => [ 0 => "iPhoneOS" ] "CFBundleVersion" => "1" "DTCompiler" => "com.apple.compilers.llvm.clang.1_0" "DTPlatformBuild" => "23A339" "DTPlatformName" => "iphoneos" "DTPlatformVersion" => "26.0" "DTSDKBuild" => "23A339" "DTSDKName" => "iphoneos26.0" "DTXcode" => "2601" "DTXcodeBuild" => "17A400" "EXAppExtensionAttributes" => { "EXExtensionPointIdentifier" => "AsheKube.app.a-Shell.localWebServer" } "MinimumOSVersion" => "26.0" "NSHumanReadableCopyright" => "Copyright © 2025 AsheKube. All rights reserved." "UIDeviceFamily" => [ 0 => 1 1 => 2 ] "UIRequiredDeviceCapabilities" => [ 0 => "arm64" ] } What should I do to be able to upload on the AppStore?

The API we used: NSURL *url = [NSURL URLWithString:@"App-Prefs:INTERNET_TETHERING"]; The link provided by Apple engineer: https://developer.apple.com/forums/thread/761314 I did not find any URL in the link that leads to the secondary menu of system settings. Does this suggest that iOS 26 does not support this functionality? Moreover, is it possible that versions of iOS 18 and earlier may also not support this behavior in the future?

After switching our iOS app project from Swift 5 to Swift 6 and publishing an update, we started seeing a large number of crashes in Firebase Crashlytics. The crashes are triggered by NotificationCenter methods (post, addObserver, removeObserver) and show the following error: BUG IN CLIENT OF LIBDISPATCH: Assertion failed: Block was expected to execute on queue [com.apple.main-thread (0x1f9dc1580)] All scopes to related calls are already explicitly marked with @MainActor. This issue never occurred with Swift 5, but appeared immediately after moving to Swift 6. Has anyone else encountered this problem? Is there a known solution or workaround? Thanks in advance!

Hi, I'm experiencing intermittent delays with URLSession where requests take 3-4 seconds to be sent, even though the actual server processing is fast. This happens randomly, maybe 10-20% of requests. The pattern I've noticed is I create my request I send off my request using try await urlSession.data(for: request) My middleware ends up receiving this request 4-7s after its been fired from the client-side The round trip ends up taking 4-7s! This hasn't been reproducible consistently at all on my end. I've also tried ephemeral URLSessions (so recreating the session instead of using .shared so no dead connections, but this doesn't seem to help at all) Completely lost on what to do. Please help!

As far as I understand, the main thread has a run loop. When an iOS app launches, the process must keep the run loop running to stay alive. Does that mean the main thread is the very first thread created when the process starts?

A security scoped bookmark can only be created for URLs that point to resources that exist. What is the preferred/correct API to use to determine if the resource exists? [NSFileManager fileExistsAtPath:] is more explicitly about existence, but might return NO if the app hasn't established access to the resource via an implicit or explicit startAccessingSecurityScopedResource? [NSURL checkResourceIsReachableAndReturnError] might explicitly deal with the latter issue (?), but might also return an error for other reasons than the resource not existing (?). 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.

Since macOS 26.1, creating bookmark data based on a NSOpenPanel URL, does not return the expected bookmark data when the selected source concerns a Windows NTFS fileshare. When the returned data is being resolved, the returned URL points to the local drive of the current Mac. Which is of course super confusing for the user. This issue did not occur in macOS 26.0 and older. In essence, the following code line with 'url' based on an URL from a NSOpenPanel after selecting the root of a Windows NTFS share, creates an incorrect bookmark in macOS 26.1: let bookmark = try url.bookmarkData(options: .withSecurityScope, includingResourceValuesForKeys: nil, relativeTo: nil) I have tested this on two different Macs with macOS 26.1 with two different Windows PC both hosting NTFS files shares via SMB. My questions: Have anyone else encountered this issue in macOS 26? Perhaps even with other fileshare types? Is there a workaround or some new project configuration needed in Xcode to get this working?

Users of my different apps started reporting an issue that could be related to the ones discussed in this other post: paths on an external volume, such as one mounted by "NTFS for Mac", or a path on a Synology volume, are "converted" to / (Macintosh HD) after going through "laundry" (creating the security-scoped bookmark, resolving the URL from it and using this new URL instead of the one returned by the open panel). Because of this issue, users of my apps are unable to select external volumes, which renders the different apps more or less useless. I've already received many emails regarding this issue in the past few days. A timely fix or suggestion for a workaround would be much appreciated, so that they don't have to wait for months before the next minor macOS release. The intention of this post is also to show users of my apps that this is a real issue. I created FB21002290 and TSI 16931637.