Bundle identifier for debug builds

Is there any way to achieve something akin to the android gradle plugin’s buildTypes applicationIdSuffix when building for different build types? The purpose of it being to get a different bundle identifier for running debug/beta builds alongside release builds.

We currently don’t have a standard way to do that.

It should be possible to create a custom Gradle task in your project, that rewrites the configuration temporarily, but we haven’t tried this ourselves.

Another option is to configure the project for development by default, and use Jenkins (or other CI server) to create distribution builds. In this case you can customize the build settings in your Jenkins pipeline configuration (e.g. customize the signing configuration).

We usually use xcodebuild archive to create the final distribution IPA, where we can specify the Xcode scheme we want for distribution and other build options on the command line / using environment variables. E.g. to change the bundle id, you could pass PRODUCT_BUNDLE_IDENTIFIER=new-bundle-id to xcodebuild.

We have a feature request to provide out of the box support for this use case, but it was not scheduled yet for a release.

Best Regards,

Thanks for the info and prompt reply.

Using that info, I set moeMainReleaseIphoneosXcodeBuild.additionalParameters accordingly, since moeIpaBuild depends on that, which does what I need.

Would you be able to elaborate on how you use xcodebuild directly to build the project? If I try and invoke xcodebuild in the xcode/ project directory, it gets to Looking for gradlew in ... and never does anything else afterwards (there is a gradlew in the folder it’s looking in).

Hi Kevin,

yes, this is unfortunately a new bug discovered in MOE 1.2: https://github.com/multi-os-engine/multi-os-engine/issues/68

Here are more infos about it in another topic: Exporting a distribution IPA with XCode 8

A workaround should be to add --no-daemon to gradle invocation in the custom build phase script in the Xcode project.

Please make sure that all previously started Gradle daemons are stopped / killed prior to trying the --no-daemon option.

The issue was not triggered for us previously, because we are using a 2 step build, like described by Paul in the other topic: we first build with gradlew moeIpaBuild, then xcodebuild archive is used with MOE_GRADLE_EXTERNAL_BUILD set.

Best Regards,

Good to know it wasn’t just me then. Thanks for the followup.