eskimo

Thanks for the update. I’m gonna focus on your first set of steps, “Issues with Local Network after reboot”, because that’s the one I really want to nail down. Unfortunately, I fell at the first hurdle )-: To run this test I need a copy of your test app, and the download link you posted above no longer works. Can you post an updated link? Ideally that’d include both a built app that you reproduced the problem with and the project that you used to built the app, but either should be sufficient for me to run your test here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Oh, wow, you’re testing with NameAndPassword. That’s not good. Please open a DTS code-level support request so that I can send you something privately. IMPORTANT In the submission form, where it asks who sent you down this path, reference this forums post. Anyway, coming back to the main issue, your logs make it clear that your mechanism is running in SecurityAgentHelper-arm64 in both cases. That’s what I expected, which leaves me struggling to find a path forward )-: The steps that you described earlier make it clear that you restarted, and that you have FileVault enabled. These are both complexities that I’d like to bypass, at least for the moment. Try this: Boot the machine and log in normally. Install your authorisation plug-in. Attach your smart card and verify that it’s working in general. You can do that from a small test app, or using your mechanism attached to the authenticate rule. Install your authorisation mechanism for system.login.console. Choose Apple menu > Log Out. Log in. Look at your log

[quote='872696022, joel2001k, /thread/812624?answerId=872696022#872696022, /profile/joel2001k'] As reading about Certificate types, I think this certificate is missing: [/quote] No. As I mentioned above, that platform specific distribution certificate type is no longer relevant. It’s been subsumed by Apple Distribution, which works for all platforms. [quote='872712022, joel2001k, /thread/812624?answerId=872712022#872712022, /profile/joel2001k'] What is with these 2 files? [/quote] You’re asking me?!? Seriously though, Apple’s standard processes don’t use openssl. If you go down that path, you won’t find any help from Apple sources. And I think that speaks to the main issue you’re having here: Apple’s code-signing infrastructure relies on digital identities in the keychain. A digital identity is the combination of a certificate and the private key that matches the public key in that certificate. Both of these have to be in the keychain. The openssl sequence you posted above doesn’t add the private key to the k

[quote='872597022, davertay-j, /thread/812770?answerId=872597022#872597022, /profile/davertay-j'] there is mention of the first certificate is the one that matters - why? [/quote] The context here really matters: In a provisioning profile, the certificates act as an allowlist. So the profile holds a list of leaf certificates that it authorises. In a code signature, the certificates act as a chain of trust [1]. The first certificate is the leaf, the next is the one that issued the leaf, and so on until you get to a root. So when the trusted execution system evaluates code for execution, it checks whether the first certificate in the code signature is in the list of certificates in the profile. Regarding your original issue, when you check certificates it’s critical that you look at the serial number. That’s what matters when it comes to matching. If you double check that and the certificate that signed the code is in the profile then the next thing to check is whether this is the right type of profile. The eas

Well, that’s… I’d say unexpected, but I was starting to think that might be the case given the results of our previous diagnostic tests |-: Try this: On the Developer website, navigate to the TEAM_ID.com.ORGANIZATION.APP App ID. Remove the Cloud capability and save that change. Create a new test provisioning profile for that App ID and download that. Go back to the App ID, re-enable the Cloud capability, and save that change. Create another new test provisioning profile and download that. Dump the entitlement allowlist in both profiles. The profile from step 3 should have no com.apple.developer.ubiquity-kvstore-identifier entry, and I’m curious what you see in the profile from step 5. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Before we get too far down the screen time rabbit hole, I wanted to ask you whether you’ve read this titbit from the Developer > Swift Student Challenge > Eligibility and requirements page: Create an interactive scene in an app playground that can be experienced within three minutes. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You post is quite hard to read. I recommend that you review the advice in Quinn’s Top Ten DevForums Tips, and specifically the stuff about code blocks in tip 5. [quote='812857021, Leo_Nagano, /thread/812857, /profile/Leo_Nagano'] What are the likely reasons for … extension category returned error [/quote] I discuss the concept of the extension category in this post. The rest of that thread should have some useful hints and tips. Taking a step back, you’re clearly testing the direct distribution case here, that is, where the sysex uses Developer ID signing. I’d like to clarify the context for that: Do you already have this working with Apple Development signing? That is, this code is working at your desk but fails when you deploy it using Developer ID signing? Or is this the first time you’ve tested your code? If it’s the latter, I recommend that you stop using Developer ID and instead switch to Apple Development. That’s a good idea in general — see The Care and Feeding of Developer ID for more on that — but i

In the Filtering Network Traffic, the content filter is a system extension. This is roughly equivalent to a launchd daemon, so you manage your XPC connection in the same way you would for a launchd daemon. That is: When setting up the connection, install both invalidation and interruption handlers. If the invalidation handler is called, the named XPC endpoint has gone away completely, and so attempting to reconnect won’t help. If the interruption handler is called, this specific XPC connection is toast but the named XPC endpoint is still around and so you should attempt to re-establish that connection. The sample doesn’t do this, but such is the nature of sample code — it tends to cut corners so that it can focus on what’s critical. In this case, this is an NE content filter sample, not an XPC sample, and thus its XPC code is simpler than you’d need in a real product. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

If you’re just starting out I recommend that you allow Xcode’s automatic code signing to take care of your provisioning needs. That is: Launch Xcode. In Xcode > Settings > Apple Accounts, sign in with your developer Apple Account. Create a new project from the iOS > App template. In Signing & Capabilities, check “Automatically manage signing” and select your team in the Team popup. Attach your test device to your Mac via a USB cable. Build and run the test app on your device. Can you get that to work? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I have two options that you should at least look at: If your goal is to run non-UI Swift code on Android then Swift’s Android Workgroup is making great strides on that front. If you want to extend that to SwiftUI code, there’s a third-party vendor who’s tackling that directly [1]. And to be clear, I’m not actually recommending either of these, because I’ll only recommend stuff that I’ve actually used. But you should at least factor them into your decision making. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] https://skip.tools

[quote='872639022, David_Akh, /thread/812774?answerId=872639022#872639022, /profile/David_Akh'] I've submitted a suggestion via Feedback Assist. [/quote] Thanks! What was the bug number? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This is fantastic help, many thanks Mr Eskimo. We actually met once long long ago, your wisdom is much appreciated. Now having done all of that this is what I found: the original profile has 2 certs, and the emitted binary has been signed with the second one of those. In that other thread under Check the Signing Certificate there is mention of the first certificate is the one that matters - why? Going back to the original error, it says that the profile included in the bundle is missing the code-signing certificate. Extracting and dumping the signature and dates of all 19 of those shows that the certifcate used for signing is in there, and is not expired. Seems to me the error is kind of misleading and something else must be amiss, any ideas?

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 I have to convert the Expectation initializers with #expect calls, right. Honestly, I’m not sure what you’re actually trying to do here. In general: If you want to test synchronous and asynchronous Swift routines, use the #expect macro. For example: @Test func example() async throws { #expect(calculateAnswer() == 42) #expect(await calculateAnswerAsync() == 42) } See Expectations and confirmations for more on that. If you want to test asynchronous stuff that’s not a simple async routine, use a confirmation. See Testing asynchronous code. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='872492022, lilan, /thread/773414?answerId=872492022#872492022, /profile/lilan'] I checked this sample but the build failed [/quote] Indeed. Sorry about that. There are expected and unexpected steps here. On the expected front, to build the sample you must select your team in the Team popup in the Signing & Capabilities editor. Do this for both the app and the appex target. The unexpected problems are caused by API tweaks during the iOS 26 beta cycle. To fix those: In URLFilterControlProvider.swift, replace this: func fetchPrefilter() async throws -> NEURLFilterPrefilter? { with this: func fetchPrefilter(existingPrefilterTag: String?) async throws -> NEURLFilterPrefilter? { Later on in the same file, change these lines: data: prefilterData, bitCount: numberOfBits, to this: data: prefilterData, tag: currentPrefilterTag, bitCount: numberOfBits, You’ll need to come up with the currentPrefilterTag value yourself. See the doc comments for the fetchPrefilter(existingPrefilterTag:) method for more b

I … uploaded a Certificate Signing Request using web form. Did you create a new CSR? Or re-submit an existing one? What about the provisioning profile? Provisioning profiles authorise, amongst other things, specific code-signing certificates. If you create a new certificate, you need to regenerate your profile. If you’re curious how this actually works, see: TN3125 Inside Code Signing: Provisioning Profiles TN3161 Inside Code Signing: Certificates [quote='872512022, joel2001k, /thread/812624?answerId=872512022#872512022, /profile/joel2001k'] I would expect to be able to add Mac Application Distribution in Xcode Manage Certificates, but it is missing. [/quote] Indeed. And you should choose Apple Distribution. Historically we used to issue separate iOS and macOS code-signing certificates. There are still bits of that past world lurking in various subsystems, but in most cases these days you want to use the generic stuff, meaning Apple Development and Apple Distribution. [quote='872512022, joel2001k, /thread/812