I'm trying to understand the behavior I'm seeing here. In the following example, I have a custom @Observable class that adopts RandomAccessCollection and am attempting to populate a List with it. If I use an inner collection property of the instance (even computed as this shows), the top view identifies additions to the list. However, if I just use the list as a collection in its own right, it detects when a change is made, but not that the change increased the length of the list. If you add text that has capital letters you'll see them get sorted correctly, but the lower list retains its prior count. The choice of a List initializer with the model versus an inner ForEach doesn't change the outcome, btw. If I cast that type as an Array(), effectively copying its contents, it works fine which leads me to believe there is some additional Array protocol conformance that I'm missing, but that would be unfortunate since I'm not sure how I would have known that. Any ideas what's going on here? The new type can be used with for-in scenarios fine and compiles great with List/ForEach, but has this issue. I'd like the type to not require extra nonsense to be used like an array here. import SwiftUI fileprivate struct _VExpObservable6: View { @Binding var model: ExpModel @State private var text: String = "" var body: some View { NavigationStack { VStack(spacing: 20) { Spacer() .frame(height: 40) HStack { TextField("Item", text: $text) .textFieldStyle(.roundedBorder) .textContentType(.none) .textCase(.none) Button("Add Item") { guard !text.isEmpty else { return } model.addItem(text) text = "" print("updated model #2 using \(Array(model.indices)):") for s in model { print("- \(s)") } } } InnerView(model: model) OuterView(model: model) } .listStyle(.plain) .padding() } } } // - displays the model data using an inner property expressed as // a collection. fileprivate struct InnerView: View { let model: ExpModel var body: some View { VStack { Text("Model Inner Collection:") .font(.title3) List { ForEach(model.sorted, id: \.self) { item in Text("- \(item)") } } .border(.darkGray) } } } // - displays the model using the model _as the collection_ fileprivate struct OuterView: View { let model: ExpModel var body: some View { VStack { Text("Model as Collection:") .font(.title3) // - the List/ForEach collections do not appear to work // by default using the @Observable model (RandomAccessCollection) // itself, unless it is cast as an Array here. List { // ForEach(Array(model), id: \.self) { item in ForEach(model, id: \.self) { item in Text("- \(item)") } } .border(.darkGray) } } } #Preview { @Previewable @State var model = ExpModel() _VExpObservable6(model: $model) } @Observable fileprivate final class ExpModel: RandomAccessCollection { typealias Element = String var startIndex: Int { 0 } var endIndex: Int { sorted.count } init() { _listData = ["apple", "yellow", "about"] } subscript(_ position: Int) -> String { sortedData()[position] } var sorted: [String] { sortedData() } func addItem(_ item: String) { _listData.append(item) _sorted = nil } private var _listData: [String] private var _sorted: [String]? private func sortedData() -> [String] { if let ret = _sorted { return ret } let ret = _listData.sorted() _sorted = ret return ret } }

When using NSScriptCommand, is there any way to create an NSAppleEventDescriptor from an NSDictionary with arbitrary keys without using keyASUserRecordFields? Am I correct in thinking that this constant is deprecated? I ask because there is still active documentation using it. Is there another way to return a record where the keys aren't known at compile-time?

When creating a folder in the code, it prompts that the file creation is successful, but when the folder does not exist in the "Download Container" file, do you have any permissions when creating the folder in VisionOS? static func getFileManager() -> URL { let documentsDirectory = FileManager.default.urls( for: .documentDirectory, in: .userDomainMask ).first! return documentsDirectory.appendingPathComponent("SGKJ_LIBRARY") } static func createFileLibrary() { let folderUrl = getFileManager() let fileManager = FileManager.default do { try fileManager.createDirectory( at: folderUrl, withIntermediateDirectories: true, attributes: nil ) print("Folder created successfully: \(folderUrl.path)") } catch { print("Failed to create folder: \(error.localizedDescription)") } }

I am using a URLSessionWebSocketTask. When trying to receive messages while the app is backgrounded, the receive() method fails with an NSError where the domain is NSPOSIXErrorDomain and the code is ECONNABORTED. That behavior is good. However, when this happens, the URLSessionWebSocketTask reports a closeCode of invalid, which is supposed to denote that the connection is still open. However, the connection state property is reporting completed. I feel that the closeCode property should be reporting something like abnormalClosure in this case. Either way, this seems like a bug or the documentation is incorrect.

We have an enterprise mac OS X application which uses the UserDefaults to store the onboarding states. The strange part here is that the newly installed mac OS X app is still be able to access the UserDefalus data of removed application. Because of this, the application never becomes as a freshly installed app. Is it any limitation to Enterprise mac OS X apps? Could you please provide us the resolution for this issue.

Hi Dev Forums and Quinn "The Eskimo!", Short version Is there sample NWConnection code available that behaves in a similar way to the higher level URLSession and URLRequest APIs? Long version I have not been able to make this question get past the "sensitive language filter" on the dev forums. I figured it might be 'fool' or 'heck', or the X link, but removing each of those still triggers the sensitive language filter. Please see this gist: https://gist.github.com/lzell/8672c26ecb6ee1bb26d3aa3c7d67dd62 Thank you! Lou Zell

I want decoded my base64 string and want to create image from it. NSData *data = [NSData dataWithBytes:bpData.rt_wav.data length:sizeof(bpData.rt_wav.data)]; NSMutableString *baseString = [data base64Encoding]; UIImage *image = [UIImage imageWithData:data];

We have identified an issue when using NumberFormatter with the locale set to it_IT. Specifically, when formatting numbers with exactly four integer digits, the grouping separator is not applied: for example, the number is displayed as 4000,00 instead of the expected 4.000,00. This behavior occurs only with four-digit integers; for instance, 40.000,00 is formatted correctly. The issue appears to affect only iOS 18.4 and later versions.

Hi, I work at OneSignal, a third-party SDK, and have the following two crash reports submitted by a client for the same issue. Because the crash originates from our SDK, even if the root cause may be elsewhere, the onus is on our team to try to resolve this crash. Additionally, my information is limited as this is not our own crash report. I'm trying to figure out why this crash happens and how we can address it within our SDK. Crash Reported: Fatal Exception: NSInvalidArgumentException [NSMutableDictionary __addObject:forKey:]: object cannot be nil Context: Our SDK makes a call to [NSUserDefaults(NSUserDefaults) objectForKey:] on the standardUserDefaults and passes in a non-null key. It appears further up the call stack, a null value is being added to a dictionary. I assume this is the innards of how the search list is generated. Additional Information: The client states that it seems to happen only once per user and the scale is not extremely high but it is increasing. They are unsure what happened and when. They don't have much information about the devices except it has happened on iOS 18. Log 1: 0 CoreFoundation 0x2d5fc __exceptionPreprocess 1 libobjc.A.dylib 0x31244 objc_exception_throw 2 CoreFoundation 0x15548 -[NSMutableDictionary __addObject:forKey:] 3 CoreFoundation 0x20850 -[__NSDictionaryM __apply:context:] 4 CoreFoundation 0x54700 ___CFPrefsDeliverPendingKVONotificationsGuts_block_invoke 5 CoreFoundation 0x52988 __CFDictionaryApplyFunction_block_invoke 6 CoreFoundation 0x52524 CFBasicHashApply 7 CoreFoundation 0x21040 CFDictionaryApplyFunction 8 CoreFoundation 0x7a6b0 _CFPrefsDeliverPendingKVONotificationsGuts 9 CoreFoundation 0x777d0 -[_CFXPreferences _deliverPendingKVONotifications] 10 CoreFoundation 0x776ac __108-[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:cloudConfigurationURL:perform:]_block_invoke 11 CoreFoundation 0x5cf24 normalizeQuintuplet 12 CoreFoundation 0x5cd60 -[_CFXPreferences withSearchListForIdentifier:container:cloudConfigurationURL:perform:] 13 CoreFoundation 0x5cc60 -[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:] 14 CoreFoundation 0x5c8bc _CFPreferencesCopyAppValueWithContainerAndConfiguration 15 Foundation 0xf0dcc -[NSUserDefaults(NSUserDefaults) objectForKey:] 16 OneSignalCore 0xc7c8 -[OneSignalUserDefaults keyExists:] + 61 (OneSignalUserDefaults.m:61) 17 OneSignalCore 0xc8b0 -[OneSignalUserDefaults getSavedBoolForKey:defaultValue:] + 70 (OneSignalUserDefaults.m:70) 18 OneSignalCore 0xbb10 +[OSPrivacyConsentController requiresUserPrivacyConsent] + 59 (OSPrivacyConsentController.m:59) 19 OneSignalCore 0xbc30 +[OSPrivacyConsentController shouldLogMissingPrivacyConsentErrorWithMethodName:] + 75 (OSPrivacyConsentController.m:75) 20 OneSignalCore 0x4418 +[OneSignalConfigManager shouldAwaitAppIdAndLogMissingPrivacyConsentForMethod:] + 50 (OneSignalConfigManager.m:50) 21 OneSignalOSCore 0x537c OSOperationRepo.flushDeltaQueue(inBackground:) + 140 (OSOperationRepo.swift:140) 22 OneSignalOSCore 0x4868 closure #1 in OSOperationRepo.pollFlushQueue() + 84 (OSOperationRepo.swift:84) 23 OneSignalOSCore 0x5078 thunk for @escaping @callee_guaranteed @Sendable () -> () 24 libdispatch.dylib 0x3fa8 _dispatch_client_callout 25 libdispatch.dylib 0x745c _dispatch_continuation_pop 26 libdispatch.dylib 0x1b620 _dispatch_source_latch_and_call 27 libdispatch.dylib 0x1a1e8 _dispatch_source_invoke 28 libdispatch.dylib 0xb42c _dispatch_lane_serial_drain 29 libdispatch.dylib 0xc124 _dispatch_lane_invoke 30 libdispatch.dylib 0x1738c _dispatch_root_queue_drain_deferred_wlh 31 libdispatch.dylib 0x16bd8 _dispatch_workloop_worker_thread 32 libsystem_pthread.dylib 0x3680 _pthread_wqthread 33 libsystem_pthread.dylib 0x1474 start_wqthread Log 2: Fatal Exception: NSInvalidArgumentException 0 CoreFoundation 0x2d5fc __exceptionPreprocess 1 libobjc.A.dylib 0x31244 objc_exception_throw 2 CoreFoundation 0x15548 -[NSMutableDictionary __addObject:forKey:] 3 CoreFoundation 0x168f0 __72-[CFPrefsSource mergeIntoDictionary:sourceDictionary:cloudKeyEvaluator:]_block_invoke 4 CoreFoundation 0x23ecc -[__NSFrozenDictionaryM __apply:context:] 5 CoreFoundation 0x4f82c -[CFPrefsSource mergeIntoDictionary:sourceDictionary:cloudKeyEvaluator:] 6 CoreFoundation 0x783b8 -[CFPrefsSearchListSource alreadylocked_getDictionary:] 7 CoreFoundation 0x77dfc -[CFPrefsSearchListSource alreadylocked_copyValueForKey:] 8 CoreFoundation 0x77d30 -[CFPrefsSource copyValueForKey:] 9 CoreFoundation 0x77ce4 __76-[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:]_block_invoke 10 CoreFoundation 0x77690 __108-[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:cloudConfigurationURL:perform:]_block_invoke 11 CoreFoundation 0x5cf24 normalizeQuintuplet 12 CoreFoundation 0x5cd60 -[_CFXPreferences withSearchListForIdentifier:container:cloudConfigurationURL:perform:] 13 CoreFoundation 0x5cc60 -[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:] 14 CoreFoundation 0x5c8bc _CFPreferencesCopyAppValueWithContainerAndConfiguration 15 Foundation 0xf0dcc -[NSUserDefaults(NSUserDefaults) objectForKey:] 16 OneSignalCore 0xc7c8 -[OneSignalUserDefaults keyExists:] + 61 (OneSignalUserDefaults.m:61) 17 OneSignalCore 0xcbd8 -[OneSignalUserDefaults getSavedDoubleForKey:defaultValue:] + 107 (OneSignalUserDefaults.m:107) 18 OneSignalFramework 0x8964 +[OneSignal shouldStartNewSession] + 350 (OneSignal.m:350) 19 OneSignalFramework 0xc968 +[OneSignalTracker applicationBecameActive] + 83 (OneSignalTracker.m:83) 20 OneSignalFramework 0xb894 -[OneSignalLifecycleObserver didBecomeActive] + 84 (OneSignalLifecycleObserver.m:84) ...... 55 UIKitCore 0x3ee674 -[UIApplication _run] 56 UIKitCore 0x14e88 UIApplicationMain 57 UnityFramework 0x399aef0 -[UnityFramework runUIApplicationMainWithArgc:argv:] + 96 (main.mm:96) 58 ClientsApp 0x412c main + 28 (main.mm:28)

Let’s try calculating one day after "2023/11/04 12:00 New York time". let timeZone = TimeZone(identifier: "America/New_York")! var calendar = Calendar(identifier: .gregorian) calendar.timeZone = timeZone var dateFormatter = DateFormatter() dateFormatter.timeZone = timeZone dateFormatter.locale = .init(identifier: "ja_JP") dateFormatter.dateStyle = .short dateFormatter.timeStyle = .short var dateComponents = DateComponents() dateComponents.year = 2023 dateComponents.month = 11 dateComponents.day = 4 dateComponents.hour = 12 // At New York 2023/11/04 12:00 let date1 = calendar.date(from: dateComponents)! print(dateFormatter.string(from: date1)) // Add 1 day let date2 = calendar.date(byAdding: .day, value: 1, to: date1)! print(dateFormatter.string(from: date2))``` The output is: 2023/11/04 12:00 2023/11/05 12:00 Now, let’s try the following—also to get the time one day later: let date2 = calendar.date(byAdding: .minute, value: 24 * 60, to: date1)! print(dateFormatter.string(from: date2)) This outputs: 2023/11/04 12:00 2023/11/05 11:00 What's Causing This Difference? It’s likely due to Daylight Saving Time (DST). But why do we get different results between the first and second examples?

The current live version of my app is 1.1.0, and I intended to create a new submission version, 1.1.1. However, I accidentally entered it as 1.0.8. In App Store Connect, I couldn't find any button to delete or modify the 1.0.8 version, nor could I add another submission version. As a result, I tried to upload the build for version 1.0.8 via Xcode, but an even worse issue occurred—Xcode displayed an error: "A version 1.1.0 already exists, which is higher than 1.0.8, so the upload path is closed." I can't update my app now or later, what should I do to fix it?

My app started crashing since iOS 18.4 update. Crashes started happening in 18.4 beta and are still happening in the official 18.4 RTM build (22E240). Crash is happening randomly and I cannot reproduce it, but it affects a few percent of users. As you can see in log, crash happen when NSAttributedString is loading HTML with init(data:options:documentAttributes:) with .html documentType. Crash-2025-04-02-154720.ips

I'm trying to schedule a background task that will run on an iPhone and I'm looking into creating a task request using BGProcessingTaskRequest and scheduled it using BGTaskScheduler.shared.submit(). Per earliestBeginDate documentation, this property can be used to specify the earliest time a background task will be launched by OS. All clear here. However, the question is: how is the value interpreted with respect to timezone ? Is the specified date in device timezone ? Is GMT ? Is something else ?

Hi! I was wondering if anyone else encountered similar issues and what the solution ended up being. We're encountering weird sign-in issues on our iOS version of our app. It seems like an uninstall and reinstall solves it, but the issue seems to only impact users who underwent the transfer process from one iOS device to another. What I am curious about: What is copied over from one device to another in this process? Is there a way outside of owning multiple test devices to replicate this flow? Our current suspicion is that NSUserDefaults is not being cleared by our app on first start, and that stale data is copied over during this transfer process, breaking the sign-in until a re-install wipes everything properly. Does it seem like we're on the right track with this assumption, or completely out to lunch?

We have used ::gethostname to retrieve hostname in our tunnel provider extension and found it returns "localhost" on iOS 17+. So we changed to use [[NSProcessInfo processInfo] hostName]. However it often caused 30+ delay in the extension process on a few devices and always returns "localhost". The sysdiagnose shows a lot of DNS query logs as below: default mDNSResponder 2025-03-19 17:15:12.453769 +0800 75281: 0x11ad501 [R80937] DNSServiceCreateConnection START PID[79767](ACExtension) default mDNSResponder 2025-03-19 17:15:12.453892 +0800 75281: 0x11ad501 [R80938] DNSServiceQueryRecord START -- qname: <mask.hash: 'fNnSAdyuhKXqCny8+neXvw=='>, qtype: PTR, flags: 0x15000, interface index: -1, client pid: 79767 (ACExtension), name hash: 84de01e1 default mDNSResponder 2025-03-19 17:15:12.458395 +0800 75281: 0x11ad501 [R80939] DNSServiceQueryRecord START -- qname: <mask.hash: '2X6qN/YT0yh2psKwrGWokg=='>, qtype: PTR, flags: 0x15000, interface index: 0, client pid: 79767 (ACExtension), name hash: f25c923e default mDNSResponder 2025-03-19 17:15:12.462924 +0800 75281: 0x11ad501 [R80940] DNSServiceQueryRecord START -- qname: <mask.hash: 'peyRWEblLKbNvcOXPjSeMQ=='>, qtype: PTR, flags: 0x15000, interface index: 0, client pid: 79767 (ACExtension), name hash: 83323cc4

My assumption has always been that [NSApp runModalForWindow:] runs a modal window in NSModalPanelRunLoopMode. However, while -[NSApplication _doModalLoop:peek:] seems to use NSModalPanelRunLoopMode when pulling out the next event to process via nextEventMatchingMask:untilDate:inMode:dequeue:, the current runloop doesn't seem to be running in that mode, so during -[NSApplication(NSEventRouting) sendEvent:] of the modal-specific event, NSRunLoop.currentRunLoop.currentMode returns kCFRunLoopDefaultMode. From what I can tell, this means that any event processing code that e.g. uses [NSTimer addTimer:forMode:] based on the current mode will register a timer that will not fire until the modal session ends. Is this a bug? Or if not, is the correct way to run a modal session something like this? [NSRunLoop.currentRunLoop performInModes:@[NSModalPanelRunLoopMode] block:^{ [NSApp runModalForWindow:window]; }]; [NSRunLoop.currentRunLoop limitDateForMode:NSModalPanelRunLoopMode]; Alternatively, if the mode of the runloop should stay the same, I've seen suggestions to run modal sessions like this: NSModalSession session = [NSApp beginModalSessionForWindow:theWindow]; for (;;) { if ([NSApp runModalSession:session] != NSModalResponseContinue) break; [NSRunLoop.currentRunLoop limitDateForMode:NSModalPanelRunLoopMode]; } [NSApp endModalSession:session]; Which would work around the fact that the timer/callbacks were scheduled in the "wrong" mode. But running NSModalPanelRunLoopMode during a modal session seems a bit scary. Won't that potentially break the modality?

Hey there! I faced issue in iOS 18 and newer when Spotlight search doesn't show my App in results. In older versions it works. Here is my code: func configureUserActivitity(with id: String, keywords: [String]) { let activity = NSUserActivity(activityType: id) activity.contentAttributeSet = self.defaultAttributeSet activity.isEligibleForSearch = true activity.keywords = Set(keywords) activity.becomeCurrent() self.userActivity = activity } I didn't find any reasons why it doesn't work now. Maybe I should report a bug?

When I make a local network HTTP request, an error occurs. I'm sure I've granted wireless data permissions and local network permissions, and I'm connected to the correct Wi-Fi. This problem is intermittent, but once it happens, it will keep happening, and the only way to fix it is to restart the phone. Here is the error log: sessionTaskFailed(error: Error Domain=NSURLErrorDomain Code=-1009 "似乎已断开与互联网的连接。" UserInfo={_kCFStreamErrorCodeKey=50, NSUnderlyingError=0x30398a5b0 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={_NSURLErrorNWPathKey=unsatisfied (Local network prohibited), interface: en0[802.11], uses wifi, _kCFStreamErrorCodeKey=50, _kCFStreamErrorDomainKey=1}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask .&lt;63&gt;, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask .&lt;63&gt;" ), NSLocalizedDescription=似乎已断开与互联网的连接。, NSErrorFailingURLStringKey=http://192.168.2.1:80/v1/parameters, NSErrorFailingURLKey=http://192.168.2.1:80/v1/parameters, _kCFStreamErrorDomainKey=1})

Hello, experts! I'm working on a VOIP application that handles audio calls and integrates with CallKit. The problem occurs when attempting to redial a previously made audio call from the system's call history. When I try to handle the NSUserActivity in the application(_:continue:restorationHandler:) method, it intercepts the INStartAudioCallIntent instead of the expected INStartCallIntent. Background Deprecation Warnings: I'm encountering deprecation warnings when using INStartAudioCallIntent and INStartVideoCallIntent: 'INStartAudioCallIntent' was deprecated in iOS 13.0: INStartAudioCallIntent is deprecated. Please adopt INStartCallIntent instead. 'INStartVideoCallIntent' was deprecated in iOS 13.0: INStartVideoCallIntent is deprecated. Please adopt INStartCallIntent instead. As a result, I need to migrate to INStartCallIntent instead, but the issue is that when trying to redial a call from the system’s call history, INStartAudioCallIntent is still being triggered. Working with Deprecated Intents: If I use INStartAudioCallIntent or INStartVideoCallIntent, everything works as expected, but I want to adopt INStartCallIntent to align with the current iOS recommendations. Configuration: CXProvider Configuration: The CXProvider is configured as follows: let configuration = CXProviderConfiguration() configuration.supportsVideo = true configuration.maximumCallsPerCallGroup = 1 configuration.maximumCallGroups = 1 configuration.supportedHandleTypes = [.generic] configuration.iconTemplateImageData = UIImage(asset: .callKitLogo)?.pngData() let provider = CXProvider(configuration: configuration) Outgoing Call Handle: When making an outgoing call, the CXHandle is created like this: let handle = CXHandle(type: .generic, value: callId) Info.plist Configuration: In the info.plist, the following key is defined: &lt;key&gt;NSUserActivityTypes&lt;/key&gt; &lt;array&gt; &lt;string&gt;INStartCallIntent&lt;/string&gt; &lt;/array&gt; Problem: When trying to redial the audio call from the system's call history, the NSUserActivity received in the application(_:continue:restorationHandler:) method is an instance of INStartAudioCallIntent instead of INStartCallIntent. This happens even though INStartCallIntent is listed in NSUserActivityTypes in the info.plist and I want to migrate to the newer intent as recommended in iOS 13+. Device: iPhone 13 mini iOS version 17.6.1

I'm developing a macOS application that tracks the duration of a user's session using a timer, which is displayed both in the main window and in an menu bar extra view. I have a couple of questions regarding the timer's behavior: What happens to the timer if the user closes the application's window (causing the app to become inactive) but does not fully quit it? Does the timer continue to run, pause, or behave in some other way? Will the app nap feature stop the timer when app is in-active state?