6

There is no quite a good tutorial for Cmake integration for iOS projects. There are very few found on internet, but lags information. I have a C++ project and I want to cross compile it for my iOS project. I am really not an expert in C++ and Cmake topics. Though, I followed a blog which I was what exactly looking for.

As mentioned in the blog, I used toolchain to execute the Cmake command

mkdir build/ && cd build/ && cmake -G "Xcode" -DCMAKE_TOOLCHAIN_FILE=../ios-cmake/ios.toolchain.cmake ../../xxx-cpp -DPLATFORM=OS64COMBINED

And it generated the .xcodeproj in the build directory.

As instructed, I included the generated Xcode solution to my main iOS project and added the C++ project to "Frameworks, Libraries, and Embedded Content" and "Dependencies". Actually I wanted to build the library for iOS devices, so, as mentioned in the comment in the same blog, "The Xcode project generated from Cmake does not require any signing itself. Instead you include that generated Xcode project in another Xcode project that DOES have signing configured", my iOS project was already code signed. When I tried to build the project, I got build error saying "Signing for "xxx" requires a development team. Select a development team in the Signing & Capabilities editor."

Here are my observations

Build main iOS project for devices: BUILD FAILED

Signing for "xxx" requires a development team. Select a development team in the Signing & Capabilities editor.

Build main iOS project for simulator: BUILD FAILED

clang: error: no such file or directory: '/Users/user/Workspace/Cmake/Cmake Sample/build/lib/{C++ project}/core/Debug-iphonesimulator/libxxx.dylib' Command Ld failed with a nonzero exit code

Build generated Xcode project for devices: BUILD FAILED

Choosing ALL_BUILD target

For .app targets: Bundle identifier is missing. xxx doesn't have a bundle identifier. Add a value for PRODUCT_BUNDLE_IDENTIFIER in the build settings editor.

For .dylib targets: Signing for "xxx" requires a development team. Select a development team in the Signing & Capabilities editor.

Build generated Xcode project for simulator: BUILD SUCCEEDED

Choosing ALL_BUILD target

I have no idea where to find the solution and I have already invested more time in analysing and doing many trial and errors. I really need some advise in cross compiling the Cpp libraries for iOS devices. Thanks in advance!!

Another gentleman is facing a same issue

iOS
  • 3,526
  • 3
  • 37
  • 82
  • Have you checked: https://stackoverflow.com/questions/39524148/xcode-error-code-signing-is-required-for-product-type-application-in-sdk-ios? This seems to be for an older version but should ideally translate well. I've posted the same comment on the other question as well. – Rajat Jain Jul 10 '21 at 05:00
  • How are you adding the `dylib` to your project? And do you need to build the C++ with `cmake`? I have plenty of `C` and `C++` libraries I use, but don't encounter these issues. I'll take a look at one of the projects a bit later today – Mobile Ben Jul 11 '21 at 16:40
  • Please check my answer in https://stackoverflow.com/questions/67581790/sign-ios-dylib-before-building – Teja Jul 12 '21 at 03:39

1 Answers1

0

There are multiple ways to solve this problem.

  1. You sign the library manually everytime after building the library with iOS-cmake using codesign command by providing appropriate signing identity. This involves lot of manual work, so I would prefer you to go with approach
  2. You can automatically sign all the included libraries using run script by adding below command codesign -f -s "$EXPANDED_CODE_SIGN_IDENTITY" "$BUILT_PRODUCTS_DIR/$FRAMEWORKS_FOLDER_PATH/<library_name>"

Here signing identity can be either "$EXPANDED_CODE_SIGN_IDENTITY" or "$CODE_SIGN_IDENTITY", it depends on your workspace structure if you are using cocoapods or not

The idea in the second approach is, xcode (xcodebuild) provides few environment variables while building the project, so we try to leverage the same signing identity which was used for signing the application to sign the library.

Also with respect to the way you are integrating the native library, I personally don't recommend doing that because if you change any setting in the generated xcode project, it would be disappeared if you generate the xcode project again

We have a similar dependency in our project, so we took the route of building the libraries in the command line (you can choose to build it using xcode generator or directly with cmake and make). Then we had to set few settings into our project

  1. Adding the build dependency :- For this we have updated framework search paths build setting which points to the library which was generated before (this you can customize depending on arm64 [devices] or x86_64 [simulator])
  2. Give that build dependency is sorted out, but in-order to have them at run time, we have to include these libraries in frameworks directory of .app folder, so we have added a run script to copy these libraries to frameworks directory. Using something like below

# Retrieve architecture type
ARCHITECTURE=""

if [ $NATIVE_ARCH == "i386" ] || [ $NATIVE_ARCH == "x86_64" ] ; then
    ARCHITECTURE="x86_64"
else
    ARCHITECTURE="arm64"
fi 

# Retrieve build configuration
BUILD_CONFIG=""

if [ $CONFIGURATION == "Debug" ] ; then
    BUILD_CONFIG="Debug"
else
    BUILD_CONFIG="Release"
fi

# Copying library
cp -r <path_to_your_library> "$BUILT_PRODUCTS_DIR/$FRAMEWORKS_FOLDER_PATH/"

Path_to_your_library might vary depending on x86_64, arm64, debug and release builds. The steps 1 and 2 are automatically taken care by xcode if you go with your route but it has lot of caveats, but configuring these settings is a one time activity which is smooth in day-to-day development process

If you maintain proper directory structure you can smoothly add them to the run script something like

  1. Debug/arm64 for debug arm64 variant
  2. Release/arm64 for release arm64 variant
  3. Debug/x86_64 for debug x86_64 variant
  4. Release/x86_64 for release x86_64 variant

Also make sure that you build framework instead of dylib, else Apple will throw warning and reject while uploading to appstore

Teja
  • 109
  • 4
  • 12