Cannot Update AUv3 Bundle Identifier with CMake

1

Hi JUCE Community,

I’ve come across an interesting challenge while updating some iOS AUv3 plugins to use CMake as the underlying build configuration system.

It appears that updates to the XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER variable have no impact on the generated CFBundleIdentifier field within the AUv3 Info.plist file. My project has a bundle suffix that differs from the specified BUNDLE_ID, however, I cannot seem to make updates to this field.

For example, if BUNDLE_ID is com.yourcompany.foo, my AUv3 bundle ID becomes com.yourcompany.foo.fooAUv3 by default. If I update the XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER cmake variable to be com.yourcompany.bar.barAUv3 for my AUv3 target, the field will update within my Xcode project, but it’s never applied to the generated Info.plist file.

When I generate my AUv3 target and examine the info.plist file, the CFBundleIdentifier field is still com.yourcompany.foo.fooAUv3. Why’s this?

Has anybody encountered this, and found solutions to rememdy this issue? Any assistance would be wonderful. Surely I shouldn’t need to run plutil as a post-build step to fix this…

Thanks,
Bruce

1 Like
2

Bump. Looking for some solutions or insights here.

One would think that setting XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER at the CMake level would translate to an updated CFBundleIdentifier Info.plist field per target, but it doesn’t. Why is this?

3

We’re using something like this:

    set(customPlist
            "<plist><dict>
            <key>CFBundleIdentifier</key>
            <string>com.my.custom.bundle</string>
            </dict></plist>")

    juce_add_plugin(MyPlugin
            # ...
            PLIST_TO_MERGE ${customPlist})

In addition to XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER

4

Thanks so much for the contribution @eyalamir, I’ve found the PLIST_TO_MERGE attribute useful for merging plist information, but unfortunately the flag merges plist info for all formats, whereas only my AUv3 target needs an updated bundle suffix, which I cannot seem to provide without overriding the plist entry for all formats.

CMake/JUCE seems to infer the bundle suffix from the BUNDLE_ID identifier. For example, AUv3 bundle ID of the example above would result in com.yourcompany.foo.fooAUv3 by default, and there appears to be no way to update the bundle suffix explicitly.

What JUCE provides: com.yourcompany.foo.fooAUv3
What I’m looking to accomplish: com.yourcompany.foo.barAUv3

5

My solution for that is to create a separate target completely for the AUv3, and pass all the shared settings via variables/functions.

AUv3, at least for us, is a separate deployment process anyway.

6

Thanks again Eyal, I have considered this approach as one of my last resort options, but I’d really like to avoid compiling two identical static libraries for my projects (one that AUv3 links against, and then the a library for the other plugin formats). I haven’t tried this path yet, but I assume that’s likely what would happen which I’d like to avoid if possible…

7

Yes, that’s the downside. I’m not sure if there are other solutions, but maybe @reuk can help?

1 Like
8

Interesting thread … imho, creating a separate target path for AUV3 is beneficial anyway, because at some point you’re (possibly?) going to want to bundle the plugin in a container “delivery” app anyway, no?

2 Likes
9

Yes.
For us, the AUv3 and the standalone that surrounds it are also (slightly) different than the regular plugin anyway, due to sandboxing.
So there are a couple of compile time checks where the code behaves differently - for example Apple don’t allow copy protection testing on the App Store and instead they want you to use the App Store mechanism to validate receipts.

So at least for us, it’s mandatory to have a separate target for both to configure the differences in build settings and in the actual code (The UI might also show different activation options, etc).

1 Like
10

Thanks so much for the input @austrianaudioJV. I agree with the approach you guys have been discussing and If I were starting a “fresh,” project I’d be open to this path. The challenge I’m facing is converting existing iOS plugins from being .jucer based to being built using CMake while maintaining 100% parity with existing functionality and session compatibility.

The build system I’m working with would do some weird things to the iOS xcodeproj file to update the iOS AUv3 bundle suffix using python. I’d love to avoid also doing weird things with python myself when we have something as amazing as CMake. There must be a way…

11

Here’s an example of the folder structure for the project I’m working with. In this project, the standalone application and the AUv3 extensions operate identically aside from a a few JUCE-specific settings and as a result they have different bundle identifiers

myiOSApplication/
├─ _CodeSignature/
├─ PlugIns/
│  ├─ myiOSApplication.appex (com.yourcompany.bar.barAUv3)
│  ├─ myiOSApplicationV2.appex (com.yourcompany.bar.fooAUv3)
12

I think your requirement makes sense but I have no idea how to do it currently other than creating another CMake target for the iOS standalone/AUv3 that’s different from the target of the other format. Usually the iOS/Mac App Store builds is a separate build project anyway that has no dependency on the other plugin formats, so it’s not like you would save some build time by having the two targets, it would only look a little different in the IDE.

Perhaps someone from the JUCE team could suggest a better idea.

3 Likes
13

It certainly seems like a bug that setting XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER has no effect on the CFBundleIdentifier in the plist file. Can the JUCE team chime in on this?

1 Like
14

Here’s what I found:

  1. juceaid project needed to have logic updated in Main.cpp related to writing the AUv3 info.plist file, specifically these lines

  2. Also at the CMakeLists.txt level set the XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER variable to the bundle identifier that is needed, such that it matches changes made to the juceaid logic.

if( IOS )
  set_target_properties(
    "${PROJECT_NAME}_AUv3" 
    PROPERTIES 
    XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER 
    "com.yourcompany.bar.fooAUv3"
  )
endif()