General: Forums subtopic: App & System Services > Networking TN3151 Choosing the right networking API Networking Overview document — Despite the fact that this is in the archive, this is still really useful. TLS for App Developers forums post Choosing a Network Debugging Tool documentation WWDC 2019 Session 712 Advances in Networking, Part 1 — This explains the concept of constrained networking, which is Apple’s preferred solution to questions like How do I check whether I’m on Wi-Fi? TN3135 Low-level networking on watchOS TN3179 Understanding local network privacy Adapt to changing network conditions tech talk Understanding Also-Ran Connections forums post Extra-ordinary Networking forums post Foundation networking: Forums tags: Foundation, CFNetwork URL Loading System documentation — NSURLSession, or URLSession in Swift, is the recommended API for HTTP[S] on Apple platforms. Moving to Fewer, Larger Transfers forums post Testing Background Session Code forums post Network framework: Forums tag: Network Network framework documentation — Network framework is the recommended API for TCP, UDP, and QUIC on Apple platforms. Building a custom peer-to-peer protocol sample code (aka TicTacToe) Implementing netcat with Network Framework sample code (aka nwcat) Configuring a Wi-Fi accessory to join a network sample code Moving from Multipeer Connectivity to Network Framework forums post NWEndpoint History and Advice forums post Network Extension (including Wi-Fi on iOS): See Network Extension Resources Wi-Fi Fundamentals TN3111 iOS Wi-Fi API overview Wi-Fi Aware framework documentation Wi-Fi on macOS: Forums tag: Core WLAN Core WLAN framework documentation Wi-Fi Fundamentals Secure networking: Forums tags: Security Apple Platform Security support document Preventing Insecure Network Connections documentation — This is all about App Transport Security (ATS). Available trusted root certificates for Apple operating systems support article Requirements for trusted certificates in iOS 13 and macOS 10.15 support article About upcoming limits on trusted certificates support article Apple’s Certificate Transparency policy support article What’s new for enterprise in iOS 18 support article — This discusses new key usage requirements. Technote 2232 HTTPS Server Trust Evaluation Technote 2326 Creating Certificates for TLS Testing QA1948 HTTPS and Test Servers Miscellaneous: More network-related forums tags: 5G, QUIC, Bonjour On FTP forums post Using the Multicast Networking Additional Capability forums post Investigating Network Latency Problems forums post WirelessInsights framework documentation iOS Network Signal Strength Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

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!

Issue Summary: On iOS 26.0.1 to 26.3, apps using multiple UITextFields for OTP input face a critical issue where the system autofill pastes the entire OTP string into a single text field, usually the focused one, rather than splitting digits across fields. Delegate events like textDidChange: do not trigger consistently on autofill, breaking existing input handling logic. Expected Behavior: OTP autofill should distribute each digit correctly across all OTP UITextFields. Delegate or control events should fire on autofill to enable manual handling. (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string { if (string.length > 1) { // Autofill detected - distribute OTP manually for (int i = 0; i < string.length && i < self.arrayOTPText.count; i++) { UITextField *field = self.arrayOTPText[i]; field.text = [NSString stringWithFormat:@"%c", [string characterAtIndex:i]]; } UITextField *lastField = self.arrayOTPText[string.length - 1]; [lastField becomeFirstResponder]; return NO; } // Handle normal single character or deletion input here return YES; } // // Setup UITextFields - set .oneTimeCode on first field only for (int i = 0; i < self.arrayOTPText.count; i++) { UITextField *field = self.arrayOTPText[i]; field.delegate = self; if (@available(iOS 12.0, *)) { field.textContentType = (i == 0) ? UITextContentTypeOneTimeCode : UITextContentTypeNone; } } What We’ve Tried: Setting textContentType properly. Handling OTP distribution in delegate method. Verifying settings and keyboard use. Testing on multiple iOS 26.x versions. Impact: Major usability degradation during OTP entry. Forces fragile workarounds. Inconsistent autofill reduces user confidence. Request: Request Apple fix OTP autofill to natively support multi-field UITextField OTP input or provide enhanced delegate callbacks for consistent behavior. Did any one face this issue in recent time with iOS 26.0.1 to 26.3 beta version

I want to create GIF file and then use UIImage to it.

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!

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.

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?

My app allows to save user-selected URLs in a list and browse them with a tap. A user reported that the app often shows that when browsing their saved entry for "On My iPad", it's apparently empty (it contains no files). I saved "On My iPad" in my own list some time ago and noticed that the same issue occurs. The URL seems to be correctly resolved from the saved bookmark data, but I noticed that url.startAccessingSecurityScopedResource() returns false. The other URL I saved some time ago is iCloud Drive, which I can access without issues. If I select "On My iPad" again in a file importer, create new bookmark data from it and resolve the URL from it, access works correctly. I create bookmark data like this: let data = try url.bookmarkData(includingResourceValuesForKeys: [.localizedNameKey, .pathKey, .volumeIsLocalKey]) and resolve URLs like this: let url = try URL(resolvingBookmarkData: data, bookmarkDataIsStale: &bookmarkDataIsStale) bookmarkDataIsStale is false for both the working and not working URLs for "On My iPad". The two bookmark data are different though, even if url.path is the same. What could be the issue?

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.

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!

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 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?

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?

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.