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?
Foundation
RSS for tagAccess essential data types, collections, and operating-system services to define the base layer of functionality for your app using Foundation.
Posts under Foundation tag
200 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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.
Topic:
App & System Services
SubTopic:
Processes & Concurrency
Tags:
iOS
Background Tasks
Foundation
CFNetwork
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.
When my Share Extension receives an image from the macOS Photos app on Tahoe, the NSItemProvider passes a URL to an image file in a temporary location.
All attempts to read that file fail silently, such as with NSImage(contentsOfFile)
I can see that the file does exist in Finder.
This code did work in previous macOS versions.
It seems like a permissions issue, but startAccessingSecurityScopedResource had no effect.
Other platforms work, other apps work, such as shares from Finder, which shares via data instead of a url.
I'm really stuck. Has anyone else run into this?
// make sure provider has a conforming item
if itemProvider.hasItemConformingToTypeIdentifier(imageType)
{
do {
let data = try await itemProvider.loadItem(forTypeIdentifier: imageType, options: nil)
// data may be image NativeImage, Data, or a URL to an image file.
// figure out which by casting, then attempt to load uiImage
if let image = data as? NativeImage {
print("found NativeImage")
self.images.append(image)
}
else if let data = data as? Data {
print("found Data")
if let image = NativeImage(data: data) {
self.images.append(image)
}
} else if let url = data as? URL{
print("found URL")
if let image = NativeImage(contentsOfFile: url.path) {
print("loaded from URL")
self.images.append(image)
}
}
}catch{
print("⛔️ Share Extension Error: \(error.localizedDescription)")
}
}
I'm working on an API client for a REST service that uses a custom token-based authentiation scheme. The app hits a specificed authentication endpoint with a username and password, said endpoint returns a token that's good for X amount of time, and the app passes that token along with every subsequent request. When that token expires, we start over.Most literature out there tells me to manually set the Authorization header on my request, but official Apple documentation discourages this, as that header is meant to be 'owned' by the built-in HTTP loading system. That said, official documentation on the 'correct' way to do this is shockingly lacking, and the standard didReceiveChallenge callbacks seem better suited for non-custom Basic/Digest/etc authentication schemes. One thought I had was registering my own URLProtocol subclass to handle our custom flow. However, while I haven't had a chance to sit down and take a crack at that yet, my understanding from skimming these forums is that it's suffering from some bit-rot right now, so it 'might' (?) not be the best choice. That, and it's also not clear to me whether the rules around the Authorization header change when a custom URLProtocol is in play.So, community (paging eskimo in particular!), what's the correct way for me to go about this?
I regularly receive emails from my customers asking why my app, which copies files from a source folder to a destination folder, gives an error during the copy operation, usually when some kind of NAS is involved. I then ask if copying the same file works in the Finder and they usually say yes. Then it’s up to me to contact the NAS vendor and ask why their NAS doesn’t work correctly with the copyfile function which my app uses to copy files, and provide them with a sample Xcode project that reproduces the issue.
It would be so much easier for me, and probably other developers as well, if my customers could test their NAS with the Finder, then if it doesn’t work, contact their NAS vendor and solve the issue, or if it works, rest assured that file copies will work for any other app that uses the same API as the Finder. I could spend my time doing much more productive and interesting work rather than checking why every other NAS doesn’t work with my app which, after all, uses the most basic file copy mechanism available on macOS.
Is there any chance that in the future (hopefully sooner than later) there will be an API to copy files like the Finder with progress information, or is there a reason why this won't ever be possible?
I created FB20929181.
Hi,
We can easily get drive throughput using the iostat command, but it only outputs plain text that needs to be parsed, and I’m not sure if the format or column order is consistent across macOS versions.
Is there any API that provides the same disk I/O metrics that iostat reports, but in a way that can be safely called from a notarized app?
Hello,
I have a question about data deserialization using NSKeyedUnarchiver in iOS SDK development.
Current Situation:
Previously, we were using the NSKeyedUnarchiver.unarchiveObject(with: Data) function
We have changed to using the NSKeyedUnarchiver.unarchivedObject(ofClasses:from:) method to deserialize complex objects stored in UserDefaults
We need to include all types in the ofClasses parameter, including Swift primitive types as well as various custom classes and structs within the project
Questions:
Implementation Approach: Is it correct pattern to include all classes defined in the project in the ofClasses array? Is this approach recommended?
Runtime Stability: When using this approach, is there a possibility of runtime crashes? Are there any performance issues?
Alternative Methods: If the current approach is not the correct pattern, what alternatives should we consider?
Current Code Structure:
All model classes conform to the NSSecureCoding protocol
We use the requiringSecureCoding: true parameter
We use a whitelist approach, explicitly listing only allowed classes
I would like to know if this structure is appropriate, or if we should consider a different approach.
Thank you.
Hi,
I have a macOS app distributed through the App Store that uses an app group to share data with app extensions.
The group identifier has the form:
.group.
In Xcode 26 I am now asked to convert the project to profile based app groups (like on iOS).
My question is:
Can I convert the project to profile based app groups and will the existing app group (which is prefixed with the Team ID) continue to work (and will exiting users still be able to access their data).
If yes, should I add the app group with or without the Team ID prefix to the profile.
Hi,
I've tried adding Extensions (using ExtensionFoundation) to one of my iOS apps. They work using Xcode on my devices, but when I upload them to the AppStore, I get the following error:
ITMS-90349: 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.
I could not find relevant information on the web page pointed. I've tried different values for the "EXExtensionPointIdentifier", but none of them work. This value was generated by Xcode, since I did set the user-defined build setting EX_ENABLE_EXTENSION_POINT_GENERATION = YES, as explained in the instructions.
At this point, I have no idea how to fix this issue.