Skip to content

Ability to merge ExportOptions.plist from App_Resources and from plugins #4528

New issue

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

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

Already on GitHub? # to your account

Open
Fatme opened this issue Apr 11, 2019 · 2 comments
Open

Comments

@Fatme
Copy link
Contributor

Fatme commented Apr 11, 2019

It’ll be great to support merging of ExportOptions.plist file from App_Resources and from plugins. This way every user will be able to add custom options to this file and NativeScript CLI will merge them with the default options. Also, every plugin author will be able to add such custom options in platforms/ios folder of the plugin in case when it is required.

Currently NativeScript CLI supports merging of Info.plist files from plugins and from App_Resources. As the format of ExportOptions.plist and Info.plist is the same (the both files are .plist format), it seems the merging of ExportOptions.plist should be very similar to the merging of Info.plist files. Here is the code that merges Info.plist files. The mergeInfoPlists function has hardcoded path to the Info.plist file. It seems the common logic of this function can be extracted to a separate function, for example mergePlistFile. After that we can call this function for Info.plist and ExportOptions.plist:

mergePlistFile(<path to Info.plist>);
mergePlistFile(<path to ExportOptions.plist>);
@jzgoda
Copy link
Contributor

jzgoda commented Oct 2, 2019

@Fatme, I was looking into implementing this feature, but I'm a bit concerned about merging export options from plugin authors. The values in these options are closely tied to the distribution method, which plugin authors have no way of knowing. Personally, I would want full control over this file, which is why merging from App_Resources/ExportOptions.plist is a fantastic idea.

Here are the current available options:

Available keys for -exportOptionsPlist:

	compileBitcode : Bool

		For non-App Store exports, should Xcode re-compile the app from bitcode? Defaults to YES.

	destination : String

		Determines whether the app is exported locally or uploaded to Apple. Options are export or upload. The available options vary based on the selected distribution method. Defaults to export.

	embedOnDemandResourcesAssetPacksInBundle : Bool

		For non-App Store exports, if the app uses On Demand Resources and this is YES, asset packs are embedded in the app bundle so that the app can be tested without a server to host asset packs. Defaults to YES unless onDemandResourcesAssetPacksBaseURL is specified.

	generateAppStoreInformation : Bool

		For App Store exports, should Xcode generate App Store Information for uploading with iTMSTransporter? Defaults to NO.

	iCloudContainerEnvironment : String

		If the app is using CloudKit, this configures the "com.apple.developer.icloud-container-environment" entitlement. Available options vary depending on the type of provisioning profile used, but may include: Development and Production.

	installerSigningCertificate : String

		For manual signing only. Provide a certificate name, SHA-1 hash, or automatic selector to use for signing. Automatic selectors allow Xcode to pick the newest installed certificate of a particular type. The available automatic selectors are "Mac Installer Distribution" and "Developer ID Installer". Defaults to an automatic certificate selector matching the current distribution method.

	manifest : Dictionary

		For non-App Store exports, users can download your app over the web by opening your distribution manifest file in a web browser. To generate a distribution manifest, the value of this key should be a dictionary with three sub-keys: appURL, displayImageURL, fullSizeImageURL. The additional sub-key assetPackManifestURL is required when using on-demand resources.

	method : String

		Describes how Xcode should export the archive. Available options: app-store, validation, ad-hoc, package, enterprise, development, developer-id, and mac-application. The list of options varies based on the type of archive. Defaults to development.

	onDemandResourcesAssetPacksBaseURL : String

		For non-App Store exports, if the app uses On Demand Resources and embedOnDemandResourcesAssetPacksInBundle isn't YES, this should be a base URL specifying where asset packs are going to be hosted. This configures the app to download asset packs from the specified URL.

	provisioningProfiles : Dictionary

		For manual signing only. Specify the provisioning profile to use for each executable in your app. Keys in this dictionary are the bundle identifiers of executables; values are the provisioning profile name or UUID to use.

	signingCertificate : String

		For manual signing only. Provide a certificate name, SHA-1 hash, or automatic selector to use for signing. Automatic selectors allow Xcode to pick the newest installed certificate of a particular type. The available automatic selectors are "Mac App Distribution", "iOS Developer", "iOS Distribution", "Developer ID Application", "Apple Distribution", "Mac Developer", and "Apple Development". Defaults to an automatic certificate selector matching the current distribution method.

	signingStyle : String

		The signing style to use when re-signing the app for distribution. Options are manual or automatic. Apps that were automatically signed when archived can be signed manually or automatically during distribution, and default to automatic. Apps that were manually signed when archived must be manually signed during distribtion, so the value of signingStyle is ignored.

	stripSwiftSymbols : Bool

		Should symbols be stripped from Swift libraries in your IPA? Defaults to YES.

	teamID : String

		The Developer Portal team to use for this export. Defaults to the team used to build the archive.

	thinning : String

		For non-App Store exports, should Xcode thin the package for one or more device variants? Available options: <none> (Xcode produces a non-thinned universal app), <thin-for-all-variants> (Xcode produces a universal app and all available thinned variants), or a model identifier for a specific device (e.g. "iPhone7,1"). Defaults to <none>.

	uploadBitcode : Bool

		For App Store exports, should the package include bitcode? Defaults to YES.

	uploadSymbols : Bool

		For App Store exports, should the package include symbols? Defaults to YES.

Did you have a particular use case in mind where it would make sense to merge from plugin authors?

@Fatme
Copy link
Contributor Author

Fatme commented Oct 2, 2019

@jzgoda,

Did you have a particular use case in mind where it would make sense to merge from plugin authors?

No. Currently we support configuration files like Podfile, Info.plist from both App_Resources and plugins. We wanted to apply the same behavior for ExportOptions.plist as well - just for consistency reasons.

The values in these options are closely tied to the distribution method, which plugin authors have no way of knowing.

That's true. It seems to make sense to support these options only from App_Resources.

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

No branches or pull requests

2 participants