Thank you. here is the bug number FB23472973

[quote='895230022, DTS Engineer, /thread/822025?answerId=895230022#895230022'] Xcode 27 beta has a new Network Topology Observation capability. That authorises your use of the com.apple.developer.networking.topology-observation entitlement [/quote] yay. It worked after adding the capability. thank you very much for closing the loop.

Thanks for the detail i will stick with what it is current and i will have it my roadmap to add a applike wrapper.

You’re hitting the second case, right? Yes sysctl returns zero and the returned needed also zero

I took the help of claude code and come to a conclusion like this Summary: IPv4 ARP cache invisible via PF_ROUTE sysctl on macOS 27 — bundled apps only; cause unknown TL;DR: On macOS 27, querying the IPv4 ARP cache via sysctl(CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO) returns an empty result (needed == 0) inside our built .app bundle, with or without the App Sandbox entitlement. The identical query with AF_INET6 returns real data in the same app. arp -a (system binary) shows IPv4 entries fine. Crucially, the identical sysctl code run as a bare, unbundled swift repro.swift script also returns real IPv4 data — so this is not about code-signing or sandboxing in general, it's specific to being a launched, bundled GUI app. We suspected the Local Network privacy permission next (the app had never appeared in System Settings → Privacy & Security → Local Network), added NSLocalNetworkUsageDescription/NSBonjourServices, forced the permission prompt via an NWBrowser Bonjour browse, and granted it — the sysctl result was unchanged. Local Network permission is ruled out too. The unbundled script also has no Local Network grant, yet works fine, confirming that permission isn't the differentiator either way. The actual cause is still unknown. Worked correctly, unchanged, on macOS 26. Full write-up: macos27_arp_sandbox_bug_report.md. Minimal repro Save as repro.swift and run with swift repro.swift: From Terminal (unbundled script): returns real IPv4 + IPv6 data — bug does not reproduce. Built into the actual .app bundle and run from Finder/LaunchServices: AF_INET returns needed=0; AF_INET6 still works — bug reproduces, with or without the App Sandbox entitlement. import Darwin func probe(_ family: Int32, label: String) { var mib: [Int32] = [CTL_NET, PF_ROUTE, 0, family, NET_RT_FLAGS, Int32(RTF_LLINFO)] var needed = 0 let rc = sysctl(&mib, 6, nil, &needed, nil, 0) print("\(label): rc=\(rc) errno=\(errno) needed=\(needed)") } probe(AF_INET, label: "AF_INET (expect IPv4 ARP entries)") probe(AF_INET6, label: "AF_INET6 (IPv6 neighbor entries)") Run as swift repro.swift from Terminal — bug does NOT reproduce AF_INET (expect IPv4 ARP entries): rc=0 errno=0 needed=7324 AF_INET6 (IPv6 neighbor entries): rc=0 errno=0 needed=15464 Both calls succeed with real, non-empty data — exactly as expected, matching macOS 26 behavior. Same code, built into and run as our app bundle on macOS 27 — bug reproduces AF_INET (expect IPv4 ARP entries): rc=0 errno=2 needed=0 AF_INET6 (IPv6 neighbor entries): rc=0 errno=0 needed=<nonzero> rc == 0 means the call succeeded — it's not an error, just an empty result for AF_INET specifically, and only inside the app bundle. arp -a run at the same time in Terminal also lists IPv4 entries normally. Reproduces with the App Sandbox entitlement present and with it removed — sandboxing is not the differentiator. The differentiator is bundled-app-vs-bare-script.

this is the line failing in macOS 27 var needed = 0 guard sysctl(&mib, 6, nil, &needed, nil, 0) == 0, needed > 0 else { return [:] } since this is failing it does not go to the second sysctl but when i use AF_INET6 it goes to the second sysctl and succeed there also. but with macOS 26 this worked

Thanks for the replay. it explains everything. this is how i solved for the wdiget and mac os app i used gorup.x.y.z and for swift cli and mac os app i used teamid.x.y.z and code signed the swift cli witht the entitlements and it worked for sharing keys in both macOS 26 and macOS 27. since this is ia not a new app i have to stay with team.x.y.z approach which solves my problem. but what is the right thing to do? The way out of this conundrum is to put the command-line tool in an app-like wrapper. Signing a daemon with a restricted entitlement explains this process, albeit in a very different context. I need to do this is it not? If in understnad it correctly.

VurtualProg also support install macOS 27 from ipsw on host Tahoe please check out https://forums.macrumors.com/threads/virtualprog-macos-virtualization-tool.2456173/post-34641389

the fix causes problems with widgets i am using. when i use the teamid.group.com.company.app appgroup in the widget it is not getting values from main mac os app it seems to be that widget needs group.com.company.app appgroup then it works in macOS 27. where as for for swift cli app it needs to teamid.group.com.company.app. but when i try to create the appgroup prefixed with teamid it is not allowed by xcode or identifiers in apple develope site. it is very confusing. what is the appgroup we need to use for sharing between mac os app and swift cli app and widget. the apple documentation says for mac os app use teamid prefix but we cant create appgroup with teamid prefix. could some one from dts support clarify this. Thanks

To answer my question, according to https://developer.apple.com/documentation/Xcode/configuring-app-groups You can also create macOS app groups using the naming convention .. By using this naming scheme, macOS checks that the code signature of processes that try to access the app group container contains the same Developer-Team-ID as app group container ID. so i need to register the group id something like this .group.com.company.app and it worked in macOS 27. apple hase closed the loop of using ios style app group for mac os app that was working with macOS 26

[quote='894588022, DTS Engineer, /thread/822025?answerId=894588022#894588022'] So, just to be clear, if you put this code in a non-sandboxed test app it works just fine on macOS 27 beta? [/quote] it does not work in both mode s(sandboxed and non-sandboxed) in macOS 27 beta whereas in macOS 26 it was working great in both the modes

[quote='894446022, DTS Engineer, /thread/831902?answerId=894446022#894446022'] Make sure to take the sysdiagnose shortly after reproducing the problem, and also add info that: Makes it clear which accessory you tried to capture. Describes the timeline of the failure, that is, roughly when you made this attempt. [/quote] I added a reply to FB witht the details you have asked for. thanks

I tried to debug and found these: for IPv6(AF_INET6) sysctl is returning data in macOS 27 it is not returning any data for AF_INET ie ipv4 in macOS 27 where as with macOS 26 it was returning correct data I have create a bug report for this FB23055965

here is the bug number FB23241619

Any DTS can make it work with macOS 27 or share some info on what´s changed on macOS 27 for sysctl Thanks