Chrome reported w/o AppKit, even though it's being used

[avidrissman]

What seems to break in this case is that 5 GUIs tries and fails to detect AppKit (“No 👨🏽‍🦳 AppKit usage to be found? 🤔”). That’s probably because of the structure of Chromium. In order to update cleanly, Chromium (and Google Chrome) is separated into an outer bundle and an inner framework, and the only job of the outer bundle is to call into the inner framework. If all that is being analyzed is the outermost binary, you’re not going to find usage of any system framework. All of Chromium’s AppKit usage (it’s an old-school ~2008 AppKit app) is through the inner framework that isn’t ever explicitly linked to any of the .apps.

I’m not sure of an easy, not special-cased way to detect this. The main function uses dlopen to open a hard-coded path to the inner framework, so there are no obvious traces in metadata.

[helje5]

5 GUIs 1.0 does traverse dependencies and doesn't just look at the top-level (3 levels deep).
Starting in 1.0.1 it will also traverse embedded apps (as per Issue #1)

Do you happen to be on macOS BS? That has issue #2 .

[helje5]

Ah, direct dlopen, I see. Well, we should also scan all embedded frameworks, similar to how we scan apps now.

[avidrissman]

In the general case, we might want to be smart in terms of embedded frameworks. Many embedded frameworks are auxiliary to the function of the app (metrics, crash reporting, updating) and therefore shouldn’t override the classification of the main binary. OTOH, for something like Chrome, where the main binary gives no clues, and there’s only one embedded framework, then definitely it should be classified as being the main app.

[helje5]

I disagree on that, if the app embeds the tech whatever, it embeds the tech.

[sarnau]

Thats a tricky one: there are apps, which are AppKit native with all the UI stuff, but they have e.g. a Python interpreter embedded. Reporting that as a Python app is wrong. The reverse is true as well: only because an App links against AppKit doesn't make it an AppKit native app.

[helje5]

I do agree with that. Ideally we'd have something like the GitHub language detector (25% Swift, 49% JavaScript, etc). But they have your full source, it's a little hard to quantify just based on the binary, but actually not impossible :-)

Though in practice, if someone links Python, it is going to use Python. Same for Electron. I do believe that embedding such as a 3rd party module should affect the primary outcome, even if used sparingly.

[helje5]

OK, I think to deal with it we should scan all embedded frameworks (Frameworks/*.framework).

otool -L Frameworks/Google\ Chrome\ Framework.framework/Google\ Chrome\ Framework
has all the stuff we want to know.

The main binary just links System/CF:
/usr/lib/libSystem.B.dylib
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation