We observed a new crash after upgrading to iOS 18. This crash does not occur on iOS 17 or earlier. Crash Stacks From Xcode Organizer CoreFoundation: __CFRunLoopServiceMachPort + 160 2. CoreFoundation: __CFRunLoopServiceMachPort.cold.1 + 64 Crash Stacks From APM

In release mode, the values are missing. I don't know what's wrong with it. If I install the debug version first and then overwrite it with the release build, I can retrieve the values stored in debug mode. But if I uninstall completely and install the release version directly, it's empty

App initiates a App group based UserDefaults within the willFinishLaunchingWithOptions method and the same reference are used throughout the app life cycle + (NSUserDefaults *)appGroupUserDefaults { if (_appGroupUserDefaults == nil) { NSString *appGroupIdentifier = [NSString stringWithFormat:@"group.%@",[[NSBundle mainBundle] bundleIdentifier]]; NSUserDefaults *groupDefaults = [[NSUserDefaults standardUserDefaults] initWithSuiteName:appGroupIdentifier]; if(groupDefaults != nil) { NSLog(@"[DB_ENCRYPTION] appGroupUserDefaults initialised"); _appGroupUserDefaults = groupDefaults; } else { NSLog(@"<ALA_ERROR>: [CCF-OS] [DB_ENCRYPTION] %s Unable to create NSUSerDefaults with groupIdentifier", __func__); _appGroupUserDefaults = [NSUserDefaults standardUserDefaults]; } } return _appGroupUserDefaults; } Doesn't have any issues on accessing the values but seen the below console error: Couldn't read values in CFPrefsPlistSource<0x103eedb00> (Domain: group.com.kodiak.InstaPoC, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd Does it require any action here ?

I have an app which uses ubiquitous containers and files in them to share data between devices. It's a bit unusual in that it indexes files in directories the user grants access to, which may or may not exist on a second device - those files are identified by SHA-1 hash. So a second device scanning before iCloud data has fully sync'd can create duplicate references which lead to an unpleasant user experience. To solve this, I store a small binary index in the root of the ubiquitous file container of the shared data, containing all of the known hashes, and as the user proceeds through the onboarding process, a background thread is attempting to "prime" the ubiquitous container by calling FileManager.default.startDownloadingUbiquitousItemAt() for each expected folder and file in a sane order. This likely creates a situation not anticipated by the iOS/iCloud integration's design, as it means my app has a sort of precognition of files it should not yet know about. In the common case, it works, but there is a corner case where iCloud sync has just begun, and very, very little metadata is available (the common case, however, in an emulator), in which two issues come up: I/O may hang indefinitely, trying to read a file as it is arriving. This one I can work around by running the I/O in a thread created with the POSIX pthread_create and using pthread_cancel to kill it after a timeout. Attempts to call FileManager.default.startDownloadingUbiquitousItemAt() fails with an error Error Domain=NSCocoaErrorDomain Code=257 "The file couldn’t be opened because you don’t have permission to view it.". The permissions aspect of it is nonsense, but I can believe there's no applicable "sort of exists, sort of doesn't" error code to use and someone punted. The problem is that this same error will be thrown on any attempt to access that file for the life of the application - a restart is required to make it usable. Clearly, the error or the hallucinated permission failure is cached somewhere in the bowels of iOS's FileManager. I was hoping startAccessingSecurityScopedResource() would allow me to bypass such a cache, as it does with URL.resourceValues() returning stale file sizes and last modified times. But it does not. Is there some way to clear this state without popping up a UI with an Exit button (not exactly the desired iOS user experience)?

We are developing an iOS application that is interacting with HTTP APIs that requires us to put a unique UUID (a nonce) as an header on every request (obviously there's more than that, but that's irrilevant to the question here). If the same nonce is sent on two subsequent requests the server returns a 412 error. We should avoid generating this kind of errors as, if repeated, they may be flagged as a malicious activity by the HTTP APIs. We are using URLSession.shared.dataTaskPublisher(for: request) to call the HTTP APIs with request being generated with the unique nonce as an header. On our field tests we are seeing a few cases of the same HTTP request (same nonce) being repeated a few seconds on after the other. Our code has some retry logic only on 401 errors, but that involves a token refresh, and this is not what we are seeing from logs. We were able to replicate this behaviour on our own device using Network Link Conditioner with very bad performance, with XCode's Network inspector attached we can be certain that two HTTP requests with identical headers are actually made automatically, the first request has an "End Reason" of "Retry", the second is "Success" with Status 412. Our questions are: can we disable this behaviour? can we provide a new request for the retry (so that we can update headers)? Thanks, Francesco

content = try String(contentsOfFile: filepath) is the following warning. 'init(contentsOfFile:)' was deprecated in iOS 18: Use init(contentsOfFile:encoding:) instead After internet searching I could find an answer. I would appreciate a rewrite of my code line to get rid of 31 warnings. Thanks a LOT Charlie

We are building a hybrid iOS app using Angular (web) rendered inside a WKWebView, hosted by a native Swift app. Communication between the Angular UI and native Swift code is done using WKScriptMessageHandler. The app mostly works without issues, but in rare edge cases, we’re seeing crashes on the main thread, and the crash is reported in Firebase Crashlytics. The root cause appears related to CFRelease and WKScriptMessageHandler. Here’s the relevant crash stack: Crashed: com.apple.main-thread 0 CoreFoundation 0xbfac CFRelease + 44 1 CoreFoundation 0xa734 __CFURLDeallocate + 128 2 CoreFoundation 0x730c _CFRelease + 292 3 libobjc.A.dylib 0x4e28 AutoreleasePoolPage::releaseUntil(objc_object**) + 204 4 libobjc.A.dylib 0x4cbc objc_autoreleasePoolPop + 260 5 WebKit 0x99f194 WebKit::WebUserContentControllerProxy::didPostMessage(WTF::ObjectIdentifierGeneric<WebKit::WebPageProxyIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>, WebKit::FrameInfoData&&, WTF::ObjectIdentifierGeneric<WebKit::ScriptMessageHandlerIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>, std::__1::span<unsigned char const, 18446744073709551615ul>, WTF::CompletionHandler<void (std::__1::span<unsigned char const, 18446744073709551615ul>, WTF::String const&)>&&) + 680 6 WebKit 0x1b358 WebKit::WebUserContentControllerProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 392 7 WebKit 0xe86b0 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 272 8 WebKit 0x23c0c WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 44 9 WebKit 0xe3f054 IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) + 252 10 WebKit 0x332d4 IPC::Connection::dispatchIncomingMessages() + 744 11 JavaScriptCore 0x58a7c WTF::RunLoop::performWork() + 204 12 JavaScriptCore 0x599a4 WTF::RunLoop::performWork(void*) + 36 13 CoreFoundation 0x56328 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 14 CoreFoundation 0x562bc __CFRunLoopDoSource0 + 176 15 CoreFoundation 0x53dc0 __CFRunLoopDoSources0 + 244 16 CoreFoundation 0x52fbc __CFRunLoopRun + 840 17 CoreFoundation 0x52830 CFRunLoopRunSpecific + 588 18 GraphicsServices 0x11c4 GSEventRunModal + 164 19 UIKitCore 0x3d2eb0 -[UIApplication _run] + 816 20 UIKitCore 0x4815b4 UIApplicationMain + 340 21 APP1 0xa2f80 main + 21 (AppDelegate.swift:21) 22 ??? 0x1c234eec8 (シンボルが不足しています) Steps: WebView: WKWebView Message passing: WKScriptMessageHandler → passing data from Angular → Swift WKWebView is long-lived and reused Native is using WKUserContentController.add(_:name:) to register handlers Crashes are intermittent (hard to reproduce), but often follow: Screen sleep/wake Push notification open Angular calling native immediately after resume Questions: Has anyone seen this specific crash pattern involving CFRelease and WKScriptMessageHandler? Are there known WebKit or CoreFoundation bugs related to WKScriptMessageHandler and retained URLs or message content? Thank you for your help!

I am seeing a weird behavior of the date formatter (Full code is below). When run, this will give the following output: 57: 1 month, 3 weeks, 5 days 58: 1 month, 3 weeks, 6 days 59: 2 months 60: 2 months, 1 day 61: 2 months 62: 2 months, 1 day 63: 2 months, 2 days So both 59 days and 61 days are 2 months, and both 60 and 62 days are 2 months and 1 day. This of course is especially weird because this means, 2 months also comes after 2 months and a day. Can someone explain to me what is going on here? import Foundation let formatter = DateComponentsFormatter() formatter.unitsStyle = .full let calendar = Calendar(identifier: .gregorian) let today = calendar.date(from: DateComponents(year: 2025, month: 7, day: 26))! for day in 57...63 { let startDate = calendar.date(byAdding: .day, value: -day, to: today)! let components = calendar.dateComponents([.day, .weekOfMonth, .month,. year], from: startDate, to: today) let result = formatter.string(from: components)! print ("\(String(format: "%3d", day)): \(result)") }

When the iPhone is set to 12-hour time format, obtaining a timestamp similar to "2025-07-18 16:29:00" fails

I have discovered a gap in my understanding of user selected URLs in iOS, and I would be grateful if someone can put me right please. My understanding is that a URL selected by a user can be accessed by calling url.startAccessingSecurityScopedResource() call. Subsequently a call to stopAccessingSecurityScopedResource() is made to avoid sandbox memory leaks. Furthermore, the URL can be saved as a bookmark and reconstituted when the app is run again to avoid re-asking permission from the user. So far so good. However, I have discovered that a URL retrieved from a bookmark can be accessed without the call to url.startAccessingSecurityScopedResource(). This seems contrary to what the documentation says here So my question is (assuming this is not a bug) why not save and retrieve the URL immediately in order to avoid having to make any additional calls to url.startAccessingSecurityScopedResource? Bill Aylward You can copy and paste the code below into a new iOS project to illustrate this. Having chosen a folder, the 'Summarise folder without permission' button fails as expected, but once the 'Retrieve URL from bookmark' has been pressed, it works fine. import SwiftUI import UniformTypeIdentifiers struct ContentView: View { @AppStorage("bookmarkData") private var bookmarkData: Data? @State private var showFolderPicker = false @State private var folderUrl: URL? @State private var folderReport: String? var body: some View { VStack(spacing: 20) { Text("Selected folder: \(folderUrl?.lastPathComponent ?? "None")") Text("Contents: \(folderReport ?? "Unknown")") Button("Select folder") { showFolderPicker.toggle() } Button("Deselect folder") { folderUrl = nil folderReport = nil bookmarkData = nil } .disabled(folderUrl == nil) Button("Retrieve URL from bookmark") { retrieveFolderURL() } .disabled(bookmarkData == nil) Button("Summarise folder with permission") { summariseFolderWithPermission(true) } .disabled(folderUrl == nil) Button("Summarise folder without permission") { summariseFolderWithPermission(false) } .disabled(folderUrl == nil) } .padding() .fileImporter( isPresented: $showFolderPicker, allowedContentTypes: [UTType.init("public.folder")!], allowsMultipleSelection: false ) { result in switch result { case .success(let urls): if let selectedUrl = urls.first { print("Processing folder: \(selectedUrl)") processFolderURL(selectedUrl) } case .failure(let error): print("\(error.localizedDescription)") } } .onAppear() { guard folderUrl == nil else { return } retrieveFolderURL() } } func processFolderURL(_ selectedUrl: URL?) { guard selectedUrl != nil else { return } // Create and save a security scoped bookmark in AppStorage do { guard selectedUrl!.startAccessingSecurityScopedResource() else { print("Unable to access \(selectedUrl!)"); return } // Save bookmark bookmarkData = try selectedUrl!.bookmarkData(options: .minimalBookmark, includingResourceValuesForKeys: nil, relativeTo: nil) selectedUrl!.stopAccessingSecurityScopedResource() } catch { print("Unable to save security scoped bookmark") } folderUrl = selectedUrl! } func retrieveFolderURL() { guard let bookmarkData = bookmarkData else { print("No bookmark data available") return } do { var isStale = false let url = try URL( resolvingBookmarkData: bookmarkData, options: .withoutUI, relativeTo: nil, bookmarkDataIsStale: &isStale ) folderUrl = url } catch { print("Error accessing URL: \(error.localizedDescription)") } } func summariseFolderWithPermission(_ permission: Bool) { folderReport = nil print(String(describing: folderUrl)) guard folderUrl != nil else { return } if permission { print("Result of access requrest is \(folderUrl!.startAccessingSecurityScopedResource())") } do { let contents = try FileManager.default.contentsOfDirectory(atPath: folderUrl!.path) folderReport = "\(contents.count) files, the first is: \(contents.first!)" } catch { print(error.localizedDescription) } if permission { folderUrl!.stopAccessingSecurityScopedResource() } } }

I have a multiplatform app for Mac and iOS, for which I am implementing a share extension. This share extension has to share settings with the app itself on both platforms. I am currently trying to achieve this by adding all targets to the same App Group and using UserDefaults with the App Group as suiteName. The app consists of three targets: A multiplatform SwiftUI app, an iOS Share Extension, and a macOS Share Extension,. Settings get persisted correctly on Mac and on the iOS 26 simulator. However, on a real iOS 26 beta 3 device, the Share Extension is unable to load UserDefaults (loading anything with the App Group as a suite name returns nil). What could cause this behavior? The following log entries are generated from the Share Extension on the iOS device, but not on the iOS simulator: Couldn't read values in CFPrefsPlistSource&lt;0x1030d3c80&gt; (Domain: MY_APP_GROUP, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd 59638328 Plugin query method called (501) Invalidation handler invoked, clearing connection (501) personaAttributesForPersonaType for type:0 failed with error Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated from this process." UserInfo={NSDebugDescription=The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated from this process.} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={_LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler, _LSFile=LSDReadService.mm, NSDebugDescription=process may not map database} Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={_LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler, _LSFile=LSDReadService.mm, NSDebugDescription=process may not map database} [C:1-3] Error received: Invalidated by remote connection.

A user of my app reported that when trying to remove a file it always fails with the error "file couldn't be removed because you don't have permission to access it (Cocoa Error Domain 513)". After some testing, we found out that it's caused by trying to delete non-empty directories. I'm using FileManager.removeItem(atPath:) which has worked fine for many years, but it seems that with their particular NAS, it doesn't work. I could work around this by checking if the file is a directory, and if it is, enumerating the directory and remove each contained file before removing the directory itself. But shouldn't this already be taken care of? In the source code of FileManager I see that for Darwin platforms it calls removefile(pathPtr, state, removefile_flags_t(REMOVEFILE_RECURSIVE)) so it seems that it should already work. Is the REMOVEFILE_RECURSIVE flag perhaps ignored by the device? But then, is the misleading "you don't have permission to access the file" error thrown by the device or by macOS? For the FileManager source code, see https://github.com/swiftlang/swift-foundation/blob/1d5d70997410fc8b7700c8648b10d6fc28194202/Sources/FoundationEssentials/FileManager/FileOperations.swift#L444

Hi there, I have discovered that the behavior of file copying has changed starting from iOS 18.4. When using FileManager.copyItem(atPath:toPath:) to copy a directory specified as an argument, whether or not there is a trailing slash ('/') affects whether the copy process works correctly. The same process operates as expected in the iOS 18.3.1 Simulator. Is this the correct behavior, or could it be a bug? The application's build environment is Xcode 16.2. Below is an example of the code. In practice, the file copying is performed within the application's folder. // Both iOS 18.3.1 and iOS 18.4 successfully complete the copy process. FileManager.default.copyItem(atPath: "/path/from/dirA", toPath: "/path/to/dirB") FileManager.default.copyItem(atPath: "/path/from/dirA/", toPath: "/path/to/dirB/") // iOS 18.3.1 successfully complete the copy process, but iOS 18.4 fails. FileManager.default.copyItem(atPath: "/path/from/dirA/", toPath: "/path/to/dirB") I hope this helps Apple engineers and other developers experiencing the same issue. Feedback or additional insights would be appreciated.

When I connect to another Mac via Finder (using SMB), creating a hard link with FileManager.linkItem(atPath:toPath:) fails (both source and destination are on the remote Mac). I read online that SMB itself supports creating hard links, so is this a macOS limitation or bug?

App includes a functionality based on each Timezone. As i have fetched some of the Timezone values got some mismatched values compared to actual. e.g: America/Denver values is -6 but got -5 Need support regarding fixing this issue.

After swapping the -objectAtIndex: method using method_exchangeImplementations, it will cause continuous memory growth. Connect the iPhone and run the provided project. Continuously tap the iPhone screen. Observe Memory; it will keep growing. Sample code

Until now I was using FileManager.contentsEqual(atPath:andPath:) to compare file contents in my App Store app, but then a user reported that this operation is way slower than just copying the files (which I made faster a while ago, as explained in Making filecopy faster by changing block size). I thought that maybe the FileManager implementation reads the two files with a small block size, so I implemented a custom comparison with the same block size I use for filecopy (as explained in the linked post), and it runs much faster. When using the code for testing repeatedly also found on that other post, this new implementation is about the same speed as FileManager for 1KB files, but runs 10-20x faster for 1MB files or bigger. Feel free to comment on my implementation below. extension FileManager { func fastContentsEqual(atPath path1: String, andPath path2: String, progress: (_ delta: Int) -> Bool) -> Bool { do { let bufferSize = 16_777_216 let sourceDescriptor = open(path1, O_RDONLY | O_NOFOLLOW, 0) if sourceDescriptor < 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } let sourceFile = FileHandle(fileDescriptor: sourceDescriptor) let destinationDescriptor = open(path2, O_RDONLY | O_NOFOLLOW, 0) if destinationDescriptor < 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } let destinationFile = FileHandle(fileDescriptor: destinationDescriptor) var equal = true while autoreleasepool(invoking: { let sourceData = sourceFile.readData(ofLength: bufferSize) let destinationData = destinationFile.readData(ofLength: bufferSize) equal = sourceData == destinationData return sourceData.count > 0 && progress(sourceData.count) && equal }) { } if close(sourceDescriptor) < 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } if close(destinationDescriptor) < 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } return equal } catch { return contentsEqual(atPath: path1, andPath: path2) // use this as a fallback for unsupported files (like symbolic links) } } }

Hey, there are plans to design a government app. When a citizen will login they will see their passport, driving license etc... What is the solution of avoiding mandatory in-app user data deletion?

Product & Version: iOS 17.5.1 (21F90) – reproducible since iOS 13 Test devices: iPhone 14 Pro, iPhone 15, iPad (10th gen) Category: UIKit → Text Input / Keyboard Summary: If the system “Save Password?” prompt (shown by iCloud Keychain after a successful login) is onscreen and the user sends the app to background (Home gesture / App Switcher), the prompt is automatically dismissed. When the app returns to foreground, the keyboard does not appear, and text input is impossible in the entire app until it is force-quit. Steps to Reproduce: Run any app from AppStore that shows "Save Password" alert. Enter any credentials and tap Login, iOS shows the system “Save Password?” alert. Without interacting with the alert, swipe up to the Home screen (or open the App Switcher). Reactivate the app. Tap the text field in the app.

We are testing our existing live build, which was prepared with Xcode 16.2, on iOS 26 beta for experience assurance and found that the [[UIDevice currentDevice] systemVersion] API is returning iOS 19 instead of the expected version iOS 26. Has anyone else observed this issue?