Producing .xcarchive for target when building for iOS with CMake - ios

I'm trying to automate iOS building through CMake, up to and including authoring .ipas. I have my provisioning profile and certificates set up, build is successful, but when I execute cmake --build I can't get .xcarchives to generate, and my POST_BUILD command (using xcodebuild) to author the .ipa is dependent on that.
I've tried setting some archive options though CMake (setting cmake_archive_output_directory), but there's a flag or option to set that can produce xcarchives during build, I don't know it. Does anyone have experience with this?

Despite many attempts, a post-build command to xcodebuild archive never worked -- I'm still not sure why, either. What I ended up doing to work around this was have CMake generate a script.
So my create executable custom function does this:
It creates a script file if it doesn't already exist, then for each executable target, appends an xcodebuild command if it's not a duplicate:
xcodebuild -workspace ${pathToTargetWorkspace} -scheme ${targetScheme} -configuration ${config} -archivePath ${pathToGeneratedArchive}.xcarchive archive
Then after building is finished, you just run the script with the aggregation of archive commands and it archives all the targets.

Related

Archive iOS application using caches from DerivedData

I'm using Fastlane for my CI builds on Github Actions.
CI runs Fastlane's build_app function. The build_app internally uses xcodebuild archive to archive the project and then uses xcodebuild -exportArchive to extract IPA.
The problem is xcodebuild archive always ignores caches and builds all the modules from the source (even if DerivedData from previous builds are available). Is there a way to force either fastlane or xcodebuild archive to use caches from DerivedData. Or maybe there is some other way to achieve this.
Thanks

How can I build the Xcode-generated Swift Package Workspace with xcodebuild?

When you open a Package.swift file, Xcode will generate a workspace with the path: .swiftpm/xcode/package.xcworkspace.
I'd like to use xcodebuild to build this but it does not seem to work. The error messages are not helpful, just tells me that clang failed.
The actual command I'm running is:
xcodebuild -workspace .swiftpm/xcode/package.xcworkspace -scheme MyLibrary-Package -sdk iphonesimulator OTHER_SWIFT_FLAGS="-D SWIFT_PACKAGE"
Funny enough, trying to build a scheme that describes an individual target works:
xcodebuild -workspace .swiftpm/xcode/package.xcworkspace -scheme SpecificTarget -sdk iphonesimulator OTHER_SWIFT_FLAGS="-D SWIFT_PACKAGE"
Am I missing some build flags needed to build the combination scheme? Has anyone else struggled with this and have any advice?
Note:
The ultimate goal here is to be able to verify that my Swift Package builds in CI. If there is an easier way to achieve this goal then I'm happy to go another route. (The easier might just be multiple commands to build the individual targets but this is less robust)

xcodebuild produces different archive to Xcode 7.0.1

I am using xcodebuild to generate an archive from a workspace. I use the following command:
xcodebuild -workspace MyProject.xcworkspace -scheme "MyProject"
-destination generic/platform=iOS archive
-archivePath "../PathToArchive/MyProject.xcarchive
(I've spaced it out over multiple lines for readability)
This command generates a MyProject.xcarchive. However it generates a generic "Xcode Archive" rather than an "iOS App Archive." This cannot be submitted to the App Store.
If I archive the exact same workspace and scheme using Xcode.app version 7.0.1 (7A1001) instead of xcodebuild then I get an "iOS App Archive" which can be submitted to the App Store.
Inspecting the contents of these two xcarchives shows the main difference is the bundled Info.plist file. The one generated by Xcode.app contains an additional ApplicationProperties dict with versioning and signing details. The one generated by xcodebuild lacks these details in its Info.plist.
Copying the Xcode.app generated Info.plist into the xcarchive generated by xcodebuild "fixes" the archive, and it can be submitted to the App Store. This is not a solution however, as it means I cannot build on the command line.
Note that doing xcodebuild -version prints:
Xcode 7.0.1
Build version 7A1001
Edit: sometimes xcodebuild appears to generate a correct iOS App Archive instead of a Generic Archive. I'm not exactly sure why this happens. It's not consistent.
Are you using Cocoapods? If so try using the pre release version gem install cocoapods --pre . I had the issue because of a copy pods phase being somewhere it should not have been, please go through https://github.com/CocoaPods/CocoaPods/issues/4021 you should find a solution that fits you.
After a lot of frustration I have discovered the cause of xcodebuild producing incorrect xcarchive packages.
I had to disable the "Parallelize Build" option for the scheme I was building.
After un-ticking this option, the builds take a lot longer, but xcodebuild is consistently producing an "iOS App Archive" rather than a "Generic Archive." With "Parallelize Build" enabled xcodebuild would generate a "Generic Archive" 90% of the time, occasionally generating a correct archive.
Because I wanted my build times within Xcode to remain unaffected, I left the "Parallelize Build" option enabled for my schemes. I duplicated the schemes to be built with xcodebuild and un-ticked the option only for the deployment schemes.

Export .ipa file from Xcode project without ever opening Xcode

We have an API that users can call to create Cordova apps/projects, upload their www directory, and then start compilation and download the executable binary file. This binary file will then go into a private app store.
I'm having trouble with the compile step for iOS. The Cordova build step is no problem, but it doesn't output a binary file, like it does for Android. After reading everything I found on Stackoverflow and elsewhere, the plan was this:
xcodebuild clean -configuration Release -alltargets
xcodebuild -scheme MyApp archive -archivePath build/MyApp
xcodebuild -exportArchive -exportFormat ipa -archivePath "build/MyApp.xcarchive" -exportPath "MyApp.ipa" -exportProvisioningProfile "My Prov Profile"
Given that the signing identity and everything is set up correctly, it almost works. The first command executes fine. The second command just hangs.
However, if I open the project in Xcode, and then execute the commands, it compiles and exports, and I'm left with an .ipa file, which is what I wanted. It seems that Xcode sets up a workspace and some scheme-related things when the project is first opened.
Is there any way I can get xcodebuild (or xcrun, or anything, for that matter) to create this workspace file for me?
Or is there another way to approach this?
Right now, I have a solution where I actually open the Xcode project, wait 15 seconds, and then proceed. But I can think of a thousand ways that will fail at some point, so I would like to change it to something a little more elegant.
I currently have Xcode 6.3 installed, if that is relevant.
Update: Opal's answer below set me on the right path (I think). What I ended up doing, was exporting a shared scheme as per Opal's link, and using that as a template for future apps. The solutions was something like this:
# Copy shared scheme file into directory
mkdir /path/to/project/dir/MyApp.xcodeproj/xcshareddata
mkdir /path/to/project/dir/MyApp.xcodeproj/xcshareddata/xcschemes
cp data/MyScheme.xcscheme /path/to/project/dir/MyApp.xcodeproj/xcshareddata/xcschemes/.
# Use sed to replace app name in scheme file
sed -i '' "s/%app_name%/MyApp/g" MyApp.xcodeproj/xcshareddata/xcschemes/MyScheme.xcscheme
# CD into directory
cd /path/to/project/dir
# Move files from Cordova to our build directory
cp -r CordovaLib/build/* build/.
# Build and export
xcodebuild clean -configuration Release -alltargets
xcodebuild -scheme MyScheme archive -archivePath build/MyApp
xcodebuild -exportArchive -exportFormat ipa -archivePath "build/MyApp.xcarchive" -exportPath "MyApp.ipa" -exportProvisioningProfile "MyProvProfile"
It seems that the application you try to build has no shared schemes. Schemes if not shared, are created when project is loaded to xcode. To create shared schemes see this site.
These are the steps I used to automate ipa generation without opening xcode in my cordova environment. (xcode version: 6.0.1 cordova version: 3.6.0)
Change in cordova/build.xcconfig: CODE_SIGN_IDENTITY=iPhone Distribution (change "Developer" to "Distribution". )
run cordova build ios --device in cordova workspace that generates .app file
Sign using : xcrun -sdk iphoneos PackageApplication -v ${WORKSPACE}/platforms/ios/build/device/${application.name}.app -o ${WORKSPACE}/platforms/ios/build/${application.name}.ipa --embed ${ios.distribution.provisionfile}.mobileprovision --sign ${code.signing.identity}

Xcodebuild is not creating an app

I'm trying to create a simulator app to submit to Facebook for review. I've followed their instructions to the letter, but keep running into problems. I am using CocoaPods and have a workspace instead of a plain old project. Here's the command I'm running:
xcodebuild -arch i386 -sdk iphonesimulator8.1 -workspace [APP].xcworkspace -scheme [APP]
I get a ** BUILD SUCCEEDED ** message, but either one of two things will happen:
No build folder is created, and I can't find where the .App file is.
A .App is created in a build folder, but is 0 bytes in size and crashes when running with ios-sim.
I read that changing the Run scheme to 'Release' might fix it, but that didn't do anything. Any ideas?
So, I had the same problem and solved it by doing the following:
I made my app as release build instead of debug in xcode: Product->Scheme->Edit Scheme and then Build Configuration set to Release.
After doing this I then went back to the command line and added a destination for the build:
xcodebuild -arch i386 -sdk iphonesimulator8.1 -workspace [APP].xcworkspace -scheme [APP] -derivedDataPath /path/to/build
If you are still having problems make sure you clean and build all of your targets (pods included) and try the above steps again.
Hope this works; it did for me.

Resources