Can child processes inherit Info.plist properties of a parent app (such as LSSupportsGameMode)?

No.

Info.plist properties are set in one of two ways:

• If the code is bundled, there’s an Info.plist file in that bundle.

• For a standalone executable, you can embed an Info.plist in the __TEXT / __info_plist section of the executable.

Unlike entitlements, these properties are not directly tied to the process. Rather, some code in the system has to consult the properties. This is common done from within the process — code in a system framework gets the current processe’s bundle and fetches properties from that — but it can also be done from outside.

Given that design, there’s no inheritance. If you want something to be effective, you have set it on that program’s Info.plist. And that makes the Java thing tricky because you don’t control it’s Info.plist.

Having said that, Java isn’t built in to the system, so you could potentially build your own copy with a custom Info.plist that has these properties set.

However, it’s hard to say whether that’ll actually achieve your final goal because it’s gonna depend on exactly how the relevant frameworks are checking for these properties. And I don’t have enough expertise in this properties to offer an opinion as to whether that’s likely to work or not.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for that info and possible lead!

Hmm, the approach of using our own copy of Java with a custom Info.plist seems to add a significant amount of complication and has several drawbacks for a relatively minor feature so I'm not sure it's actually realistic for our case. But lets say I want to investigate whether that angle works anyway.

One thing I want to clarify is that you differentiated between the location of an Info.plist when the code is bundled versus when it is a standalone executable.

My initial thought is that since a Java installation I have on hand is a bundle that clearly has a Info.plist file in its Contents directory, and the java executable is contained within that bundle, then the "code is bundled" rule should apply. But when I use otool to look at the relevant section of the java executable, I see content as well:

$ otool -P /Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home/bin/java
/Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home/bin/java:
(__TEXT,__info_plist) section
 
... (Info.plist content here, different from the Info.plist in the bundle)

Some clarifying questions I have are:

• Looking at the documentation it doesn't seem to follow the normal convention for a bundle? java is located in Contents/Home/bin/java. Does this matter for which Info.plist is used?
• In the bundle's information at Contents/Info.plist, the CFBundleExecutable listed is not the one I am concerned about (it is not java). Does this affect which Info.plist is relevant?
• In this case where both the bundle has an Info.plist file and an executable somewhere in it also has an __info_plist section, which one is used (or is some combination used)?

The Info.plist file in a bundle applies to the bundle itself. The executable for that bundle is the one at the path Contents/MacOS/NNN [1], where NNN is the value in the CFBundleExecutable property of that Info.plist.

If you position an executable elsewhere in the bundle [2] then either:

• That executable is in its own bundle, and thus that bundle’s Info.plist applies.

• Or not, in which case its __TEXT / __info_plist section applies.

Here’s a control example:

MyApp.app/
  Contents/
    Info.plist          <<< applies to MyApp
    MacOS/
      MyApp
      MyHelperTool      <<< __TEXT / __info_plist section
      MyHelperApp.app/
        Contents/
          Info.plist    <<< applies to MyHelperApp
          MacOS/
            MyHelperApp
          Resources/
            …
    Resources/
      …

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Assuming we’re talking about a Mac app. Mac frameworks and non-Mac apps have a different layout.

[2] Ideally this would be one of the places reserved for executables, as described in a Placing Content in a Bundle, but many cross-platform tools use a non-standard layout.