Objo macOS builds: all apps share one executable UUID

madru

Hi Garry,

thanks for the watchpoint hint, that explained the loop timings. I've found a separate macOS issue that I believe affects every Objo app that talks to a server on the local network. (We might have to do something slightly differently in Objo, but unfortunately I don't know that yet.)

Symptom

My app connects to a server on the LAN (e.g 192.168.1.16:17178).

Run from Studio: works.
Started from Terminal (running the binary directly): works.
Started by double-click in Finder: fails with "Connection failed: No route to host". The app never shows up in System Settings > Privacy & Security > Local Network, and no permission prompt appears. Setting a custom app name and bundle identifier made no difference.

Cause

it looks like all Objo-built apps appear to share the same main executable UUID (LC_UUID):

$ dwarfdump --uuid jRDCclientTest.app/Contents/MacOS/jRDCclientTest
UUID: 2A39B1A0-F2F9-3BF3-ACAA-4D572C837A11 (arm64)

$ dwarfdump --uuid "Binary Data Download.app/Contents/MacOS/Binary_Data_Download"
UUID: 2A39B1A0-F2F9-3BF3-ACAA-4D572C837A11 (arm64)

(the second one is your "Binary Data Download" example, built unchanged)

macOS Local Network privacy identifies apps by the main executable's UUID. Apple's technote TN3179 "Understanding local network privacy" notes that apps sharing the same main executable UUID confuse the system. The log shows exactly that: the connection is blocked for the UUID, while nehelper reports the app as allowed a few milliseconds later.
(h**ps://developer.apple.com/documentation/Technotes/tn3179-understanding-local-network-privacy?changes=2,2)

log stream --info --predicate 'eventMessage CONTAINS[c] "local network" OR eventMessage CONTAINS[c] "192.168.1.16"'

UserEventAgent: [com.apple.networkextension:] Got local network blocked notification: pid: 50071, uuid: 2A39B1A0-F2F9-3BF3-ACAA-4D572C837A11, bundle_id: (null)
kernel: cfil_inp_log: [50071 jRDCclientTest] TCP out ... faddr ::ffff:192.168.1.16 (port 17178)
nehelper: [com.apple.networkextension:] Local network allowed by preference for jRDCclientTest (com.guido.test)

An earlier run of a different app (jRDCtest1, pid 49279) was blocked with the same UUID, and at that time nehelper reported "allowed by preference for MyApp (com.objo.app.myapp)", i.e. the permission was attributed to another Objo app.

can you please verify?

Workaround for now

Starting the app via a .command file (so it runs as a child of Terminal and inherits Terminal's Local Network permission) works.

Happy to test a fixed build. Thanks!

Best regards,
Guido

Garry

Thanks for the careful investigation. I think this is an Objo bug.

I checked the macOS desktop host in the current build, and its executable has exactly the UUID you reported: 2A39B1A0-F2F9-3BF3-ACAA-4D572C837A11. Studio copies that host into generated apps; changing the app name and bundle identifier does not change the executable UUID.

Apple warns that apps sharing a main executable UUID can confuse Local Network privacy. Terminal and its child processes are automatically allowed local network access, so launching there does not exercise the same permission path as double-clicking in Finder. I have confirmed the UUID collision, though I have not independently reproduced your exact connection failure.

I’ve logged this as bug #1571. The fix will need to give each generated app a distinct executable UUID before signing, then verify the result with Finder-launched network tests. Your offer to test a fixed build would be very helpful. I’ll follow up when one is ready.

madamov

madru Good catch!

Garry

This is now fixed. Studio assigns every generated macOS app its own unique main executable UUID during both Build and Publish:

The UUID is stamped onto the app's own copy of the executable before code signing, so signatures, disk images, and notarisation all cover the personalised binary.
It's derived deterministically from the app's identity and compiled content: two different apps always get different UUIDs, but rebuilding the same app from unchanged sources keeps the same UUID - so an app you've already granted Local Network access doesn't lose that grant on the next rebuild.
The runtime host that Studio itself installs is never modified, and nested libraries keep their original UUIDs.

After the fix, each app gets its own Local Network prompt and its own entry in System Settings → Privacy & Security → Local Network. You can verify it with the same command you used:

xcrun dwarfdump --uuid 'MyApp.app/Contents/MacOS/MyApp'

Two different apps should now report two different UUIDs. Apps built with an older version keep the old shared UUID until you rebuild them with the fixed one.

One caveat from Apple's guidance: Local Network tracking is most reliable for apps signed with an Apple-issued Developer ID certificate. Ad-hoc signed Build output for local testing is tracked less reliably, so for anything you distribute, keep publishing with your Developer ID signing identity as before.

The fix ships in the next release of Objo Studio.