“eskimo”

So, lemme see if I understand you correctly: You have some sort of program running on macOS, aka the parent. The parent spawns a child process that runs an existing executable. That executable is built by someone else and you can’t modify it. That executable calls fsync. You want the parent to learn about this call. And arbitrarily delay the calling thread within the child. Until some point in the future, when the parent either: Allows the calling thread to continue into the kernel and run the fsync Or instructs the call fail with an error All of this has to work in a supported fashion, so no SPI and no disabling SIP. Is that right? Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

For those reading along at home, hjug created three separate threads about related issues: This one Keychain access after an A → B → A round-trip transfer: can a new build signed by Team A still read the items the original Team A build wrote? Preserving guest-account credentials after a completed A → B transfer (keychain prefix change, no build released from B) [quote='853185021, hjug, /thread/853185, /profile/hjug'] The distribution certificate and provisioning profile that Team A used to sign the build which is live right now will expire. [/quote] I addressed this point in you other thread. In short, these credentials only matter when you submit your app. Regarding StoreKit and APNs, that’s not really my area of expertise. App Store Connect Help > Transfer an app has a bunch of advice about a bunch of different topics. If you need help beyond that I recommend that you start a new thread in the appropriate subtopic here on the forums. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Supp

I recommend that you try reproducing this without your third-party tooling. If you can do that, we can talk about the Apple side of this. However, if the issue only shows up with your third-party tooling in play, that’s something you should ask the vendor about. My experience is that third-party LLMs commonly use a custom SBPL-based sandbox, and that’s not something we support. See this thread for more about that. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

I recommend that you have a read of this thread, where we’ve been discussing this issue and various related ones. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

[quote='853064021, maliyilmaz0, /thread/853064, /profile/maliyilmaz0'] This is confusing because Developer ID is listed while macOS is not listed under Platform Support. [/quote] I agree that this is confusing. My interpretation of this is that if Wi-Fi Aware were supported on the Mac, it’d support App Store and Developer ID distribution. Certainly, it’s not supported right now. If you create provision profiles from an App ID with Wi-Fi Aware enabled, this is what you see: % security cms -D -i Test853064_iOSDev.mobileprovision | plutil -p - { … Entitlements => { application-identifier => SKMME9E2Y8.com.example.Test853064 com.apple.developer.team-identifier => SKMME9E2Y8 com.apple.developer.wifi-aware => [ 0 => Publish 1 => Subscribe ] get-task-allow => true keychain-access-groups => [ 0 => SKMME9E2Y8.* 1 => com.apple.token ] } … } % security cms -D -i Test853064_MacDev.provisionprofile | plutil -p - { … Entitlements => { com.apple.application-identifier => SKMME9E2Y8.com.ex

There are two well-trodden paths for custom communication over Thunderbolt: TCP/IP RDMA, as described in TN3205 Low-latency communication with RDMA over Thunderbolt It sounds like you want to dig into the second one (-: Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

To start, I want to drop a link to your other thread, which is closely related. And I presume you’ve read App ID Prefix Change and Keychain Access. If not, read it now. [quote='852918021, hjug, /thread/852918, /profile/hjug'] Q1 — App container across a cross-team update. Does an app's sandbox container … persist when a user updates in place to a build signed by the recipient team? [/quote] Yes. [quote='852918021, hjug, /thread/852918, /profile/hjug'] Q2 — identifierForVendor. Does identifierForVendor stay stable across an app transfer … ? [/quote] No. IDFV is quite brittle. It’s also something I found that folks overuse. It’s beneficial when you have multiple apps and you want to correlate activity across those apps on the same device. If you have a single app you’re generally better off generating your own unique ID and storing it either in a file in your app’s container or in the keychain, or both (-: [quote='852918021, hjug, /thread/852918, /profile/hjug'] Q3 — Transferring back. … Q5 — Recommended practi

I presume you’ve read App ID Prefix Change and Keychain Access. If not, read it now. [quote='853212021, hjug, /thread/853212, /profile/hjug'] Q1 — Does the App ID Prefix revert? [/quote] After a transfer the App ID prefix is set to the destination Team ID. So, If the app previously used team A’s Team ID then you’ll get back to where you started. OTOH, if the app previously used a unique App ID prefix then… well… I’m not sure what’ll happen. That’s not a case I’ve previously dealt with. So my advice here is that you check whether the app that’s currently shipping on the App Store is using a unique App ID prefix. If it isn’t — so it’s using team A’s Team ID — then you’re all set. If it is then we’ll need to talk some more. [quote='853212021, hjug, /thread/853212, /profile/hjug'] Q2 — Does a newly issued certificate or profile have any bearing? [/quote] Not really. For an App Store app, distribution signing identities and provisioning profiles are only relevant at the point that you submit the app to the store.

I recommend that you file a bug about this. User space restarts are more-or-less equivalent to kernel panics, in the sense that they’re always Apple’s issue to resolve. Please post your bug number, just for the record. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

Sorry it took me so long to reply here. It’s been a hectic week. Lemme start out with some sort of semi-official answer: Yes, we recognise that this situation is less than ideal and we’re working on ways to improve things (r. 190253666). I have no details as to what that’ll be, or any sort of timeline to share. Oh, and thanks for all the work you’ve put into answering questions on the forums over the years. And with that out of the way, I want to give you my own thoughts about two aspects of this: What should this look like? What do you do right now? Regarding the first, my take on this is that the forums are primarily a place to help folks with Apple APIs and tools. These are things that we can discuss in public, and having that discussion in public is beneficial for everyone involved. However, there is a set of things that we simply can’t handle here on the forums. For example, if you have a problem with your programme enrolment, fixing that will likely require a bunch of private info, which isn’t appropria

[quote='911063022, blacksun, /thread/852618?answerId=911063022#911063022, /profile/blacksun'] All of the crash reports with these signatures come from watchOS 26.2 (23S303), 26.2.1 (23S314) and 26.3 (23S620). We have not seen either signature on any other watchOS version, including watchOS 27. [/quote] OK. I used some internal tooling to check whether your experience is typical, and that seems to be the case. That is: This bug affected a lot of watchOS apps… … in the the 26.2 and 2.6.3 timeframe. After which the occurrences dropped off to almost nothing. Given that, I’m not sure it’s worth pushing harder on this. If you have users reporting this, you can advise them to update to either watchOS 26.x, x > 3, or watchOS 27. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

[quote='911124022, Tawasi, /thread/852591?answerId=911124022#911124022, /profile/Tawasi'] Feedback ID: FB25285950 [/quote] Thanks. Internally, we’ve marked that as a dup of the bug mentioned that other thread (FB25187024), so Feedback Assistant should let you know if and when this is fixed. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

[quote='911090022, vishalsehgal, /thread/852213?answerId=911090022#911090022, /profile/vishalsehgal'] My understanding is … [/quote] That sounds about right. [quote='911090022, vishalsehgal, /thread/852213?answerId=911090022#911090022, /profile/vishalsehgal'] Since the safety on the C++ side depends entirely on how the C++ code is written, could you share the guidelines for doing this correctly? [/quote] Not really. The span facility is a standard part of C++; there’s nothing Apple-specific about it. Thus, you can take avantage of of the numerous C++ resources out there: books, websites, LLMs, and so on. I don’t use C++ a lot [1] so I don’t have any concrete recommendations. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com [1] I read a lot of C++, but most of the time I write C++ it’s to exercise Swift / C++ interoperability (-:

I’m confused. This works for me from Terminal on macOS 27: % sw_vers ProductName: macOS ProductVersion: 27.0 BuildVersion: 26A428 % codesign --verify --strict --verbose=6 -R '=anchor apple' /usr/bin/printf /usr/bin/printf: valid on disk /usr/bin/printf: satisfies its Designated Requirement /usr/bin/printf: explicit requirement satisfiedAre you spawning codesign from some other environment? If so, what is that? Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

Consider the backtrace of the crashing thread: Thread 0 name: tid_103 Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib … __pthread_kill + 8 1 libsystem_pthread.dylib … pthread_kill + 268 2 libsystem_c.dylib … abort + 148 3 Senso.Client.Mobile … 0x10451c000 + 225524 4 Senso.Client.Mobile … 0x10451c000 + 1207380 5 Senso.Client.Mobile … 0x10451c000 + 1811412 6 Senso.Client.Mobile … 0x10451c000 + 262084 7 Senso.Client.Mobile … 0x10451c000 + 2763728 8 dyld … start + 6928Your app has crashed because code within your app (frame 3) has called abort( (frame 2). To make progress you’ll need to symbolicate that backtrace to uncover the identity of the code in frame 3. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com