Post

Replies

Boosts

Views

Activity

Is it possible to locally test a Network Extension without a paid development account?
I've searched these terms all over the place and have found only a confusing mishmash of things that were probably true years ago but no longer seem to reflect today's reality so I'm posting it here to hopefully add a definitive 2026 answer to these search results for myself and others. The existence of the DNS Proxy Network Extension protocol in 10.15 has given me an idea. I would like to test this idea to see if it is worth developing further or a complete waste of time. This test does not need to run on any device anywhere in the world other than the one in front of me so I would prefer not to spend $100 just to see if I can make a small code fragment do a silly trick. XCode sadly refuses to build my Network Extension target when I only have a "Personal Team" to sign with: Personal development teams, including "XXXX XXXX", do not support the Network Extensions capability. Can this be done or is Apple just 100% pay-to-play nowadays? I have zero problems disabling SIPS or any other consumer grade protections if that will actually achieve my goal but I've read enough comments from people saying it didn't work that I haven't bothered trying. Thanks for reading. OS: 15.7.5 (24G624) XCode Version 26.3 (17C529)
0
0
82
12h
SMAppService Sample Code seems broken
I abandoned Mac development back around 10.4 when I departed Apple and am playing catch-up, trying to figure out how to register a privileged helper tool that can execute commands as root in the new world order. I am developing on 13.1 and since some of these APIs debuted in 13, I'm wondering if that's ultimately the root of my problem. Starting off with the example code provided here: https://developer.apple.com/documentation/servicemanagement/updating-your-app-package-installer-to-use-the-new-service-management-api Following all build/run instructions in the README to the letter, I've not been successful in getting any part of it to work as documented. When I invoke the register command the test app briefly appears in System Settings for me to enable, but once I slide the switch over, it disappears. Subsequent attempts to invoke the register command are met only with the error message: `Unable to register Error Domain=SMAppServiceErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedFailureReason=Operation not permitted} The app does not re-appear in System Settings on these subsequent invocations. When I invoke the status command the result mysteriously equates to SMAppService.Status.notFound. The plist is in the right place with the right name and it is using the BundleProgram key exactly as supplied in the sample code project. The executable is also in the right place at Contents/Resources/SampleLaunchAgent relative to the app root. The error messaging here is extremely disappointing and I'm not seeing any way for me to dig any further without access to the underlying Objective-C (which the Swift header docs reference almost exclusively, making it fairly clear that this was a... Swift... Port... [Pun intended]).
10
0
424
Sep ’25
Is it possible to locally test a Network Extension without a paid development account?
I've searched these terms all over the place and have found only a confusing mishmash of things that were probably true years ago but no longer seem to reflect today's reality so I'm posting it here to hopefully add a definitive 2026 answer to these search results for myself and others. The existence of the DNS Proxy Network Extension protocol in 10.15 has given me an idea. I would like to test this idea to see if it is worth developing further or a complete waste of time. This test does not need to run on any device anywhere in the world other than the one in front of me so I would prefer not to spend $100 just to see if I can make a small code fragment do a silly trick. XCode sadly refuses to build my Network Extension target when I only have a "Personal Team" to sign with: Personal development teams, including "XXXX XXXX", do not support the Network Extensions capability. Can this be done or is Apple just 100% pay-to-play nowadays? I have zero problems disabling SIPS or any other consumer grade protections if that will actually achieve my goal but I've read enough comments from people saying it didn't work that I haven't bothered trying. Thanks for reading. OS: 15.7.5 (24G624) XCode Version 26.3 (17C529)
Replies
0
Boosts
0
Views
82
Activity
12h
SMAppService Sample Code seems broken
I abandoned Mac development back around 10.4 when I departed Apple and am playing catch-up, trying to figure out how to register a privileged helper tool that can execute commands as root in the new world order. I am developing on 13.1 and since some of these APIs debuted in 13, I'm wondering if that's ultimately the root of my problem. Starting off with the example code provided here: https://developer.apple.com/documentation/servicemanagement/updating-your-app-package-installer-to-use-the-new-service-management-api Following all build/run instructions in the README to the letter, I've not been successful in getting any part of it to work as documented. When I invoke the register command the test app briefly appears in System Settings for me to enable, but once I slide the switch over, it disappears. Subsequent attempts to invoke the register command are met only with the error message: `Unable to register Error Domain=SMAppServiceErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedFailureReason=Operation not permitted} The app does not re-appear in System Settings on these subsequent invocations. When I invoke the status command the result mysteriously equates to SMAppService.Status.notFound. The plist is in the right place with the right name and it is using the BundleProgram key exactly as supplied in the sample code project. The executable is also in the right place at Contents/Resources/SampleLaunchAgent relative to the app root. The error messaging here is extremely disappointing and I'm not seeing any way for me to dig any further without access to the underlying Objective-C (which the Swift header docs reference almost exclusively, making it fairly clear that this was a... Swift... Port... [Pun intended]).
Replies
10
Boosts
0
Views
424
Activity
Sep ’25