When the UITextField is touched, it crashes on "[UITextField becomeFirstResponder]" iOS 15.3.1 keyboard: Chinese keyboard of system

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFString timeIntervalSinceReferenceDate]: unrecognized selector sent to instance 0x115fadbc0' *** First throw call stack: (0x1940bd8c8 0x1910097c4 0x194159838 0x19403a4f8 0x1940423a0 0x1e42cb9a8 0x1e42ce220 0x106f02c08 0x1080a461c 0x1080be2b0 0x1080acb2c 0x1080ad7b4 0x1080b9b00 0x1080b91a4 0x1eecdb3b8 0x1eecda8c0) libc++abi: terminating due to uncaught exception of type NSException InputAnalytics called timeIntervalSinceReferenceDate in dispatch_sync.The display issue of the call stack occurs in two stages: keyboard input analysis and folding the keyboard. After adding protection to NSString, it can function normally, but I want to know the reason #import "NSString+Safe.h" @implementation NSString (Safe) - (NSTimeInterval)timeIntervalSinceReferenceDate { return 0; } - (NSTimeInterval)timeIntervalSinceDate:(NSDate *)date { return 0; } @end

Hello, In our app we provide a button that initiates a phone call using tel://. For normal numbers, tapping the button presents the standard iOS confirmation sheet with Call and Cancel. If RTT is enabled on the device, the sheet instead shows three options: Call, Cancel, and RTT Call. However, when dialing a national emergency number, this confirmation dialog does not appear at all — the call is placed immediately, without giving the user the choice between voice or RTT. Is this the expected system behavior for emergency numbers on iOS? 
And if so, how does RTT get applied in the emergency-call flow — is it managed entirely by the OS rather than exposed as a user-facing option? Thanks in advance for clarifying.

I have prepared a NSSpellServer spelling and grammar checker for Slovenian proofing in macOS. My proofing service gets used when I explicitly set keyboard spelling language to "Slovenian (Besana)" (my proofing tool). When I set keyboard language to Automatic by Language, system does the language detection. Since it has limited support for Slovenian language, it doesn't recognize the text as Slovenian and never asks my proofing service to check the spelling. It does consult my proofing service for spelling suggestions and when it does, I see the language parameter there is set to anything but Slovenian. Is it possible to install own language detector to macOS? Or, place some language dictionary files somewhere, the system could use to extend language detection to new languages?

I would like to understand the recommended App Store–compliant method for uninstalling applications, particularly in cases where certain apps are owned by root rather than the user. Currently, since root-owned apps cannot be uninstalled, I display the error message: 'App name couldn’t be moved to the Trash because you don’t have permission to access it. please run sudo chown -R $user /application/appname and try again' I then instruct users to change the ownership of the app and try again, but this approach does not appear to align with App Store policies.

While I am not new to programming, I am quite new to the Swift language. I am using the Swift Playground app on macOS 26 on an M1 MacBook Air. I am on the lesson about types. Perhaps it's a silly question, but what is a portal? It is never described or pointed out where to find it in the puzzle world. Similarly, the instructions reference a "switch" object without ever defining what it is. I cannot write code to call methods or set properties on objects about which I have no useful information. Can anyone advise, please? Thank you kindly.

For ages, we've been using appStoreReceiptUrl to detect if the app was installed from TestFlight or not, but now that's deprecated. Since we have a strict policy of no warnings on the project, we need to find a way to check if the app was installed from TestFlight or from the App Store. Does anyone know what's the new way to do so? I thought about using MarketplaceKit.AppDistributor.testFlight but to use MarketplaceKit you need to jump through hoops that our app really doesn't need to - we don't distribute outside of the App Store. Any ideas are much appreciated! 🙏

I have created a sample app which read/write from a network file. When the file was attempted to open (using open Linux API), connection to network file was lost. The thread which was stuck on the open method, returns after a long time. It was observed that for macOS, the maximum return time of the thread was around 10 mins, whereas in Windows and Linux, the maximum timeout was 60 sec and 90 sec. macOS has a very large timeout before returning the thread with a network failure error. Is this by designed and expected? With a large timeout as 10mins, it's difficult to respond swiftly back to the user.

A user of my app brought to my attention that unless they select their ~/Library/Mail folder explicitly in an open panel, they get an error when scanning it inside my app. I can confirm that I also get a permission error when trying to scan it as a subfolder of ~/Library, but not if I select it directly. I'm assuming this is intentional, but it would be nice to have an explanation or some documentation that I can point my users to when they encounter what appears to them as a bug in my app. What makes this matter even more confusing is that selecting a folder in any open panel of an app gives the app access to it for the lifetime of the app, but after restarting the app, access is lost again (unless it has a bookmark to it). This was probably the reason why the user thought that it worked in another app but not in mine. This is the code I use to scan: let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true if openPanel.runModal() == .cancel { return } let enumerator = FileManager.default.enumerator(at: openPanel.urls[0], includingPropertiesForKeys: nil) { url, error in print(url.path, error) return true } while let url = enumerator?.nextObject() as? URL { } And this the error related to the Mail folder: ~/Library/Mail Error Domain=NSCocoaErrorDomain Code=257 "The file “Mail” couldn’t be opened because you don’t have permission to view it." UserInfo={NSURL=file:///~/Library/Mail, NSFilePath=/~/Library/Mail, NSUnderlyingError=0x600002991470 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}

Problem summary I have a macOS helper app that is launched from a sandboxed main app. The helper: has com.apple.security.app-sandbox = true and com.apple.security.inherit = true in its entitlements, is signed and embedded inside the main app bundle (placed next to the main executable in Contents/MacOS), reports entitlement_check = 1 (code signature contains sandbox entitlement, implemented via SecStaticCode… check), sandbox_check(getpid(), NULL, 0) returns 1 (runtime sandbox enforcement present), APP_SANDBOX_CONTAINER_ID environment variable is not present (0). Despite that, Cocoa APIs return non-container home paths: NSHomeDirectory() returns /Users/<me>/ (the real home). [[NSFileManager defaultManager] URLsForDirectory:inDomains:] and URLForDirectory:inDomain:appropriateForURL:create:error: return paths rooted at /Users/<me>/ (not under ~/Library/Containers/<app_id>/Data/...) — i.e. they look like non-sandboxed locations. However, one important exception: URLForDirectory:... for NSItemReplacementDirectory (temporary/replacement items) does return a path under the helper's container (example: ~/Library/Containers/<app_id>/Data/tmp/TemporaryItems/NSIRD_<helper_name>_hfc1bZ). This proves the sandbox is active for some FileManager APIs, yet standard directory lookups (Application Support, Documents, Caches, and NSHomeDirectory()) are not being redirected to the container. What I expect The helper (which inherits the sandbox and is clearly sandboxed) should get container-scoped paths from Cocoa’s FileManager APIs (Application Support, Documents, Caches), i.e. paths under the helper’s container: /Users/<me>/Library/Containers/<app_id>/Data/.... What I tried / diagnostics already gathered Entitlements & code signature codesign -d --entitlements :- /path/to/Helper.app/Contents/MacOS/Helper # shows com.apple.security.app-sandbox = true and com.apple.security.inherit = true Runtime checks (Objective-C++ inside helper): extern "C" int sandbox_check(pid_t pid, const char *op, int flags); NSLog(@"entitlement_check = %d", entitlement_check()); // SecStaticCode check NSLog(@"env_variable_check = %d", (getenv("APP_SANDBOX_CONTAINER_ID") != NULL)); NSLog(@"runtime_sandbox_check = %d", sandbox_check(getpid(), nullptr, 0)); NSLog(@"NSHomeDirectory = %s", NSHomeDirectory()); NSArray *urls = [[NSFileManager defaultManager] URLsForDirectory:NSApplicationSupportDirectory inDomains:NSUserDomainMask]; NSLog(@"URLsForDirectory: %@", urls); Observed output: entitlement_check = 1 env_variable_check = 0 runtime_sandbox_check = 1 NSHomeDirectory = /Users/<me> URLsForDirectory: ( "file:///Users/<me>/Library/Application%20Support/..." ) Temporary/replacement directory (evidence sandbox active for some APIs): NSURL *tmpReplacement = [[NSFileManager defaultManager] URLForDirectory:NSItemReplacementDirectory inDomain:NSUserDomainMask appropriateForURL:nil create:YES error:&err]; NSLog(@"NSItemReplacementDirectory: %@", tmpReplacement.path); Observed output (example): /Users/<me>/Library/Containers/<app_id>/Data/tmp/TemporaryItems/NSIRD_<helper_name>_hfc1bZ Other facts Calls to NSHomeDirectory() and URLsForDirectory: are made after main() to avoid "too early" initialization problems. Helper is placed in Contents/MacOS (not Contents/Library/LoginItems). Helper is a non-GUI helper binary launched by the main app (not an XPC service). macOS version: Sequoia 15.6 Questions Why do NSHomeDirectory() and URLsForDirectory: return the real /Users/<me>/... paths in a helper process that is clearly sandboxed (entitlement + runtime enforcement), while NSItemReplacementDirectory returns a container-scoped temporary path? Is this behavior related to how the helper is packaged or launched (e.g., placement in Contents/MacOS vs Contents/Library/LoginItems, or whether it is launched with posix_spawn/fork+exec vs other APIs)? Are there additional entitlements or packaging rules required for a helper that inherits sandbox to have Cocoa directory APIs redirected to the container (for Application Support, Documents, Caches)? *Thanks in advance — I can add any requested logs

Greetings, With MacOS 15 Sequoia, Apple updated key-value-observations in such a way, that an unremoved observation by a now deallocated object will no longer cause an exception, when the observed object triggers said observation. While this is fundamentally a positive change, the issue comes with the fact, that this change affects systems based on the version of their operating system and not the version of the operating system of the build system. Many of our customers use old operating system versions and old hardware - meaning they can't easily update. Since we need to use up to date Xcode versions to develop for newer systems, our developers tend to have rather new OS versions. This means, that we are increasingly facing bugs which only happen in customer systems but not in most developer (or QA) systems. Currently, we still can use earlier OS versions with Xcode to fix these bugs, but once the used Xcode versions no longer support MacOS 14 or below this will become a major hurdle. Are there known solutions to this issue? We are currently attempting to swizzle observer adding and removal in order to fix the problem for old systems as well, but this has proven to be quite difficult and unstable. Since any weakly held property in the middle of an observation keypath can cause crashes, one would have to split up observations into multiple subobservations, which is less simple than it sounds, due to custom implementations of addObserver (such as there seems to be in array controller proxies) and collection operators. Thanks for any suggestions!

Hi everyone, I'm using an app group to share data between iOS and it's watch companion app. I ensured that is has the same identifier in Signing & Capabilities and in the .entitlements files. Here is the UserDefaults part: class UserDefaultsManager { private let suitName = "group.com.sanjeevbalakrishnan.Test" public func saveItems(_ items: [ItemDTO]) { print("Save \(items.count) items to shared defaults") let defaults = UserDefaults(suiteName: suitName) let data = try? JSONEncoder().encode(items) defaults?.set(data, forKey: "items") } public func loadItems() -> [ItemDTO] { let defaults = UserDefaults(suiteName: suitName) print(defaults) guard let data = defaults?.data(forKey: "items") else { print("watchOS received data is empty") return [] } let items = [ItemDTO].from(data: data) print("Load \(items.count) items from user defaults") return items } } For testing I called loadItems after saveItems on iOS app and it returned items. However, on watchOS app it always returns empty array. What do I need to consider? Thanks. Best regards Sanjeev

Hi, I encountered the following error while trying to launch a video game developed with Unity and running on an iPhone 12 and iPhone 16 Pro. Native StackTrace: Thread 2 (crashed) 0 libsystem_kernel.dylib 0x00000001d40102ec <symbols missing for uuid: 21ee5290d1193c31b948431865a67738> 1 libsystem_c.dylib 0x000000019330fba0 <symbols missing for uuid: 7135c2c8ba5836368b46a9e6226ead45> 2 UnityFramework 0x000000010e7bc744 <symbols missing for uuid: 4c1540b0ca733555aa69fc3e514204a3> 3 UnityFramework 0x000000010dc1c22c <symbols missing for uuid: 4c1540b0ca733555aa69fc3e514204a3> 4 UnityFramework 0x000000010cc26da4 <symbols missing for uuid: 4c1540b0ca733555aa69fc3e514204a3> 5 CoreFoundation 0x000000018b4af984 <symbols missing for uuid: 76a3b1983c09323e83590d4978e156f5> 6 libobjc.A.dylib 0x0000000183277140 7 libc++abi.dylib 0x00000001e7d20068 8 libc++abi.dylib 0x00000001e7d2000c 9 libdispatch.dylib 0x0000000193256de8 <symbols missing for uuid: 5f66cdb608a936158c6a4e3b47005495> 10 libdispatch.dylib 0x000000019325e400 <symbols missing for uuid: 5f66cdb608a936158c6a4e3b47005495> 11 libdispatch.dylib 0x000000019325ef30 <symbols missing for uuid: 5f66cdb608a936158c6a4e3b47005495> 12 libdispatch.dylib 0x0000000193269cb4 <symbols missing for uuid: 5f66cdb608a936158c6a4e3b47005495> 13 libdispatch.dylib 0x0000000193269528 <symbols missing for uuid: 5f66cdb608a936158c6a4e3b47005495> 14 libsystem_pthread.dylib 0x00000001e7e00934 15 libsystem_pthread.dylib 0x00000001e7dfd0cc

Greetings, I would like to understand this URLCache behavior for two different requests to the same end point but with a different header value. Here is a code with comment explaining the behavior. // Create a request to for a url. let url = URL(string: "https://&lt;my url&gt;?f=json")! var request = URLRequest(url: url) // Set custom header with a value. request.setValue("myvalue", forHTTPHeaderField: "CustomField") // Send request to get the response. let (data, response) = try await URLSession.shared.data(for: request) print("data: \(String(describing: String(data: data, encoding: .utf8)))") print("response: \(response)") // Create second request to the same url but with different value of custom header field. var request2 = URLRequest(url: url) request2.setValue("newvalue", forHTTPHeaderField: "CustomField") // Check the URL cache for second request and it returns the response // of the first request even though the second request has different header value. let cachedResponse = URLCache.shared.cachedResponse(for: request2) print("cachedResponse: \(cachedResponse?.response)") Is this a bug in URLCache that request headers are not matched while returning the response? Is this an expected behavior? If yes, why?

A user of my app noticed that when using it to move a file to the trash on an USB drive, the trash doesn't show the file until unmounting the drive and mounting it again. I was able to reproduce it with one of my own USB drives, but with another USB drive it doesn't reproduce. All USB drives are formatted APFS. When moving a file to the trash from the Finder, both USB drives immediately list it in the trash. Is this a macOS bug, or am I doing something wrong? I created FB19941168. let openPanel = NSOpenPanel() openPanel.runModal() let url = openPanel.urls[0] do { var result: NSURL? try FileManager.default.trashItem(at: url, resultingItemURL: &result) print(result as Any) } catch { fatalError(error.localizedDescription) }

I have a UIKit app where I've adopted SwiftData and I'm struggling with a crash coming in from some of my users. I'm not able to reproduce it myself and as it only happens to a small fraction of my user base, it seems like a race condition of some sort. This is the assertion message: SwiftData/DefaultStore.swift:453: Fatal error: API Contract Violation: Editors must register their identifiers before invoking operations on this store SwiftData.DefaultStore: 00CF060A-291A-4E79-BEC3-E6A6B20F345E did not. (ID is unique per crash) This is the ModelActor that crashes: @available(iOS 17, *) @ModelActor actor ConsumptionDatabaseStorage: ConsumptionSessionStorage { struct Error: LocalizedError { var errorDescription: String? } private let sortDescriptor = [SortDescriptor(\SDConsumptionSession.startTimeUtc, order: .reverse)] static func createStorage(userId: String) throws -> ConsumptionDatabaseStorage { guard let appGroupContainer = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: UserDefaults.defaultAppGroupIdentifier) else { throw Error(errorDescription: "Invalid app group container ID") } func createModelContainer(databaseUrl: URL) throws -> ModelContainer { return try ModelContainer(for: SDConsumptionSession.self, SDPriceSegment.self, configurations: ModelConfiguration(url: databaseUrl)) } let databaseUrl = appGroupContainer.appendingPathComponent("\(userId).sqlite") do { return self.init(modelContainer: try createModelContainer(databaseUrl: databaseUrl)) } catch { // Creating the model storage failed. Remove the database file and try again. try? FileManager.default.removeItem(at: databaseUrl) return self.init(modelContainer: try createModelContainer(databaseUrl: databaseUrl)) } } func isStorageEmpty() async -> Bool { (try? self.modelContext.fetchCount(FetchDescriptor<SDConsumptionSession>())) ?? 0 == 0 // <-- Crash here! } func sessionsIn(interval: DateInterval) async throws -> [ConsumptionSession] { let fetchDescriptor = FetchDescriptor(predicate: #Predicate<SDConsumptionSession> { sdSession in if let startDate = sdSession.startTimeUtc { return interval.start <= startDate && interval.end > startDate } else { return false } }, sortBy: self.sortDescriptor) let consumptionSessions = try self.modelContext.fetch(fetchDescriptor) // <-- Crash here! return consumptionSessions.map { ConsumptionSession(swiftDataSession: $0) } } func updateSessions(sessions: [ConsumptionSession]) async throws { if #unavailable(iOS 18) { // Price segments are duplicated if re-inserted so unfortunately we have to delete and reinsert sessions. // On iOS 18, this is enforced by the #Unique macro on SDPriceSegment. let sessionIds = Set(sessions.map(\.id)) try self.modelContext.delete(model: SDConsumptionSession.self, where: #Predicate<SDConsumptionSession> { sessionIds.contains($0.id) }) } for session in sessions { self.modelContext.insert(SDConsumptionSession(consumptionSession: session)) } if self.modelContext.hasChanges { try self.modelContext.save() } } func deleteAllSessions() async { if #available(iOS 18, *) { try? self.modelContainer.erase() } else { self.modelContainer.deleteAllData() } } } The actor conforms to this protocol: protocol ConsumptionSessionStorage { func isStorageEmpty() async -> Bool func hasCreditCardSessions() async -> Bool func sessionsIn(interval: DateInterval) async throws -> [ConsumptionSession] func updateSessions(sessions: [ConsumptionSession]) async throws func deleteAllSessions() async } The crash is coming in from line 30 and 41, in other words, when trying to fetch data from the database. There doesn't seem to be any common trait for the crashes. They occur across iOS versions and device types. Any idea what might cause this?

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