“eskimo”

[quote='880644022, alexfs123, /thread/819160?answerId=880644022#880644022, /profile/alexfs123'] after doing a Preview on a mounted drive a few times I'm not able to unmount it cleanly [/quote] What does lsof report? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

AFAIK there’s no magic here. And I tried reproducing this on my main work Mac and didn’t have a problem. Specifically: On macOS 26.3.1, I downloaded the current 26.4rc seed (UniversalMac_26.4_25E243_Restore.ipsw). Using an off-the-shelf Virtualization framework app [1], I created a VM from that. It installed and booted, and I was able to run all the way through MacBuddy and get to the Finder. I’m not sure why this is failing in your environment. This Mac is production hardware that’s only ever run released system software (plus various Xcode beta seeds). When I wrote the above I hadn’t yet installed Xcode 26.4rc. So I installed that and repeated the test. It didn’t change anything. Things continued to work. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] VirtualBuddy 2.1.

[quote='880707022, chapo213, /thread/818938?answerId=880707022#880707022, /profile/chapo213'] I need to support both use case (exec and dylib). [/quote] OK. [quote='880707022, chapo213, /thread/818938?answerId=880707022#880707022, /profile/chapo213'] [Library validation] does not apply in my scenario since the library is provided by a third party [/quote] I’d like to better understand that. It’s quite common for Mac apps to use libraries created by other developers, and they retain library validation by re-signing those libraries. Is there something preventing you from doing that in this case? The most obvious case where folks need to disable library validation is that their app supports in-process plug-ins, where those plug-ins are built and shipped by other third-party developers in a way that’s completely independent of the main app’s vendor. Is that what’s happening here? Because if you’re managing these plug-in releases then it’d be better to have you re-sign the plug-in and leave library validation enab

Thanks for bringing this to the forums. The com.apple.token keychain access group, aka kSecAttrAccessGroupToken, isn’t a normal keychain access group. Rather, it’s a special group that holds all of the credentials that the system finds in CryptoTokenKit (CTK) tokens. Given that, you can’t add credentials to this group directly. It is possible to create a persistent CTK token, that is, one that’s not tied to smart card hardware. If you do that then the credentials published by that token will be available to all apps that are set up to use token-based credentials. It’s not clear whether this approach will work for your ultimate goal: [quote='819445021, h-noto, /thread/819445, /profile/h-noto'] so that Microsoft Edge for iOS … can … use it for client certificate authentication [/quote] My advice is that you first prototype this with an actual smart card [1]. If you can get that working, it’d be worth exploring the virtual token option. Finally, if you’re curious how an app can work with token-based credentials,

[quote='819454021, oleksandr91, /thread/819454, /profile/oleksandr91'] Is this a known macOS bug? [/quote] I’m pretty sure I’ve seen this before. IIRC the problem was reported by a third-party developer and I found it super hard to reproduce, and thus I’m not sure if a bug got filed. Sorry to be vague about the details; I searched my records but was unable to track down the conversation. Anyway, it sounds like you can easily reproduce this. Given that, I think it make sense for you to file your own bug about it. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='819449021, Team Tank Wars, /thread/819449, /profile/Team+Tank+Wars'] the remaining uploads do not proceed in the background and appear to be suspended. [/quote] Suspended forever? Or just a delayed? If you leave the watch in that state for a day, does it eventually attempt these stalled uploads? For context, there are URLSession and watchOS aspects to this. On the URLSession front, the system is free to delay background session transfer until an opportune time. While I have a lot less experience with this on the watchOS side, on iOS this often means that the transfer is deferred until overnight, when the device has both Wi-Fi and mains power. So I’m curious if the same thing is happening on the watch. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

It looks like you’re trying to report a bug. If so, the way to do that is via Feedback Assistant. See my Bug Reporting: How and Why? for a lot more info about that process. Please post your bug number, just for the record. FWIW, I’m seeing the same issue with Swift Playground 4.7 on my Mac, so this is not iPad specific. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

It’s not clear what you’re asking for here: Are you a developer who wants to use TestFlight to run a test programme? Are you a user whose been invited to a test programme by a developer? Are you a user who would like to be invited to a test programme by a developer? Or something else? Please clarify. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='819406021, eddiewangyw, /thread/819406, /profile/eddiewangyw'] With ad-hoc signing … the system treats each build as a new app. [/quote] Correct. If you’re curious about the mechanics of this, have a read of TN3127 Inside Code Signing: Requirements. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='819553021, robonaren, /thread/819553, /profile/robonaren'] my understanding is that root daemons typically don’t run sandboxed [/quote] Correct. While it is possible to enable the App Sandbox on a daemon, folks don’t normally do that. [quote='819553021, robonaren, /thread/819553, /profile/robonaren'] The plugin only connects to the legitimate daemon [/quote] The canonical way to do that is by setting the privileged flag. I have a link to an explanation of that in XPC Resources. You could also validate the peer’s signature. Again, I have a link to info about that in XPC Resources IMPORTANT This works in this direction because you control the daemon’s main executable. [quote='819553021, robonaren, /thread/819553, /profile/robonaren'] The daemon only accepts connections from trusted clients [/quote] There isn’t a good way to achieve this goal, presuming that this set of trusted clients includes an authorisation plug-in. The issue is that authorisation plug-ins are in-memory plug-ins, so you don’t control

Are you really supplying an empty Apple Account string? Or did you just redact that for the sake of this post? Regardless, I have a couple of generic bits of advice here: To get started, use the store-credentials subcommand. It runs you through the authentication process interactively, which can help head off the most obvious errors. Make sure you’re using an app-specific password, rather than the password for your Apple Account. An app-specific password should have the format aaaa-aaaa-aaaa-aaaa, where each a is a lowercase letter. If you get stuck, switch to authenticating with an API key. IME it’s often easier to get that working. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. [quote='880678022, HuangKun, /thread/819403?answerId=880678022#880678022, /profile/HuangKun'] Could this App Review rejection have triggered a backend review of our account affecting notarization? [/quote] I can’t comment on that. See this post for a little more background about this “No comment.” Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don’t have time to go through the doc properly today, but we just published a new technote about RDMA over Thunderbolt: TN3205 Low-latency communication with RDMA over Thunderbolt Please read it through and reply here with your thoughts. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for providing that extra context. There are two ways that Apple can grant you access to managed entitlements, via an old process or a new process. I explain those processes in detail in Using the Multicast Networking Additional Capability (this is for a different entitlement, but you should recognise the processes). It seems that your teams are configured with a mix of the old and the new. For example, WEJZZZZZZZ is using the old process whereas NWKYYYYYYY is using the new process. I don’t have any insight into the old process setup, but I can see the setup for new process stuff and I’ve confirmed that NWKYYYYYYY is set up correctly. However, to use it you have to use the new process, rather than the old process. To learn more about this, read Account > Reference > Provisioning with capabilities. At the bottom of that page is a Migrating additional entitlements to capabilities section. This explains how you can request that we migrate you from the old process to the new process. I recommend that

Please try again after a restart. I went through this process myself and hit very similar symptoms. I found that fskitd had a bunch of threads stuck like this: 816 _dispatch_call_block_and_release + 32 (libdispatch.dylib + 7004) [0x19b4ceb5c] 816 ??? (fskitd + 132900) [0x100988724] 816 ??? (fskitd + 86796) [0x10097d30c] 816 ??? (fskitd + 87588) [0x10097d624] 816 ??? (fskitd + 50740) [0x100974634] 816 objc_sync_enter + 20 (libobjc.A.dylib + 70452) [0x19b245334] 816 816 __ulock_wait2 + 8 (libsystem_kernel.dylib + 60532) [0x19b656c74] *816 ??? (kernel.release.t6031 + 6477368) [0xfffffe0008ea1638] (blocked by turnstile waiting for fskitd [634] thread 0x30444d) Worse yet, the number of threads kept growing, every time I retried the mount command! I was able to clear this by restarting, after which the mount command worked as expected. I did some spelunking based on internal resources and it seems that these threads are deadlocked due to some previous error starting the extension. Hence my idea to restart, in an a