Building iOS Applications Using Xcodebuild Without Codesign

Building iOS applications using xcodebuild without codesign

In order to skip the code signing you can perform a manual build from the console like this:

xcodebuild clean build CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO

Additionally, use the -configuration, -target and -sdk parameters in order to define your build settings.

Refer to this Stack Overflow answer in order to get a detailed description on how to disable code-signing inside Xcode.

How can I skip code signing for development builds in Xcode?

To turn the code signing off, go to your project and target "Build Settings", search for "Code Signing Identity" change its value to "Don't Code Sign" in both of them.

To make this effective you need to change this value in the Project and all of the Targets separately.

How to build and sign an iOS app on separate machines?

We worked on this for several weeks along with other teams in the company. All of us came to the same conclusion, there is no better option than signing with a dev cert and then re-signing each and every binary with the prod cert afterwards. It's not a straight forward process, but that's what we have been left with.

Create iOS App without code sign , stuck installing app

Code signing your app assures users that it is from a known source and the app hasn’t been modified since it was last signed. Before your app can integrate app services, be installed on a device, or be submitted to the App Store, it must be signed with a certificate issued by Apple.

Without code signing the device will not allow the app to install.

If your device is jailbroken then follow the below link for self signing certificate.

https://www.reddit.com/r/jailbreak/comments/9r8j2n/question_installing_apps_to_a_jailbroken_iphone/

How to build an IPA without signing in Xcode 8

I ended up finding a working solution for xcode 8. Here is the step by step

  1. (Optional) Change build location

Xcode>preferences>locations>derived data>custom>your desktop


  1. Open Terminal and navigate to the project's folder
  2. Run manual build: xcodebuild -workspace (or -project) [workspacename.xcworkspace] -scheme [Schemename] -sdk iphoneos -configuration Release CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO
  3. Open the location from Step 1 (derived data) and navigate to >your app>build>products>Release-iphoneOS
  4. Copy the .app file into a new subfolder named Payload (this folder name is case sensitive and much match verbatim)
  5. Compress Payload folder and rename it to app_name-version_number.ipa

Boom. Done.

Is it possible to generate unsigned iPA using Xcode 10.2.1

Step 1:

Set ‘Code Signing Identity’ = ‘Don’t Code Sign’
· Select Targets (‘’) -> Build Settings and find the ‘Signing’ section.
· Set ‘Code Signing Identity’ = ‘Don’t Code Sign’

Setp 2:

Set Bundle Identifier = ‘com.testCompany.prjectname’
Set Version = 1.0
Set Build = 5
Remove ‘Automatically manage singing’ flag.

Step 3:

Open terminal and go to the project root folder. Then run the following command.

xcodebuild -workspace <projectName>.xcworkspace -scheme <projectName> -configuration Release clean archive -archivePath buildArchive/<projectName>.xcarchive CODE_SIGN_IDENTITY=”” CODE_SIGNING_REQUIRED=NO

Step 4:

After successfully completing above command, it will create a new ‘.xcarchive’ file inside ‘buildArchive’ folder ( the ‘buildArchive’ folder create inside your project folder)
Zip that ‘.xcarchive’ file and send it to your team agent.

Building project using Xcodebuild succeeds but no XArchive file output

Just try by giving the archive file name.

xcodebuild -project myproject.xcodeproj -scheme scheme -configuration debug clean archive -archivePath /Users/username/Desktop/myproject.xcarchive DEVELOPMENT_TEAM=Dev_Team_Id

Creating iOS/OSX Frameworks: is it necessary to codesign them before distributing to other developers?

I opened the bounty: "Looking for an answer drawing from credible and/or official sources." but haven't receive such since then.

While answer provided by @jackslash is correct, it tells only a part of story so I want to write my own in a way I would like to have seen it at the moment I was asking this question.

The actuality of this answer is: July 2015. It is most likely that things will change.

First of all let's assert that actions needed for correct code signing of framework should be divided into steps that framework's Developer has to take and steps that framework's Consumer has to take.

TLDR;

For OSX framework: Developer is free to distribute OSX framework without codesigning it as Consumer will re-codesign it anyway.

For iOS framework: Developer is free to distribute iOS framework without codesigning it as Consumer will re-codesign it anyway, but Developer is forced by Xcode to codesign their framework when they build for iOS device.

Because of radar: "iOS frameworks containing simulator slices can't be submitted to the App Store" Consumer of iOS framework is forced to run special script like "copy_frameworks" or "strip_frameworks" which uses lipo -remove to strip off simulator slices from iOS framework and re-codesigns stripped framework because at this point its codesigning identity whatever it was (or wasn't) is removed as side effect of lipo -remove manipulation.

Longer answer follows.


This answer is not a "drawing from credible and/or official sources" one but is rather based on a number of empiric observations.

Empiric observation #1: Consumer does not care because they will re-codesign framework they receive from Developer

Binary framework distributions of well-known open source projects on Github are not codesigned. Command codesign -d -vvvv gives: "code object is not signed at all" on all of the binary iOS and OSX frameworks I used to explore. Some examples: ReactiveCocoa and Mantle, Realm, PromiseKit.

From this observation it is clear that authors of these frameworks intend them to be codesigned by Consumer, on their behalf i.e. a Consumer must use either "Code Sign on Copy" flag in "Embed frameworks" build phase provided by Xcode or use some custom shell script which does the same thing manually: codesigns framework on the Consumer's behalf.

I didn't find any single example of the opposite: open source framework that would be distributed with codesigning identity in it so in the rest of the answer I am assuming this widely adopted approach as correct one: there is no need for framework Developer to distribute their framework to other developers with codesigning identity in it because Consumer will anyway re-codesign it.

Empiric observation #2 which applies to iOS only and which is entirely a Developer's concern

While Consumer does not care whether framework they receive from Developer is codesigned or not, Developer still needs to codesign their iOS framework as part of its build process when they build it for iOS device because otherwise Xcode does not build: CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'. To quote Justin Spahr-Summers:

OS X frameworks don't need to be codesigned at build... Unfortunately, Xcode does require that iOS frameworks be codesigned at build time.

This pretty well answers on my question #2: "iPhone Developer" identity is enough to cajole Xcode so that it would build iOS framework for device. This comment on Carthage#339 says the same thing.

Empiric observation #3: lipo tool

Specific behavior of lipo tool: when applied to framework binary, it always recursively removes any codesign identities from it: lipo -create/-remove codesigned framework ... -> not codesigned framework.

This could be an answer why all of the examples in observation #1 are not codesigned at all: their codesigning identity is blown away after lipo is applied but since according to observation #1 Consumer does not care it is fine.

This observation is especially relevant to the next observation #4 about AppStore.

Empiric observation #4: iOS frameworks containing simulator slices can't be submitted to the App Store

This is widely discussed in: Realm#1163 and Carthage#188 and radar is opened: rdar://19209161.

This is entirely Consumer's concern: for iOS universal framework that Consumer includes in their application, when application is being built, they must run special script (custom Run Script Phase) that removes simulator slice from that framework's binary so that app could pass AppStore validation.

The good example for binary frameworks I found in Realm: strip-frameworks.sh.

It uses lipo to remove all slices of architectures other than ${VALID_ARCHS} and then re-codesigns it with Consumer's identity - this is where observation #3 kicks in: framework is to be re-codesigned because of lipo manipulations on it.

Carthage has CopyFrameworks.swift script which does the same thing to all the frameworks included by Consumer: it strips off the simulator slices and re-codesigns framework on behalf on Consumer.

Also there is good article: Stripping Unwanted Architectures From Dynamic Libraries In Xcode.


Now the overview of steps required to produce both iOS and OSX from both Developer's and Consumer's perspectives. First the easier one:

OSX

Developer:

  1. Builds OSX framework
  2. Gives it to Consumer

No codesigning activities are required from Developer.

Consumer:

  1. Receives OSX framework from Developer
  2. Copies framework to Frameworks/ directory and codesigns it automatically on their, Consumer's, behalf as part of "Code Sign on Copy" process.

iOS

Developer:

  1. Builds iOS framework for device. Codesigning is required by Xcode, "iPhone Developer" identity is enough.
  2. Builds iOS framework for simulator.
  3. Uses lipo that produces universal iOS framework from previous two. At this point the codesigning identity of 1 step is lost: universal framework binary "is not signed at all" but that is fine since "Consumer does not care".
  4. Gives it to Consumer

Consumer:

  1. Receives iOS framework from Developer
  2. Copies framework to Frameworks/ directory (this step may be redundant depending on what script in step 3 is.)
  3. Uses special script as a part of build process: this script strips simulator slices off the iOS framework and then re-codesigns it on their, Consumer's, behalf.

Codemagic | iOS Build failed

you can try the following solutions:

  • check your Icon implementation how recommended here
  • try to build with --no-tree-shake-icons option (Settings > Build > Build arguments > iOS)
  • upgrade Flutter version

xcodebuild stuck at codesign step when being run in Travis CI

I solved same problem by following steps that is described here.

https://github.com/travis-ci/travis-ci/issues/6791#issuecomment-261215038

a) change argument for all your security imports to keychain from -T to -A

security import ./scripts/certs/dist.cer -k ~/Library/Keychains/ios-build.keychain -A

b) after all imports execute command set-key-partition-list

security set-key-partition-list -S apple-tool:,apple: -s -k <keychainPass> <keychainName>



Related Topics



Leave a reply



Submit