[0x0]

Then you could probably replace a dylib inside one app, with a dylib from another. If Apple codesigns all dylibs in apps, you could just submit a silly little app with a malicious dylib, grab the signed dylib from the appstore later and play games with third party apps.

[mikeash]

The code signature for an app extends to the frameworks it contains. You can't just replace them and still have a valid signature.

[quesera]

The code signature is on the multiple architecture binary, thereby including any statically linked object files, right?

If Apple were to add dynamic libs, they would presumably be separate binary files, with their own signatures. This could raise the concern noted by 0x0.

[teacup50]

> If Apple were to add dynamic libs, they would presumably be separate binary files, with their own signatures.

No. That's not how it works on Mac OS X today, where bundled shared libraries are supported.

[quesera]

That's right, thanks.

Separate binary files have individual hashes, which are included in the package manifest file. The manifest is then signed, so a single signature covers all hashed files in the manifest.

Curiously though, in all of the MAS apps I've checked, bundled dylibs are explicitly not hashed in the manifest. This is the developers choice, but perhaps a default?