If I set the capacity of the disk cache to less than 5MB, It doesn't work. Through the print statement, I checked that the value of the currentDiskUsage did not rise at all, and I also checked that the image has been making network requests every time because there is no cached data even if I shut down and run the app again. I'm simply wondering why this is happening. Also, I wonder what kind of eviction policy the disk cache follows. I was so curious that I tried to find out through the link [here], but there seems to be no implementation of disk cache at all. Below is the code I used. I'm attaching it together just in case. import UIKit protocol Cacheable { func getCachedResponse( for path: String, completion: @escaping (Result<Data, CacheError>) -> Void ) func save( for path: String, data: Data ) } final class CacheManager { static let shared = CacheManager() private let imageCache: URLCache init() { imageCache = URLCache( memoryCapacity: 4 * 1024 * 1024, // 4MB diskCapacity: 4 * 1024 * 1024 // 4MB ) } } extension CacheManager: Cacheable { func getCachedResponse( for path: String, completion: @escaping (Result<Data, CacheError>) -> Void ) { if let url = URL(string: path), let cachedResponse = imageCache.cachedResponse(for: URLRequest(url: url)) { completion(.success(cachedResponse.data)) return } completion(.failure(.noCachedResponse)) } func save( for path: String, data: Data ) { guard let url = URL(string: path) else { return } let response = URLResponse( url: url, mimeType: nil, expectedContentLength: 0, textEncodingName: nil ) if let uiImage = UIImage(data: data), let compressedData = uiImage.jpegData(compressionQuality: 0.8) { #if DEBUG let formmatter = ByteCountFormatter() formmatter.allowedUnits = [.useMB] formmatter.countStyle = .file print(""" === Original size: \(formmatter.string(fromByteCount: Int64(data.count))) === Cached size: \(formmatter.string(fromByteCount: Int64(compressedData.count))) """) #endif let cachedResponse = CachedURLResponse( response: response, data: compressedData ) imageCache.storeCachedResponse( cachedResponse, for: URLRequest(url: url) ) } } }

URLSession.shared.downloadTask doesn't work apple watch. I monitored network traffic but it doesn't. have any activity. Data(contentsOf: URL(string: url)!) works perfectly. Also, it works perfectly in preview. What do i do? Ask for more context if necessary.

I have an app with which users take photos and upload them in batches. It's used often on older devices, in areas with less than ideal network, and for durations of a full workday - so often the device has low power. The current implementation of uploads uses an NSURLSession configured for the foreground, and as a result my users are used to having to keep the app in the foreground while an upload completes. However, these uploads are big and connectivity is often low, so this takes a long time - often users are stuck waiting with the app foregrounded for 15 minutes or so while the upload completes. So, I created a build which uses an NSURLSession configured for the background. In the ideal case, users could start the upload, put the device in their pocket and continue their workday, and the next time they open their device it will be complete. For some users this ideal case has come true. However, for others, the uploads sit in progress for an indeterminate amount of time, making no progress. My suspicion is that this is because the OS is deferring them until a time when network and power is more available. However, my users are using work devices at a work location - reliable power and network might never be available. Being able to background the app and continue working is valuable for these users, but having the upload complete promptly is essential for them. My questions are: Is it true that background configured NSURLSessions will defer network requests when connectivity or power is low, even if discretionary = NO? Is the exact behavior for when requests will be attempted in the background documented? Is there a way to reliably test background configured NSURLSessions in XCode? I've attempted throttling my connection with Charles Proxy, and using my device in Low Power Mode, but I'm unable to reproduce the request stalling behavior my users are experiencing in the wild. Is there a way to create an NSURLSession that will muscle through difficult or inefficient uploads in the background, with the same reliability as a foreground session? If not, what is Apple's recommended approach to situations like mine? I've considered queueing both a background and foreground upload, and cancelling the other once one completes, but this seems disrespectful to the user's resources. Will setting timeoutIntervalForResource to a lower value cause the OS to more aggressively attempt uploads? Or simply to throw an error sooner? I want the OS to give the upload a long time to complete, but I also want it to attempt it right away. Thanks for any information!

I'm trying to get the same path you'd get by running getconf DARWIN_USER_CACHE_DIR in the terminal, but via FileManager.default.urls(for: , in:) , but can't really find out how is there a way to do that other than running the shell script via swift?

How to use Custom URLSession in MKMapView?

this is an email I have sent to Apple with no luck: Dear Apple Developer Support Team, I am writing to seek urgent assistance with a persistent issue I have been encountering with Xcode. For several months now, every time I connect my iPhone to Xcode for development purposes, it automatically overwrites the user data of my apps with an old, seemingly random container. This issue is severely impacting my ability to continue development, as I cannot test new changes effectively. This occurs since a few months in every iOS and Xcode/macOS Version. I tried it with different Apps and Devices. Sometimes the entire Container (Documents) gets read only access so no new data can be created or changed by the user. I frequently used the replace container feature on Xcode so maybe this has something to do with it. This problem persists despite numerous attempts to resolve it on my end. I am at a critical point in my development timeline, and it is crucial for me to resolve this as soon as possible. Could you please advise on the next steps I should take to address this issue? If there are any logs or further information you require, I am more than willing to provide them. Thank you for your attention to this matter. I look forward to your prompt response and hope for a resolution soon. Best regards, Victor Lobe

I had some support tickets about dates not showing properly for customers based in the America/Merida timezone. Essentially America/Merida permanently changed to -0500 (CDT) on October 31, 2021, and it appears that the NSTimeZone does not respect this change, and reports times as -0600 (CST). Creating a little test tool with the following code: +(void) run { NSArray<NSString *> * args = [[NSProcessInfo processInfo] arguments]; if ([args count] > 1) { NSString *timezone = args[1]; NSLog(@"custom TZ: %@", timezone); NSTimeZone * tz = [NSTimeZone timeZoneWithName:timezone]; [NSTimeZone setDefaultTimeZone:tz]; } NSDate * now = [NSDate date]; NSLog(@"Testing Dates: (local timezone : %@)", [NSTimeZone localTimeZone]); NSLog(@" (default timezone: %@)", [NSTimeZone defaultTimeZone]); NSLog(@" (is DST : %@)", [[NSTimeZone defaultTimeZone] isDaylightSavingTimeForDate:now] ? @"YES" : @"NO"); NSLog(@" (current cal-tz : %@)", [[NSCalendar currentCalendar] timeZone]); NSLog(@" (current locale : %@)", [[NSLocale currentLocale] localeIdentifier]); NSLog(@"Now: %@", now); } And running with the America/Merida timezone passed in, I'm getting the following output: custom TZ: America/Merida Testing Dates: (local timezone : Local Time Zone (America/New_York (EDT) offset -14400 (Daylight))) (default timezone: America/Merida (CST) offset -21600) (is DST : NO) (current cal-tz : America/Merida (CST) offset -21600) (current locale : en_US) Now: Tue May 14 15:06:14 2024 Running the same code on Linux via the GNUStep implementation of Objective-C, I get the correct output with America/Merida showing up as CDT (ie (is DST : YES)). Are there any good ways to work around this?

Hello, I am using CAMetalDisplayLink to render my metal layer and i am trying to calculate timestamp for next render to compare with current timestamp. I did notice that timestamp from display link Update is not like Date timestamp. Looks like it depends on some kind of phone boot or another kernel process start. I did try func bootTime() -> TimeInterval? { var tv = timeval() var tvSize = MemoryLayout<timeval>.size let err = sysctlbyname("kern.boottime", &tv, &tvSize, nil, 0); guard err == 0, tvSize == MemoryLayout<timeval>.size else { return nil } return Double(tv.tv_sec) + Double(tv.tv_usec) / 1_000_000.0 } And i got calc 1715680889.6883893 real 1715680878.01257 It's close but still 10 seconds different so probably it's not kern.boottime but something similar. Anybody knows what should i use to get correct timestamp?

Hi! Not sure if this is a swift data or more a Decimal in general type of question. What's going on: I have a SwiftUI app using SwiftData, I have persisted a Model with a property "reducedPrice" of type Decimal. It's stores correctly the value. Now, I have read the value during automated tests and tried comparing the values: let reducedPrice = model.reducedPrice // swift data property let target = Decimal(4.98) // expected target value to compare to swift data value. Now if I just print the result of the comparison between those 2 I get a false result. print(reducedPrice == target) //output : false The swift data model was populated from a direct copy of another struct that comes from an JSON import using Codable+CodingKeys (I used Decimal type). What I expected: I expected it to be true. Debug Observations I did noticed that on the variable inspector both had the same magnitudes but in reality the mantissa are different. I'm attaching a screenshot. My Theory They are different just because something under SwiftData stores different way the decimal as in comparison on how I am creating the Decimal for the comparison inside the automated tests. My question Is this expected behavior? Any suggestion on best practices on how to handle this? Thank you in advance any relevant guidance is very appreciated!

My Objective-C app contains several hundreds lines of deprecated code like these: NSData *tmp = [NSKeyedArchiver archivedDataWithRootObject:singleTaskCleanUserArrayItem]; singleTaskUserArrayItem = [NSKeyedUnarchiver unarchiveObjectWithData:tmp]; New recommended methods: +archivedDataWithRootObject:requiringSecureCoding:error: +unarchivedObjectOfClass:fromData:error: How to implement the new methods in Objective-C? Forums and Documentation refer to Swift but not to Objective-C. Please give me a sample code for the two lines of code Best regards, Gerhard

Hey there, I'm trying to decode an json with an dynamic dict as value. eg. "results": [ { "id": 1799, "created_at": "2024-05-09T14:21:13.289655Z", "updated_at": "2024-05-10T11:54:25.484537Z", "email": "test@test.testh", "name": "Test", "attributes": { "name": { "firstname": "max", "lastname": "mustermann" }, "anboolen": false, "anNumber": 1, "anString": "Test" } } ] The dictionary "attributes" is always an dictionary but the content inside could be everything. for the container of results I already created an struct and using JSONDecoder to decode, but now I have the issue with the attributes part. Can anyone help me with this issue? Thanks in advance!

HI i have coded an App for Mac OSX that has embedded a Command line tool, the problem is that everything works fine while i am running from the xcode compiler, after build the final product, the app is not working properly and i can see messages like this in the console. Task .<251932> not allowed to create a new connection (existing Connection 224) Task <37752B7F-5827-4160-83C4-773B17AE72DF>.<255990> resuming, timeouts(60.0, 604800.0) QOS(0x21) Voucher (null) i was reading a link posted here but the solution is not working, some ideas are appreciated. My guess is that maybe is something related with a security setting. This is the code: NSTask *task; NSString *executableName = @"websocat"; NSString *executablePath = [[[NSBundle mainBundle] resourcePath] stringByAppendingPathComponent:executableName]; task = [[NSTask alloc] init]; [task setLaunchPath:executablePath]; Quinn “The Eskimo!" please help!

Im making an API call using notions API to access and retrieve data from my Notion page and I'm successfully making the url request and accessing the page, however I seem to be struggling with returning the actual data that I have in that page and parsing the JSON data as right now, my console only outputs the makeup of my notion page rather than the formatted and parsed data. I made a codable struct meant to replicate the structure of a notion page based off their documentation then I'm passing that struct to my JSON parsing function but my data still is not being parsed and returned. heres what I have. import Foundation struct Page: Codable, Hashable { //Codable struct for notion "Page" for defining content aswell as object representation in a codable struct of all the basic components that make up a notion page per notion's documentation let created_time: String let created_by: String let last_edited_time: String let object: String let cover: String let emoji: String let icon: String struct properties: Codable, Hashable { let title: String let dueDate: String let status: String } struct dueDate: Codable, Hashable { let id: String let type: String let date: String let start: String let end: String? //optionals added to "end" and "time_zone" as these values are set to null in the documentation let time_zone: String? } struct Title: Codable,Hashable { let id: String let type: String let title: [String] } struct annotations: Codable, Hashable { let bold: Bool let italic: Bool let strikethrough: Bool let underline: Bool let code: Bool let color: String } let English: String let Korean: String let Pronounciation: String let in_trash: Bool let public_url: String? let annotations: Bool } let url = URL(string: "https://api.notion.com/v1/pages/8efc0ca3d9cc44fbb1f34383b794b817") let apiKey = "secret_Olc3LXnpDW6gI8o0Eu11lQr2krU4b870ryjFPJGCZs4" let session = URLSession.shared func makeRequest() { if let url = url { var request = URLRequest(url: url) let header = "Bearer " + apiKey //authorization header declaration request.addValue(header, forHTTPHeaderField: "authorization") //append apikey request.addValue("2022-06-28",forHTTPHeaderField: "Notion-Version") //specify version per notions requirments let task = URLSession.shared.dataTask(with: request) { data, response, error in if let httpError = error { print("could not establish HTTP connection:\(httpError)") } else { if let httpResponse = response as? HTTPURLResponse { if httpResponse.statusCode == 200 { } else { print("invalid api key:\(httpResponse.statusCode)") } } } if let unwrapData = data { //safely unwrapping the data value using if let if let makeString = String(data: unwrapData, encoding: .utf8) { print(makeString) } else { print("no data is being returned:") } do { let decoder = JSONDecoder() //JSONDecoder method to decode api data, let codeUnwrappedData = try decoder.decode(Page.self,from: unwrapData) //Page. specifies its a struct, from: passes the data parmeter that contains the api data to be decoded //PASS STRUCTURESDATABASE STRUCT print("data:\(codeUnwrappedData)") } catch { print("could not parse json data") } if let httpResponse = response as? HTTPURLResponse { if httpResponse.statusCode == 200 { print(String(data: unwrapData, encoding: .utf8)!) } else { print("unsuccessful http response:\(httpResponse)") } } } } task.resume() } }

Over the years I’ve helped a lot of folks investigate a lot of crashes. In some cases those crashes only make sense if you know a little about how Foundation and Core Foundation types are toll-free bridged. This post is my attempt to explain that. If you have questions or comments, please put them in a new thread. Tag it with Foundation and Debugging so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Devel oper Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Crashes on the Toll-Free Bridge Certain Core Foundation (CF) types are toll-free bridged to their Foundation equivalent. That allows you to pass the Foundation object to a CF routine and vice versa [1]. For example, NSData and CFData are toll-free bridged, allowing you to pass an NSData object to a CF routine like CFDataGetBytePtr. For more information on this topic, see Toll-Free Bridged Types within Core Foundation Design Concepts in the Documentation Archive. This is cool, but it does present some interesting challenges. One of these relates to subclassing. Many of the toll-free bridge Foundation types support subclassing and, if you create a instance of your subclass and pass it to CF, CF has to do the right thing. Continuing the NSData example above, it’s legal [2] to create your own subclass of NSData with a completely custom implementation. As long as you implement the -bytes method and the length property, all the other NSData methods will just work. Moreover, this class works with CFData routines as well. If you pass an instance of your subclass to CFDataGetBytePtr, CF detects that it’s an Objective-C object and calls your -bytes method. Exciting! So, how does this actually work? It relies on the fact that CF and Objective-C types share a common object header. That object header is an implementation detail, but the first word of the header is always an indication of the class [3]. CF uses this word to distinguish between CF and Objective-C objects. Note This basic technique is used by other Objective-C compatible types, including Swift objects and XPC objects. If, for example, you call CFRetain on Swift object, it detects that this is an Objective-C compatible object and calls objc_retain, which in turns detects that this is a Swift object and calls swift_retain. To see this in action, check out the Swift Foundation open source. Continuing our NSData example, the first line of CFDataGetBytePtr uses the CF_OBJC_FUNCDISPATCHV macro to check if this is an Objective-C object and, if so, call -bytes on it. Sadly, the open source trail goes cold here, because Objective-C integration is only supported on Apple platforms. However, some disassembly reveals the presence of an internal routine called CF_IS_OBJC. (lldb) disas -n CFDataGetBytePtr CoreFoundation`CFDataGetBytePtr: … <+0>: pacibsp … <+4>: stp x20, x19, [sp, #-0x20]! … <+8>: stp x29, x30, [sp, #0x10] … <+12>: add x29, sp, #0x10 … <+16>: mov x19, x0 … <+20>: mov w0, #0x14 … <+24>: mov x1, x19 … <+28>: bl 0x19cc60100 ; CF_IS_OBJC … WARNING Do not rely on the presence or behaviour of CF_IS_OBJC. This is an implementation detail. It has changed many times in the past and may well change in the future [4]. While this is an implementation detail, it’s useful to know about when debugging. If you pass something that’s not a valid object to CFDataGetBytePtr, you might see it crash in CF_IS_OBJC. For example, this code: void test(void) { struct { int i; } s = { 0 }; CFDataGetBytePtr( (const struct __CFData *) &s ); } crashes like this: Exception Type: EXC_BREAKPOINT (SIGTRAP) … Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 CoreFoundation … CF_IS_OBJC + 76 1 CoreFoundation … CFDataGetBytePtr + 32 2 xxot … test + 24 … … In this case CF_IS_OBJC has detected the problem and trapped, resulting in an EXC_BREAKPOINT crash. However, if you pass it a pointer that looks more like an object, this might crash trying to dereference a bad pointer, which will result in a EXC_BAD_ACCESS crash. The other common failure you see occurs when you pass it an Objective-C object of the wrong type. Consider code like this: void test(void) { id str = [NSString stringWithFormat:@"Hello Cruel World!-%d", (int) getpid()]; const void * ptr = CFDataGetBytePtr( (__bridge CFDataRef) str); … } When you run this code, it throws a language exception like this: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFString bytes]: unrecognized selector sent to instance 0x6000028545a0' *** First throw call stack: ( 0 CoreFoundation … __exceptionPreprocess + 176 1 libobjc.A.dylib … objc_exception_throw + 60 2 CoreFoundation … -[NSObject(NSObject) __retain_OA] + 0 3 CoreFoundation … ___forwarding___ + 1580 4 CoreFoundation … _CF_forwarding_prep_0 + 96 5 xxot … test + 92 … ) CFDataGetBytePtr has detected this is an Objective-C object and called -bytes on it. However, this is actually an NSString [5] and NSString doesn’t implement the -bytes method. The end result is an unrecognized selector exception. [1] To be clear, when using CF objects in Objective-C you first cast the CF object to its Foundation equivalent and then call Objective-C methods on it. [2] While it’s legal to do this, it’s probably not very sensible. Subclassing Foundation types is something that might’ve made sense back in the day, but these days there are generally better ways to solve your problems. [3] Historically this word was called isa and was of type Class, that is, a pointer to the actual Objective-C class. These days things are much more complex (-: [4] Historically, CF_IS_OBJC was very simple: If the object’s isa word was 0, it was a CF object, otherwise it was an Objective-C object. That’s no longer the case. [5] The actual type is __NSCFString. That’s because NSString is a class cluster. For more about that, see Class Clusters within Cocoa Fundamentals Guide in the Documentation Archive.

I have an Electron app on macOS Sonoma (Intel arch). It has a native addon (app.node) using node-addon-api. Recently it crashed, with the stack trace (given below). What is the CF_IS_OBJC function inside the CFDataGetBytePtr function, and why did it crash there? [NSEvent addGlobalMonitorForEventsMatchingMask:NSEventMaskKeyDown handler:^(NSEvent *event) { // code using CFDataGetBytePtr function }]; [NSEvent addLocalMonitorForEventsMatchingMask:NSEventMaskKeyDown handler:^NSEvent *_Nullable(NSEvent *event) { // code using CFDataGetBytePtr function return event; }]; I have key events monitors attached using addGlobalMonitorForEventsMatchingMask and addLocalMonitorForEventsMatchingMask in my native code and they use the CFDataGetBytePtr function there. So I think the issue happened in the key event monitor handler when calling the CFDataGetBytePtr function because my native addon app.node is also present in the trace. Also from the third and fourth entry in the stack trace, it seems like it happened while the app was updating. OS Version: macOS 14.4 (23E214) Report Version: 104 Crashed Thread: 5490 Application Specific Information: Fatal Error: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS / 0x0 Thread 5490 Crashed: 0 CoreFoundation 0x19c970118 CF_IS_OBJC 1 CoreFoundation 0x19c83b280 CFDataGetBytePtr 2 .app.desktop.1inmRz 0x104a5bec0 &lt;unknown&gt; 3 .app.desktop.1inmRz 0x104a57b28 &lt;unknown&gt; 4 app.node 0x104a80a7c [inlined] Napi::details::CallbackData&lt;T&gt;::Wrapper::lambda::operator() (napi-inl.h:117) 5 app.node 0x104a80a7c Napi::details::WrapCallback&lt;T&gt; (napi-inl.h:79) 6 app.node 0x104a80a24 Napi::details::CallbackData&lt;T&gt;::Wrapper (napi-inl.h:112) 7 Electron Framework 0x11472e5e0 v8impl::(anonymous namespace)::FunctionCallbackWrapper::Invoke (js_native_api_v8.cc:441) 8 &lt;unknown&gt; 0x147e105f8 &lt;unknown&gt; 9 &lt;unknown&gt; 0x1401d0814 &lt;unknown&gt; 10 &lt;unknown&gt; 0x1401d0a9c &lt;unknown&gt; 11 &lt;unknown&gt; 0x147f19368 &lt;unknown&gt; 12 &lt;unknown&gt; 0x147e0aab0 &lt;unknown&gt; 13 &lt;unknown&gt; 0x1401d0e00 &lt;unknown&gt; 14 &lt;unknown&gt; 0x1401d1ac0 &lt;unknown&gt; 15 &lt;unknown&gt; 0x147f19368 &lt;unknown&gt; 16 &lt;unknown&gt; 0x147e0aab0 &lt;unknown&gt; 17 &lt;unknown&gt; 0x1401d1494 &lt;unknown&gt; 18 &lt;unknown&gt; 0x1401d20dc &lt;unknown&gt; 19 &lt;unknown&gt; 0x147e4c1b4 &lt;unknown&gt; 20 &lt;unknown&gt; 0x147f1b5f8 &lt;unknown&gt; 21 &lt;unknown&gt; 0x147e3b754 &lt;unknown&gt; 22 &lt;unknown&gt; 0x147e0b618 &lt;unknown&gt; 23 Electron Framework 0x10ee0c49c v8::internal::(anonymous namespace)::Invoke (simulator.h:178) 24 Electron Framework 0x10ee0d08c v8::internal::(anonymous namespace)::InvokeWithTryCatch (execution.cc:475) 25 Electron Framework 0x10ee0d1e0 v8::internal::Execution::TryRunMicrotasks (execution.cc:576) 26 Electron Framework 0x10ee37364 v8::internal::MicrotaskQueue::PerformCheckpoint (microtask-queue.cc:176) 27 Electron Framework 0x1146cce9c node::InternalCallbackScope::Close (callback.cc:137) 28 Electron Framework 0x1146ccb64 node::InternalCallbackScope::~InternalCallbackScope (callback.cc:92) 29 Electron Framework 0x1147112b4 node::Environment::RunTimers (env.cc:1376) 30 Electron Framework 0x10daf9980 uv__run_timers (timer.c:178) 31 Electron Framework 0x10dafcb3c uv_run (core.c:465) 32 Electron Framework 0x10dc944d4 electron::NodeBindings::UvRunOnce (node_bindings.cc:891) 33 Electron Framework 0x110e2016c base::TaskAnnotator::RunTaskImpl (callback.h:156) 34 Electron Framework 0x110e3cea4 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork (task_annotator.h:89) 35 Electron Framework 0x110e8851c base::MessagePumpCFRunLoopBase::RunWorkSource (message_pump_apple.mm:444) 36 Electron Framework 0x10da7ad7c base::apple::CallWithEHFrame 37 Electron Framework 0x110e876a4 base::MessagePumpCFRunLoopBase::RunWorkSource (message_pump_apple.mm:415) 38 CoreFoundation 0x19c89deac __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 39 CoreFoundation 0x19c89de40 __CFRunLoopDoSource0 40 CoreFoundation 0x19c89dbb0 __CFRunLoopDoSources0 41 CoreFoundation 0x19c89c79c __CFRunLoopRun 42 CoreFoundation 0x19c89be08 CFRunLoopRunSpecific 43 HIToolbox 0x1a7036ffc RunCurrentEventLoopInMode 44 HIToolbox 0x1a7036e38 ReceiveNextEventCommon 45 HIToolbox 0x1a7036b90 _BlockUntilNextEventMatchingListInModeWithFilter 46 AppKit 0x1a00f496c _DPSNextEvent 47 AppKit 0x1a08e6de8 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] 48 AppKit 0x1a00e7cb4 -[NSApplication run] 49 Electron Framework 0x110e89244 base::MessagePumpNSApplication::DoRun (message_pump_apple.mm:805) 50 Electron Framework 0x110e87068 base::MessagePumpCFRunLoopBase::Run (message_pump_apple.mm:156) 51 Electron Framework 0x110e3d9a0 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run (thread_controller_with_message_pump_impl.cc:646) 52 Electron Framework 0x110e05a98 base::RunLoop::Run (run_loop.cc:134) 53 Electron Framework 0x10ffcbcd0 content::BrowserMainLoop::RunMainMessageLoop (browser_main_loop.cc:1094) 54 Electron Framework 0x10ffcd744 content::BrowserMainRunnerImpl::Run (browser_main_runner_impl.cc:158) 55 Electron Framework 0x10ffc964c content::BrowserMain (browser_main.cc:34) 56 Electron Framework 0x10de12aa8 content::RunBrowserProcessMain (content_main_runner_impl.cc:712) 57 Electron Framework 0x10de13b1c content::ContentMainRunnerImpl::RunBrowser (content_main_runner_impl.cc:1299) ...

When following this guide https://developer.apple.com/documentation/xcode/embedding-a-helper-tool-in-a-sandboxed-app I cannot run the embedded binary. I'm getting this error: "zsh: trace trap" I would like to be able to use the embedded binary for NativeMessaging with for example Chrome but I can't figure out how to allow it to be executable even with sandboxing enabled. How are Strongbox able to do this with their afproxy executable?

Hi all, I am working on macOS 14.4.1 and I am having an issue with the Desktop Spaces feature. Calling defaults read com.apple.spaces.plist gives me a list of all current spaces, which reports the existence of a phantom Space that cannot be seen nor interacted with. The ID of that Space leads me to the following: which shows that space 23 is associated with the Dashboard feature, that does not exist in Sonoma! I have tried to: restart the computer, forcefully disable the dashboard with defaults write com.apple.dashboard mcx-disabled -boolean YES killall Dock Neither attempt erased the phantom Space, which creates conflicts in my setup. I have tried completely disabling Widgets in the Preferences, closing all apps, deleting every space (including the "current" one, by creating a new one to substitute it) and restarting the Mac. After this, the id of the dashboard space changed: but it is still there. I do not know which step changed its id, because to my knowledge the com.apple.spaces.plist file takes a while to be updated (https://apple.stackexchange.com/questions/388449). But no hints on how to erase it. The specific issues I am having are that this phantom space prevents any software that reads the Spaces state, to save it, from working correctly (e.g. DisplayMaid, Workspaces). In particular, I am now developing a Hammerspoon (https://www.hammerspoon.org/) module to do just that, to set it precisely to my liking: https://github.com/tplobo/restore-spaces. Listing the spaces to cycle through them always reports this phantom space, and since it cannot be identified as the "non-existing" one (up until the time it breaks one of the Lua commands that manage spaces), I am unable to exclude it somehow to continue development. Is there a command to restart the Spaces feature, to completely erase all spaces and check if this removes this phantom Space? Otherwise, any alternative suggestions? I have already posted this in the standard forum, but no luck there. Thank you,

Is the timeout for session-level authentication challenge handling documented somewhere? For example, if I get the urlSession(_:didReceive:) callback for server trust authentication, how long do I have to invoke the completion handler (or return from the callback if using Swift Concurrency)? Or is this completely dependent on the server's settings?

Hello! Recently, the following crash issue began to occur. 0 libswiftCore.dylib 0x000000019ffaa3c8 closure #1 in closure #1 in closure #1 in _assertionFailure+ 238536 (_:_:file:line:flags:) + 228 1 libswiftCore.dylib 0x000000019ffaa2a0 closure #1 in closure #1 in _assertionFailure+ 238240 (_:_:file:line:flags:) + 332 2 libswiftCore.dylib 0x000000019ffa9c2c _assertionFailure+ 236588 (_:_:file:line:flags:) + 184 3 libswiftCore.dylib 0x000000019ffac4fc specialized BidirectionalCollection._index+ 247036 (_:offsetBy:) + 1280 4 libswiftCore.dylib 0x00000001a016d630 String.UTF16View._indexRange+ 2086448 (for:from:) + 184 5 libswiftCore.dylib 0x00000001a018561c __StringStorage.getCharacters+ 2184732 (_:range:) + 112 6 libswiftCore.dylib 0x00000001a0185720 @objc __StringStorage.getCharacters+ 2184992 (_:range:) + 36 7 CoreFoundation 0x00000001a16893e0 __CFStringEncodeByteStream + 1864 8 Foundation 0x00000001a0527c94 -[NSString+ 208020 (NSStringOtherEncodings) getBytes:maxLength:usedLength:encoding:options:range:remainingRange:] + 260 ... It seems like assert is being called. Can you tell me a case that could be the cause? Also, this is a code I have been using for a long time, but recently it started crashing. Have there been any internal changes recently? Please understand that the entire crash log cannot be attached for security reasons. Any help would be greatly appreciated!

AppTrackingTransparency popup not show on iOS17.4.1 Some devices can, while others cannot