eskimo

D’oh! I’ve seen that before and I always forget to warn folks about it. I never hit it myself because: I try to avoid storing code on the desktop. That can result in other weird problems [1]. I don’t have Desktop and Documents Folders syncing enabled. Anyway, I’m glad you found it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Because the desktop is protected by MAC. See On File System Permissions for more about that.

The notary service requires that all code be signed with a valid Developer ID signing identity. If you don’t sign your code, it will be rejected by notary. For general advice on how to sign and package code, see: Creating distribution-signed code for macOS Packaging Mac software for distribution The top of the first doc says: If you use a third-party developer tool to build your app, consult its documentation for advice specific to that tool. and I’m gonna reiterate that here. It’s likely that your tool vendor, or the community of developers who use your tool, has more experience on how to sign the code that it produces. [quote='776414021, gokulthanu, /thread/776414, /profile/gokulthanu'] We have tried to codesignin the .app file but [errSecInternalComponent] [/quote] I have a forums post about exactly that: Resolving errSecInternalComponent errors during code signing. In this case, the unable to build chain to self-signed root for signer message suggests you’re missing an intermediate, as explained in Fixing

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. so we're not checking it I recommend that you do. If the probability is about 10%, you’ll need at most 50 manual tests to confirm whether this is an API issue or not. That’s probably less than an hour’s work. Or you could automate it with an Xcode UI test. Anyway, the reason why I ask is because, if the problem reproduces in Settings, you know that your code is correct, in which case the next step is to file a bug report. And that brings me to this: Can you process this order number FB16819345 I had a look at that bug and it’s on its way back to you with a request for more info. When filing a bug report about Wi-Fi, it’s vital that you include a sysdiagnose log taken shortly after reproducing the problem. Better yet, follow the Wi-Fi for iOS/iPadOS instructions on our Bug Reporting > Profiles and Logs page. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support

OK. That suggests that you have the certificate but not the private key. To confirm that: In Keychain Access, choose Certificates at the top. Find your certificate there. Now switch to My Certificates. Is it still there? To sign code you need a code-signing identity, that is, a code-signing certificate and the private key that matches the public key in that certificate. If you only have the certificate, you can’t sign because you’re missing the private key. It’s very common for folks to lose their private key. For some backstory on that, see Certificate Signing Requests Explained. Fortunately, for Apple Distribution that’s easy to fix: Just generate a new distribution certificate. IMPORTANT This fix make sense for most, but not all, certificate types. One that can cause real problems is the Developer ID signing identities use for directly distributed macOS products. If you do end up working on the Mac, see The Care and Feeding of Developer ID. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technic

FYI, self-signed certificates aren’t really useful for code signing on macOS. They are better than ad hoc signing, but not much. My advice is that you use Apple Development signing identities for development code. Also, the com.apple.security.device entitlement isn’t a thing. There are two groups of entitlements relevant in this context: App Sandbox entitlements Hardened Runtime entitlements The first only relevant if you’ve explicitly enabled App Sandbox. The second is relevant to all programs, because all programs should have the hardened runtime enabled. However, for testing purposes you can opt out of the hardened runtime, which disables all of its additional security checks. Regardless, neither page list com.apple.security.device. For HID devices there is an old school com.apple.security.device.hid entitlement, but it’s been deprecated in favour of com.apple.security.device.usb, documented here. And both of those are for App Sandbox. Honestly, I don’t think this that any of the above is relevant to your

[quote='829013022, alexfs123, /thread/776322?answerId=829013022#829013022, /profile/alexfs123'] There's no macOS > File System Extension template in the Xcode 16.3 beta 2, am I missing something? [/quote] I haven’t yet downloaded 16.3b2 [1] but it’s certainly there in 16.3b1. IMPORTANT It’s a target template, not a project template. Open or create a new macOS app project and then choose File > New > Target. Regarding your other points, lets get you up and running on the template first and then we can come back to them. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] The perils of answering forums questions from my local coffee shop (-:

[quote='828891022, Kray16, /thread/776043?answerId=828891022#828891022, /profile/Kray16'] In my implementation I am using Golang to call C code, how is the XPC lifecycle affected by this? [/quote] It isn’t, at least not from a launchd perspective. I’m presuming that your C code is linked into your executable and thus running in the same process as your Go code. In that case, this split doesn’t affect launchd or the XPC API: launchd just starts a process that runs your executable. It doesn’t case what language you write this in. Likewise, the XPC API doesn’t care about the language you use for your main function. [quote='828891022, Kray16, /thread/776043?answerId=828891022#828891022, /profile/Kray16'] Is the XPC listener launched on demand, or does it stay running as long as the daemon? [/quote] OK, so an XPC listener isn’t launched. Rather, it’s something that you start within your process by calling XPC APIs. Your launchd daemon is launched. Whether that’s on demand on not depends on how you’ve configured yo

I don’t have any answers for you here, but I wanted to explain why that’s the case: DevForums is primarily focus on helping developers with the APIs in our platform SDKs. Packet Filter is not considered an API [1]. Rather, it’s an implementation detail of various macOS networking systems. If you’re asking about this because you plan to ship a product based on PF, please don’t do that. There are better options, and I’m happy to help you adopt them. If you’re doing this on your own Mac, or Macs you manage, then I recommend that you bounce on over to Apple Support Community, run by Apple Support, and specifically in the Business and Education topic area, where you’re more likely to find folks with experience with this tool. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] And we now say as much, in TN3165 Packet Filter is not API.

The best way to investigate problems like this is to run syspolicy_check against your app. That usually helps you pinpoint the source of this problem. If that fails, I have a bunch of additional info in Resolving Trusted Execution Problems. Oh, and the #1 source of this problem is folks disabling library validation when they don’t need to. See Resolving Gatekeeper Problems Caused by Dangling Load Command Paths. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You had me second guessing myself there for a minute (-: But, no, Accepted is the correct terminal state. Consider this: % notarytool history …credentials… Successfully received submission history. history -------------------------------------------------- createdDate: 2025-03-06T12:04:58.570Z id: 2f6882e6-0f28-49f6-955f-8f7a414eac3c name: TestTranslocate.dmg status: Accepted -------------------------------------------------- … -------------------------------------------------- createdDate: 2023-11-01T17:55:16.319Z id: cca5d303-b1f2-4338-8350-66c9c386e100 name: [redacted].zip status: Invalid -------------------------------------------------- … And if you want to double check, fetch the notary log: % notarytool log …credentials… 2f6882e6-0f28-49f6-955f-8f7a414eac3c { logFormatVersion: 1, jobId: 2f6882e6-0f28-49f6-955f-8f7a414eac3c, status: Accepted, statusSummary: Ready for distribution, statusCode: 0, archiveFilename: TestTranslocate.dmg, uploadDate: 2025-03-06T12:04:59.702Z, sha256: 5ce15b85a0b89c79287de2813

Error 3 in the NERelayErrorDomain is NERelayManagerClientErrorServerUnreachable, with a doc comment of The relay server prematurely disconnected the connection. That suggests that the system reached out to the relay you supply to confirm its setup, and it failed to respond correctly. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m gonna respond to your NEHotspotConfigurationManager question here. I don’t know enough about Bluetooth to answer your other question. I recommend that you put that question in a new thread. Put it in App & System Services > Core OS and tag it with Core Bluetooth. That’ll increase the chances of it being seen by folks with Bluetooth experience. Regarding NEHotspotConfigurationManager: [quote='776432021, Wise-Lee, /thread/776432, /profile/Wise-Lee'] Are there known scenarios where this method would block for extended periods … ? [/quote] What do you mean by “block”? The apply(_:) method is asynchronous. You call it and then, at some point in the future, it calls the completion handler. Given that, there are two potential interpretations of the work “block”: The apply(_:) method takes a long time to return. The apply(_:) returns quickly but there’s a long delay before it calls the completion handler. The first would be most unusual. If you see that, it’s definitely bugworthy. The second is expected. T

Consider the crashing thread backtrace: Thread 1 name: com.apple.uikit.xpc-service Thread 1 Crashed: 0 CoreFoundation … 0x197e6d000 + 185852 1 libobjc.A.dylib … objc_exception_throw + 88 2 CoreFoundation … 0x197e6d000 + 423612 3 CoreFoundation … 0x197e6d000 + 419760 4 CoreFoundation … 0x197e6d000 + 75256 5 MyAppXX … startup_check_root + 12380 6 libdispatch.dylib … 0x19fc2b000 + 8776 7 libdispatch.dylib … 0x19fc2b000 + 16296 8 libdispatch.dylib … 0x19fc2b000 + 46540 9 libdispatch.dylib … 0x19fc2b000 + 49444 10 libdispatch.dylib … 0x19fc2b000 + 95116 11 libdispatch.dylib … 0x19fc2b000 + 93144 12 libsystem_pthread.dylib … _pthread_wqthread + 288 13 libsystem_pthread.dylib … start_wqthread + 8 Frames 13 through 6 suggest that this is a Dispatch worker thread running a block on a queue. Frame 5 is your code. Frames 4 through 2 suggest that your code has call Foundation [1]. Frames 1 and 0 are part of the standard exception machinery, indicating that Foundation has thrown a language exception, probably the attempt

Let’s focus this discussion in your other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Let’s focus this discussion in your other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com