Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add custom Info.plist key additions field to iOS and macOS export settings #8848

Closed
lostminds opened this issue Jan 9, 2024 · 0 comments · Fixed by godotengine/godot#87029

Comments

@lostminds
Copy link

Describe the project you are working on

An editor, exporting to multiple formats including an internal file format I want to associate with the editor app.

Describe the problem or limitation you are having in your project

On both iOS and macOS many application meta-properties are controlled by the Info.plist file in the exported application bundle. This is generated by Godot at export based on the export template, and populated by many of the values you can fill in in the export settings.

I've opened a number of related issues previously (like godotengine/godot#74154, #8289, #6360) that I'm happy to see have been implemented improving export for iOS and macOS. But now I find myself once again needing to make some additions to the Info.plist.

However, this time the change is a bit more specific and experimental and I don't think these specific keys will be widely used, so I don't think it warranted to add specific fields for these specific properties. (I'm attempting to add declarations for UTExportedTypeDeclarations and CFBundleDocumentTypes to define file formats that should be associated with the exported app as the owner). But this means I have to export the project unsigned, manually modify the Info.plist and then manually sign, package and notarize the project each time.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

So, what I'm proposing is to instead add a new "Custom Info.plist keys" field in the export options for iOS and macOS, for example at the end of the XCode section. This field would allow advanced users to simply add additional keys content they want to be added at the end of the Info.plist file during the export process, but before the bundle is signed, packaged, notarized etc.

For example you could add something like the document type:

<key>CFBundleDocumentTypes</key>
<array>
	<dict>
		<key>CFBundleTypeExtensions</key>
		<array>
			<string>ext</string>
		</array>
		<key>CFBundleTypeIconFile</key>
		<string>DocIcon.icns</string>
		<key>CFBundleTypeRole</key>
		<string>Editor</string>
		<key>LSHandlerRank</key>
		<string>Owner</string>
		...
	</dict>
</array>

Or something like the iOS device required performance capabilities

This would allow users to make seldom used additions like the cases above without need for additional specific fields in the export settings. And it would also make it much easier to test and fix any future issues like the ones linked in the introduction above related to missing plist keys.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The basic implementation of this would be very simple, just the addition of another field (sorry @bruvzg) in the export settings for iOS and macOS. Possibly with an expanding/scrolling text field in the UI to fit longer additions.
Then when generating the Info.plist during export all it would require to get the basic functionality would be to insert the custom Info.plist additions string at the end before the closing -tags.

If you want to make it more advanced you could do some basic format checking to warn if the addition isn't properly formatted as closed plist content tags (would probably break the exported app). Or, if you want to be really advanced, allow the content of the custom plist content to overwrite and replace existing keys with the same name, letting the user use this custom field to also replace tags Godot and the export template generates. Basically allowing advanced users to replace any key in the entire Info.plist file if they want to using this field.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No, but as described above it can be worked around by adding several complicated manual steps to the export process.

Is there a reason why this should be core and not an add-on in the asset library?

Exporting is a core part of the engine

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants