Unable to disable SIP on macOS 27 Beta 1

Our local developer workflow for testing and validating changes is to build locally with Developer certificates (not a legitimate/production Developer ID certificate) and deploy local builds into a VM. Where to get the System Extension to load and be accepted, we need to disable SIP & AMFI.

If you've been granted the entitlement, why aren't you just signing for development with the entitlement?

Development builds ONLY run on machines that were attached to the account at the time the profile was generated (which is fine, as I believe you should be able to register VMs), so the pool of machines is so limited that you don't really need to worry/care about builds running in the wrong place.

Also, as a side note, I'd appreciate you filing a bug asking us to introduce a "Development Only" entitlement variant for Endpoint Security, then posting the bug number back here. That way any team (not just teams that have been approved for the entitlement) can use the entitlement in development builds. That's the same approach DriverKit uses and it's completely eliminated the whole SIP/AMFI issue you're dealing with.

Is there an alternate approach we can use for this workflow to allow macOS VMs to accept our software when signing with a (same teamID, but different certificate to the provisioning profile) developer certificate for local validation?

I specifically said "development" above, but you could also sign for ad hoc or TestFlight distribution. Basically, if your team has been granted the entitlement, I don't see any reason you HAVE to disable SIP.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

What Kevin said plus…

If you’re testing in a VM, you need to be careful about how you create your VM and how you manage your provisioning UDIDs. There’s a long backstory to this. Building macOS apps with Xcode 26 on macOS 26 VM has all the details. However, the basic idea would be something like:

1. Have each of your engineers create their own VM for testing.
2. Boot that VM.
3. And note down the UDID.
4. Then shut it down.
5. Add that UDID to your account.
6. And make sure it gets embedded in your development profile.
7. To run a test, make a copy of the VM and start it on the same Mac on which it was created. It should have the some UDID as you saw in step 3.

Alternatively, you can achieve a similar goal using a VM app that supports snapshots.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Apologies for the delay responding, thanks both for the replies they've helped me fill in the missing gaps in what I'd already tried and got a solution now!

Hi guys @DTS Engineer @DTS Engineer ,

Thanks for the help so far. I've got this working now thanks to your prior help, I can now successfully do this for Endpoint Security System Extension, but I've hit another snag.

We have another component we're developing in to our product suite, that being a network filter system extension implementing NETransparentProxyProvider.

The extension for production (Developer ID Application signed + notarized) builds with: com.apple.developer.networking.networkextension = [ app-proxy-provider-systemextension ]

But I can't get a macOS App Development profile that includes the entitlements required, for either of the App IDs involved (system extension itself, eg com.example.filter-app.network-extension, or the app which sysext is bundled in ie com.example.filter-app)

Development profiles generated via the web interface at developer.apple.com/account for both App IDs carry only the app-extension flavours of the NE providers, so the -systemextension values our binaries are signed with aren't in the profiles' allowlists, signature validation fails, and the extension won't activate on a SIP-enabled but correctly registered Mac.

I've inspected both profile types side by side (security cms -D -i app-dev.provisionprofile). The Development profile contains:

app-proxy-provider content-filter-provider packet-tunnel-provider dns-proxy dns-settings relay url-filter-provider hotspot-provider

The Developer ID Application profile for the same App ID contains:

packet-tunnel-provider-systemextension app-proxy-provider-systemextension content-filter-provider-systemextension dns-proxy-systemextension dns-settings relay url-filter-provider hotspot-provider

So the four providers that have a system-extension form show up in app-extension form in the Development profile and in -systemextension form in the Developer ID one. The other four values are identical in both.

To rule out a "it happens when you use the web" scenario, I tried using fastlane sigh (--development), which as far as I understand it, drives the App Store Connect API, to see if generating the development profiles via that method gives different results but I got a profile back with the exact same issue.

Right now I'm not sure how I can build a system extension NETransparentProxyProvider and sign it with my Apple Developer certificate for testing on a registered Mac/VM.

Am I doing something wrong?

Happy to send over the raw profiles etc in a DTS ticket if you feel that's the better route?

Thanks,

I’m gonna provide a couple of quick hints and then recommend that you start a new thread if you need more help. Having multiple topics in the same thread is less than ideal.

I explain the -systemextension suffix in Exporting a Developer ID Network Extension forums. That explanation is mainly focused on the reverse problem — folks who have things working in development but then encounter problems when directly distributing their product using Developer ID signing — but I suspect it’ll be enough for you to puzzle this out.

for testing on a registered Mac/VM.

A development profile must list the machine’s provisioning UDID in its ProvisionedDevices property. See TN3125 Inside Code Signing: Provisioning Profiles for more about that.

For real hardware this is trivial. For VMs things get trickier. See the explanation in this post.

If you continue to have problems, start a new thread with the details. Put it in App & System Services > Networking and tag it with, at a minimum, Network Extension. That way I’ll be sure to see it go by.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks Quinn. I do have Developer ID Application distribution signing of this working already, it's the Apple Development certificate + registered test device bit I'm struggling with.

I'll read through the post linked and see if it helps, and if not I'll create a new thread as requested