Thanks for your effort to contribute. Looks like you had (and fixed) the same issue as discussed in #375? As mentioned there, I'm happy to include an option to en/disable the framework setting if convinced that this is useful. You wrote that with this option "integrating another universal framework into the consuming project" is necessary. Can you elaborate? See also @parallaxe's comment.

Either way, I'm not happy with your choice of words here: INCLUDE_IOS_WRAPPERS. The main effect this setting has is the FRAMEWORK TRUE line. So a more suitable name would e.g. BUILD_XCODE_FRAMEWORK or BUILD_APPLE_FRAMEWORK be.

Thanks for the response! I did not see that this issue was already discussed in #375, but this is indeed addressing the same issue.

You wrote that with this option "integrating another universal framework into the consuming project" is necessary. Can you elaborate? See also @parallaxe's comment.

The main pain point for our integration is the necessity to run the build-release.sh script to generate the framework outside of CMake, this adds some extra work for integrating it into our dev and build pipeline which currently calls CMake directly to build the XCode project.

Additionally, since the barcode reader component of our app is written directly in C++ without having platform specific implementations there's no need for us to include the framework as we can consume the ZXing C++ code directly as a pure C++ library and share the same code across all platforms. Even if we were to switch over to using the framework we would not opt to use the Apple specific wrapper code, so this just ends up including unneeded Objective-C code in our project. Where I think the framework has strong value is for integrating into iOS specific implementations given its nice integration with Swift/Objective-C.

Either way, I'm not happy with your choice of words here: INCLUDE_IOS_WRAPPERS. The main effect this setting has is the FRAMEWORK TRUE line. So a more suitable name would e.g. BUILD_XCODE_FRAMEWORK or BUILD_APPLE_FRAMEWORK be.

I'm totally fine with renaming the definition, and those suggestions make sense to me. I would probably go with BUILD_APPLE_FRAMEWORK.

Hey @axxel, just wanted to add my voice on this one. The main issue is that the iOS wrapper introduced language bindings (Swift/Objective-C) for use on iOS, and the changes to the core CMakeLists.txt now require you to build the language bindings in order to build the core code on for any Apple target. This means even if you have no need of the language bindings (Swift/Objective-C), you still have to build them to consume zxing-cpp in a project that builds for Apple platforms. As @Alex-MSFT said, in our case we are using zxing-cpp in platform agnostic code that is pure C++ with no Swift/Objective-C (or Java, or C#, or any other platform specific languages). In this case, there is no reason to build Swift/Objective-C language bindings, as it is just building extra platform specific code that won't be used.

Thanks @Alex-MSFT and @ryantrem for the details but there is one thing I don't understand: I thought the question of whether or not a framework is build is independent of whether or not any ObjectiveC language bindings are build? In that case some other property of those specified in the if (APPLE) block is actually the one that you want to avoid?

@parallaxe: do you have anything to say about the proposed XCODE_ATTRIBUTE_ENABLE_BITCODE "NO" change?

Thanks @Alex-MSFT and @ryantrem for the details but there is one thing I don't understand: I thought the question of whether or not a framework is build is independent of whether or not any ObjectiveC language bindings are build? In that case some other property of those specified in the if (APPLE) block is actually the one that you want to avoid?

For just excluding the iOS wrappers I believe the main part that needs to be omitted is the inclusion of the wrappers module map XCODE_ATTRIBUTE_MODULEMAP_FILE "wrappers/ios/Sources/Wrapper/module.modulemap". Moving the block to just this line does allow the project to build without having to manually generate the framework by running build-release.sh.

I opted to make the flag cover the whole iOS block for a few reasons:

• Building and linking Xcode frameworks works slightly differently in cmake, so giving the option to use a library may make the integration a little bit cleaner and match more closely with other iOS libraries for certain projects.
• We can side step hard coding things like enabling bit code, ARC, and which architectures to include that may differ based on the consuming project.
• Consumers don't need to worry about signing settings for the library, which must be manually set when using a framework.

My personal opinion is that it is best to limit platform specific integration details where possible to keep integrating the project as similar as possible across platforms, and to avoid potential conflicts with platform specific configurations in consuming projects.

Sounds fine for me. Our use case for integrating zxing into iOS-apps obviously does not cover all use-cases of zxing on Apple-platforms, and the reasonings in the discussions make sense.
Regarding enabling / disabling / side stepping bitcode: Since Xcode 14 / iOS 16 (released in September this year), bitcode is deprecated. Previously, it was recommended to build apps and frameworks with bitcode turned on but not enforced.
Thus, I prefer to turn bitcode off per default.

Thanks to everyone for the valuable input on this.