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.

Hi everyone, I’ve run into a consistent issue on multiple Apple Vision Pro devices where downloads using URLSessionConfiguration.background are between 4× and 10x slower than when using URLSessionConfiguration.default. This issue is systematic and can easily be reproduced. This only happens on device, in the simulator, both configurations download files at the expected speed with respect to the network speed. Details: Tested on visionOS 26.0.1 and 26.1 (public releases) Reproduced across 2 Vision Pro (currently testing on a third one) Reproduced on 2 different Wi-fi networks (50mb/s and 880mb/s) From my tests this speed issue seems to affects multiple apps on my device: Stobo Vision (our app), Immersive India, Amplium Not server-related (reproduces with Apple CDN, S3, and DigitalOcean) I’ve built a small sample project that makes this easy to reproduce, it downloads a large file (1.1 GB video) using two managers: One with URLSessionConfiguration.default One with URLSessionConfiguration.background You can also try it with your own file url (from an s3 for example) Expected behavior: Background sessions should behave similarly to default sessions in terms of throughput, just as they do in the simulator. To be clear I am comparing both config when running in the foreground, not in the background. Actual behavior: Background sessions on Vision Pro are significantly slower, making them less usable for large file downloads. On this screenshot it's even reaching 27x slower than the expected speed. Default config takes ~97s to download and Background config takes ~2640s. I do now have the fastest internet connection but 44min to download 90.5MB is extremely slow. Has anyone else seen this behavior or found a workaround? Or is this an expected behavior from URLSessionConfiguration.background? If I'm doing something wrong please let me know Repo link: https://github.com/stobo-app/DownloadConfigTesting

For bookmark creation and resolving, there's a NSURLBookmark{Creation,Resolution}MinimalBookmark enum value. What does this value imply on macOS and iOS? Specifically, to create security scoped bookmarks on macOS, we use NSURLBookmarkResolutionWithSecurityScope, but that is not available on iOS. Are iOS bookmarks always security scoped? Does the minimal enum imply security scoped bookmarks? Is 0 a valid value to bookmarkDataWithOptions, and does that give an even less scoped bookmark than NSURLBookmarkCreationMinimalBookmark`? We are also using NSURLBookmarkCreationWithoutImplicitSecurityScope on both iOS and macOS, to avoid any implicit resolution of bookmarks we resolve, so that we can explicitly control access by explicit calls to start/stopAccessing. How does NSURLBookmarkCreationWithoutImplicitSecurityScope relate to the enum values discussed above? Thanks! (https://mothersruin.com/software/Archaeology/reverse/bookmarks.html provides some really interesting insights, but doesn't discuss the minimal bookmarks.)

If I'm reading this guide correctly, macOS will automatically/implicitly startAccessingSecurityScopedResource for files opened via drag to Dock icon or NSOpenPanel. And I'm expected to call stopAccessingSecurityScopedResource to balance it once I'm done. Does that mean that if I don't, I'm leaking kernel resources as per the docs? If you fail to relinquish your access to file-system resources when you no longer need them, your app leaks kernel resources. If sufficient kernel resources leak, your app loses its ability to add file-system locations to its sandbox, such as with Powerbox or security-scoped bookmarks, until relaunched. What is this limit in practice for macOS and iOS? I've seen number ranging from 1000-2500. From my testing, iOS does not provide the same implicit startAccessingSecurityScopedResource when using UIDocumentPickerViewController. Is this a correct observation/per design? Now, in the cases where I'm creating an NSURL by resolving a saved bookmark, I'm expected to explicitly startAccessingSecurityScopedResource. Based on this, from what I can tell, this means that I can't universally call startAccessingSecurityScopedResource whenever I access a resource by URL, balanced with a stopAccessingSecurityScopedResource when done, as depending on how I got the URL it might already be implicitly started. Is this a correct observation? Do I need to explicitly check whether I'm on iOS (never implicit?), or macOS (sometimes implicit?), and selectively startAccessingSecurityScopedResource based on every call site that may give me a security-scoped file? If so, is there a complete list of the entrypoints that may give me such files (file dialog, drag and drop, etc)? Thanks!

I would like to change the name of the app displayed in the pop-up box during the download process.

var testTwo: Double = 0 testDouble = 80 testTwo = 200 var testThree: Int = 0 testThree = Int(testTwo/testDouble) var testDate: Date = .now var dateComponent = DateComponents() dateComponent.day = testThree var newDate: Date = Calendar.current.date(byAdding: dateComponentwith a thread error , to: testDate)! This code works in a playground. However, when I try to use it in Xcode for my app it fails with the following error: Thread 1: Fatal error: Double value cannot be converted to Int because it is either infinite or NaN I printed the value being converted to Int and it was not NAN or infinite.