Pass -no_exported_symbols by default

[keith]

Passing -Wl,-no_exported_symbols has been generally
recommended to reduce app size. Since we have the
exported_symbols_list attribute, if those are never set, we can do
this by default. This does require folks export things that they
actually need.

[karim-alweheshy]

One compatibility concern before making -no_exported_symbols the default: it also removes __mh_execute_header.

I verified this on a reduced ios_application with Xcode 26.5 / ld 1267: nm -gU reports zero defined exports and dyld_info -exports is empty. Firebase Crashlytics' current source explicitly says it needs __mh_execute_header and refuses to initialize when that lookup fails (source, reproduced issue).

Would it make sense to retain only that symbol for app-like executables instead?

-Wl,-exported_symbol,__mh_execute_header

On the same reduced input this changed four exports to one while leaving __TEXT / __text unchanged. Explicit exported_symbols_lists can remain additive for apps that need more symbols, including XCTest bundle-loader hosts.

I put together an opt-in, product-scoped implementation with analysis tests for default-off behavior, opt-out, apps, extensions, additive custom exports, and framework exclusion: main...karim-alweheshy:rules_apple:codex/restrict-application-exports

[keith]

yea i think if we want to move forward with this including that symbol by default would be fine

[karim-alweheshy]

Separately, I prototyped the framework-side counterpart as a reusable apple_exported_symbols_list rule. It takes explicit framework deps and client CcInfo roots (Bazel cannot discover reverse dependencies), derives the client-required exports, keeps non-Swift definitions conservatively by default, and emits an audit report. The conservative policy has an explicit opt-out plus authored runtime roots because it can pull otherwise-unreferenced archive members.

A final Mach-O test covers the unrestricted negative control, the retained client-used Swift API, the removed unused Swift API, and the conservative C runtime root. I kept this independent from the application feature for focused review: main...karim-alweheshy:rules_apple:codex/derive-private-framework-exports

[karim-alweheshy]

@keith I opened #3073 as a small draft companion PR targeting your branch, preserving your existing commits. It keeps __mh_execute_header for executable Mach-Os while retaining your bundle/dylib, bundle-loader, and explicit export-policy behavior. There are no new production build actions.

The runtime regression test fails with the original no-export policy and passes with the fix; all 14 focused tests pass on Bazel 8.0.1 and 9.1.1rc1 with Xcode 26.5. You can merge the companion into this branch or cherry-pick d2aee46. I kept the framework-export work separate. Would you be happy to take this follow-up when refreshing #3024 for review?