Code Signing

RSS for tag

Certify that an app was created by you using Code signing, a macOS security technology.

Code Signing Documentation

Posts under Code Signing tag

265 results found
Sort by:
Post not yet marked as solved
24k Views

Not able to install enterprise build in iOS 15 beta version

After updating the os, not able to install the enterprise app through ipa, it throws error unable to install the app. Also not able to launch the enterprise app which was present in the device before updating the OS iOS 15 beta, it throws error, the developer of this app needs to update it to work with this version of iOS Kindly update on this. Any app side changes has to be done for this to fix these issues ?
Asked
by Shwetham.
Last updated
.
Post not yet marked as solved
67 Views

Think I am misunderstanding keychain-access-groups, can anyone confirm how I should be handling it

I have a really simple profile, the entitlements are as follows. <key>Entitlements</key> <dict> <key>com.apple.application-identifier</key> <string>QXAFMEPH6X.com.ohanaware.aquaSwatch</string> <key>com.apple.developer.team-identifier</key> <string>QXAFMEPH6X</string> <key>keychain-access-groups</key> <array> <string>QXAFMEPH6X.*</string> </array> </dict> However when I add the keychain-access-groups to the code signing entitlements. <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.files.user-selected.read-write</key> <true/> <key>com.apple.security.network.client</key> <true/> <key>keychain-access-groups</key> <array> <string>QXAFMEPH6X.com.ohanaware.aquaSwatch</string> </array> The application crashes on launch. Exception Type: EXC_CRASH (Code Signature Invalid) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace CODESIGNING, Code 0x1 I think I may have misunderstood Quinn's excellent article on Provision Profiles, because I assumed that the wildcard in the Profile, allowed me to use any identifier as long as the team id was correct. https://developer.apple.com/forums/thread/685723 Thank you for any asssitance Sam Rowlands
Asked
by rowlands.
Last updated
.
Post not yet marked as solved
1.7k Views

executable is killed after codesign

Hi,After we made changes for apple notarization, I cannot seem to re-place a binary for debugging.[This are all terminal binaries, not apps]executable A is linked with library B, both are codesingned withcodesign -f -o runtime -s "identity" <binary>and, are runnign fine.Now, for debugging if I make a change in B and replace it, now A is killed right away with errorException Type: EXC_BAD_ACCESS (Code Signature Invalid)Exception Codes: 0x0000000000000032, 0x0000000103082000Exception Note: EXC_CORPSE_NOTIFYTermination Reason: Namespace CODESIGNING, Code 0x2Application Specific Information:dyld: in dlopen()<path to library B>even if I add entitlement get-task-allow to executable A, it's still same.What can I do, what am I missing?
Asked Last updated
.
Post not yet marked as solved
30 Views

Is Apple's Timestamp Server Acting Up?

I'm hitting an error in codesign. It's reporting "The timestamp service is not available." Are other people hitting this error? I confirmed that if I use -timestamp=none, it works (but of course I cannot notarize). So I'm inclined to believe that the error message actually means what it says. I tried rebooting, checked my certificates haven't expired, and tried using three different LANs to eliminate networking issues. The app I'm signing is Electron, and I've noticed that the specific file it dies on changes each time. That makes me suspect the timestamp service might be only working intermittently.
Asked
by jesmith.
Last updated
.
Post not yet marked as solved
819 Views

Cannot Build Debug - "App requires a provisioning profile with Push Notifications etc"

I am using Xcode 12.5 and automatic signing. I can build release locally but cannot build debug to run on my device. Code Signing Error: "Unity-iPhone" requires a provisioning profile with the In-App Purchase, Game Center, and Push Notifications features. Select a provisioning profile in the Signing & Capabilities editor. Code Signing Error: Code signing is required for product type 'Application' in SDK 'iOS 14.5' Code Signing Error: Code signing is required for product type 'Application' in SDK 'iOS 14.5' I have checked everything several times. My provisioning profile includes those capabilities. I have revoked and created my certificates and provisioning profiles in Xcode. I even went as far as so configure APNs with SSL certificates but I still keep getting the same error. I have tried manual code signing, and checked my build settings. Identity, team, profile settings all seem to be correct. I have also tried manual code signing and again everything looks correct my build settings. Same error no matter what I do. Really at a loss here.
Asked Last updated
.
Post not yet marked as solved
43 Views

Xcode and App Signer Issue

My Xcode seems to be working properly. However, when I am running IOS App Signer to convert my *.deb file to an *ipa file there are issues. Issue 1: IOS App Signer does not see a Signing Certificate Issue 2: IOS App Signer "Provisioning Profile" sees my IOS Team Provisioning Profile but the numbers in Parentheses does not match my Xcode Team Provisioning Profile in Parentheses. The 10 digit numbers are different in Xcode and IOS App Signer. The numbers beside my Profile in Xcode match my Keychain. But for some reason IOS App Signer does not see the correct profile and new numbers in parentheses. Also, I have a free account. Any help would be appreciated
Asked Last updated
.
Post not yet marked as solved
327 Views

otool -L randomly crashing? (fatal error in otool-classic)

I recently switched to Apple Silicon on a MacBook Air / M1 and ever since have been facing a weird crash when using otool. My scenario has me working with a repository of precompiled universal dylibs which all are code signed with an adhoc profile. All of these dylibs are valid and 100% readable on disc. However sometimes, randomly any number of them will cause otool to crash with this message: otool: fatal error in /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool-classic Copying the affected library to a different place, deleting the original and moving the copy back to where the original was solves the issue for a random amount of time. The crash is always the same and the workaround is always as described up. However I have no idea what's causing the issue as the same project has been working without any issues on an intel Mac for almost two years. Looking into my crash logs I find the following: Process: otool-classic [8670] Path: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool-classic Identifier: otool-classic Version: 980.1 Code Type: ARM-64 (Native) Parent Process: ??? [8669] Responsible: Terminal [96515] User ID: 501 Date/Time: 2021-08-27 17:46:21.774 +0200 OS Version: macOS 11.5.1 (20G80) Report Version: 12 Anonymous UUID: E4021586-8704-4B85-AC4E-265554E01C00 Sleep/Wake UUID: DD48C75B-1051-4B24-A92D-38EDEE55A6AE Time Awake Since Boot: 28000 seconds Time Since Wake: 5100 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (Code Signature Invalid) Exception Codes: 0x0000000000000032, 0x0000000105210000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace CODESIGNING, Code 0x2 kernel messages: VM Regions Near 0x105210000: __LINKEDIT 105208000-10520c000 [ 16K] r--/r-- SM=NUL /usr/lib/dyld --> mapped file 10520c000-1055f4000 [ 4000K] rw-/rw- SM=COW Object_id=580efbdb MALLOC_TINY 13f600000-13f700000 [ 1024K] rw-/rwx SM=PRV Application Specific Information: dyld2 mode Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 otool-classic 0x0000000104da7440 ofile_specific_arch + 448 1 otool-classic 0x0000000104da731c ofile_specific_arch + 156 2 otool-classic 0x0000000104da4690 ofile_process + 2668 3 otool-classic 0x0000000104da8434 main + 2336 4 libdyld.dylib 0x0000000181789430 start + 4 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x000000013f606780 x1: 0x0000000104e0b3e0 x2: 0x0000000000000000 x3: 0x000000013f606787 x4: 0x0000000000000000 x5: 0x0000000000000010 x6: 0x0000000000000000 x7: 0x0000000000000000 x8: 0x00000001055f0660 x9: 0x0000000000216390 x10: 0x00000000003e0660 x11: 0x0000000105426390 x12: 0x0000000000010000 x13: 0x0000000000000015 x14: 0x0000000000000800 x15: 0x000000008000001f x16: 0x00000001817b424c x17: 0x000000018158e83c x18: 0x0000000000000000 x19: 0x000000016b05f490 x20: 0x000000016b05f4d8 x21: 0x0000000105210000 x22: 0x0000000000216390 x23: 0x000000016b05f5c8 x24: 0x0000000000000000 x25: 0x0000000000000000 x26: 0x000000016b05f988 x27: 0x0000000000000000 x28: 0x0000000000000001 fp: 0x000000016b05f430 lr: 0x0000000104da731c sp: 0x000000016b05f3e0 pc: 0x0000000104da7440 cpsr: 0x20000000 far: 0x0000000105210000 esr: 0x92000007 Binary Images: 0x104da0000 - 0x104e23fff +otool-classic (980.1) <67F17B71-A17E-3BDC-B6C2-038E0044413D> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool-classic 0x105104000 - 0x105183fff dyld (852.2) <17D14D9B-B6B2-35DC-B157-4FD60213BE99> /usr/lib/dyld [remainder removed, see attachment] otool-classic_2021-08-27-174622_MacBook-Air.crash
Asked
by Shirk.
Last updated
.
Post not yet marked as solved
1.5k Views

Signing modified binaries

Big Sur on the M1 processor seems to prevent modified binaries from running. For instance, a simple C hello world: #import <stdio.h> int main(void) { &#9;printf("Hello World!\n"); } If I compile this with Clang and run it, everything works as expected. However, if I go into a hex editor and change the 'H' => 'h' (or something else trivial), the kernel immediately sends a SIGKILL, i.e. ➜&#9;~ ✗ ./a.out [1]&#9;&#9;943 killed&#9;&#9; ./a.out This is expected, since modifying the binary's hex would invalidate the signature, but when I try to resign the executable, I get the following non-descipt error: ➜&#9;~ ✗ codesign -s zbaylin a.out a.out: the codesign_allocate helper tool cannot be found or used From other posts I've seen online, this is often the result of codesign_allocate not being in one's path, but I know codesign_allocate is in my PATH, and I am able to sign unmodified executables, but any binary that has been modified refuses to sign. Is this behavior documented anywhere, and would I be able to sign these executables? I should mention that all of this works on my 2019 MacBook Pro (x86, obviously), so I think it has something to do with the M1 in particular.
Asked
by zbaylin.
Last updated
.
Post not yet marked as solved
7.1k Views

Signing a Mac Product For Distribution

I spend a lot of time helping Mac developers with notarisation and Gatekeeper problems, and many of these problems are caused by incorrect code signing. The instructions for how to sign and package a Mac product for distribution are rather scattered, so I’ve written them all down in one place. And rather than keep that to myself, I’m posting it here for everyone’s benefit. If you have any corrections, feel free to get in touch with me directly (my email address is in my signature). And if have any questions about this, it’s probably best to ask them here on DevForums. I’ve locked this thread, so just start a new thread in the Distribution > Mac Apps topic area. Or, if you want one-on-one help, open a DTS tech support incident and we can pick things up in that context. IMPORTANT None of the following has been formally reviewed, so it’s not official Apple documentation. Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = "eskimo" + "1" + "@" + "apple.com" Signing a Mac Product For Distribution The best way to sign and package an app is via Xcode: Build a version of your app to distribute using Xcode’s Product > Archive command, and then package that archive for your distribution channel via the Organizer. See Xcode Help > Distribute your app for the details. However, not all Mac products can be distributed this way. For example: An app that’s distributed outside of the Mac App Store on a disk image A product that has to be installed via an installer package An app that uses a third-party development environment In these cases you must manually sign and package your product. Note If you find this post a little abstract, and would prefer to follow a concrete example, see Manual Code Signing Example. Consult Resources for Third-Party Development Environments Many third-party development environments have their own strategies for signing and packaging the products they build. If you’re using a third-party development environment, consult its support resources for advice before continuing. Decide on a Container Format To get started, decide on your container format. Mac products support two distribution channels: An app can be distributed via the Mac App Store Apps and non-apps can be distributed outside of the Mac App Store using Developer ID signing A Mac App Store app must be submitted as an installer package. In contrast, products distributed outside of the Mac App Store can use a variety of different container formats, the most common being: Zip archive (.zip) Disk image (.dmg) Installer package (.pkg) It’s also possible to nest these. For example, you might have an app inside an installer package on a disk image. Each container format has its own pros and cons, so pick an approach based on the requirements of your product. However, this choice affects how you package your product, something discussed in more detail below. Structure Your Code Correctly All code that you distribute must be signed. There’s two parts to this: Structuring your code to support signing Actually signing it You must structure your code correctly. If you don’t, it may be hard (or in some cases impossible) to sign it. First things first, identify all the code in your product. There are many types of code, including apps, app extensions, frameworks, other bundled code (like XPC Services), shared libraries, and command-line tools. Each type of code has two key attributes Is it bundled code? (apps, app extensions, frameworks, other bundled code) Is it a main executable? (apps, app extensions, command-line tools) Both of these attributes affect how you sign the code. In addition, whether the code is bundled is critical to how you structure it. Specifically, bundled code supports the notion of nested code. For example, you might have an app extension nested within your app’s bundle. When dealing with nested code, follow these rules: Place any nested code in the appropriate nested code location. For more on that, see Placing Content in a Bundle. Do not place non-code items in a nested code location. Rather, place these in the bundle’s resources directory (typically Contents/Resources). IMPORTANT Scripts are not considered code. If you have scripts — shell, Python, AppleScript, or whatever — place them in the resources directory. These will still be signed, but as a resource rather than as code. Provisioning Profile If you have a main executable that uses a restricted entitlement, one that must be allowlisted by a provisioning profile, place the profile in your bundle at the path Contents/embedded.provisionprofile. The profile is sealed by the code signature, so do this before signing the code. If your product contains multiple executables that need a profile — for example, you have an app with an embedded Network Extension app extension, both of which need the Network Extensions entitlement — repeat this process for each of these code executables. If your product includes a non-bundled executable that uses a restricted entitlement, you must package that executable in an app-like structure. See Packaging a Daemon with a Provisioning Profile. Use Symlinks to Deal with Alien Structures If you’re using a complex third-party library, you may find that the structure required by the library does not match up with the structure required by macOS. In many cases you can resolve this conflict using symlinks. For details, see this DevForums post. Sign Your Code Sign code using the codesign tool. Read the following sections to learn about the specific arguments to use, but also keep these general rules in mind: Do not use the --deep argument. This feature is helpful in some specific circumstances but it will cause problems when signing a complex program. For a detailed explanation as to why, see --deep Considered Harmful. Rather, sign each code item separately. For a complex app, you should create a script to do this. Sign from the inside out. That is, if A depends on B, sign B before you sign A. When you sign A, the code signature encodes information about B, and changing B after the fact can break the seal on that code signature. Basic Signing No matter what sort of code you’re signing, the basic codesign command looks like this: % codesign -s III /path/to/your/code` where III is the name of the code signing identity to use. The specific identity varies depending on your target platform. See the following sections for details. When signing bundled code (as defined in Structure Your Code Correctly) pass in the path to the bundle, not the path to the code. If you’re re-signing code — that is, the code you’re signing is already signed — pass the -f option. If you’re signing a main executable (as defined in Structure Your Code Correctly) that needs entitlements, add --entitlements ***.entitlements, where ***.entitlements is a path to a property list file that contains your entitlements. IMPORTANT The entitlements property list file must be in the standard XML format with LF line endings, no comments, and no BOM. If you’re not sure of the file’s provenance, use plutil to convert it to the standard format. See Ensure Properly Formatted Entitlements in Resolving Common Notarization Issues. If you’re signing non-bundled code, set the code signing identifier by adding -i BBB, where BBB is the bundle ID the code would have if it had a bundle ID. For example, if you have an app whose bundle ID is com.example.flying-animals that has a nested command-line tool called pig-jato, the bundle ID for that tool would logically be com.example.flying-animals.pig-jato, and that’s a perfectly fine value to use for BBB. Note For bundled code, you don’t need to supply a code signing identifier because codesign defaults to using the bundle ID. Mac App Store Signing If you’re distributing via the Mac App Store, use your Mac App Distribution signing identity in place of III in the example above. This will typically be named 3rd Party Mac Developer Application: TTT, where TTT identifies your team. You can also use an Apple Distribution signing identity, with the name Apple Distribution: TTT. Developer ID Signing If you’re distributing outside of the Mac App Store, use your Developer ID Application signing identity in place of III in the example above. This will typically be named Developer ID Application: TTT, where TTT identifies your team. All Developer ID signed code needs a secure timestamp; enable this by adding the --timestamp option. If you’re signing a main executable (as defined in Structure Your Code Correctly), enable the hardened runtime by adding -o runtime option. The hardened runtime enables additional security checks within your process. You may need to make minor code changes to be compatible with those additional security checks. For some specific examples, watch WWDC 2019 Session 703 All About Notarization. Failing that, you can opt out of these additional security checks using entitlements. See Hardened Runtime Entitlements Build Your Container Once you’ve signed the code in your product, it’s time to wrap it in a container for distribution. Follow the advice appropriate for your chosen container format in the following sections. If you’re using a nested container format — for example, an app inside an installer package on a disk image — work from the inside out, following the advice for each level of nesting. Build a Zip Archive Use the ditto tool to create a zip archive for your product: Create a directory that holds everything you want to distribute. Run the ditto as shown below, where DDD is the path to the directory from step 1 and ZZZ is the path where ditto creates the zip archive. . % ditto -c -k --keepParent DDD ZZZ Zip archives cannot be signed (although their contents can be). Build an Installer Package Use the productbuild tool to create a simple installer package for a single app: % productbuild --sign III --component AAA /Applications PPP In this example: III is either your Mac Installer Distribution or Developer ID Installer signing identity, depending on your distribution channel. This will typically be named 3rd Party Mac Developer Installer: TTT or Developer ID Installer: TTT, where TTT identifies your team. AAA is the path to your app. PPP is the path where productbuild creates the installer package. IMPORTANT The above is the simplest possible example. There are many different ways to create installer packages. See the man pages for productbuild, productsign, pkgbuild, and pkgutil for more details. Build a Disk Image Use the hdiutil tool to create a disk image for distribution: Create a directory to act as the source for the root directory of your disk image’s volume. Populate that directory with the items you want to distribute. Use hdiutil command shown below to create the disk image, where SSS is the directory from step 1 and DDD is the path where hdiutil creates the disk image. Use codesign command shown below to sign the disk image, where III is your Developer ID Application signing identity (typically named Developer ID Application: TTT, where TTT identifies your team), BBB is a pseudo bundle ID as discussed in Basic Signing, and DDD is the path to the disk image from step 3. . % hdiutil create -srcFolder SSS -o DDD % codesign -s III --timestamp -i BBB DDD IMPORTANT There are various third-party tools that can help you create a disk image in exactly the right way. For example, the tool might arrange the icons nicely, set a background image, and add a symlink to /Applications. If you use such a tool, or create your own tool for this, make sure that the resulting disk image: Is signed with your Developer ID Application signing identity Is a UDIF-format read-only zip-compressed disk image (type UDZO) Notarisation If you’re distributing outside of the Mac App Store, you must notarise the file you intend to distribute to your users. For instructions on doing this, see Customizing the Notarization Workflow. Skip the Export a Package for Notarization section because you already have the file that you want to submit. If you’re using a nested container format, only notarise the outermost container. For example, if you have an app inside an installer package on a disk image, sign the app, sign the installer package, and sign the disk image, but only notarise the disk image. The exception to this rule is if you have a custom third-party installer. In that case, see the discussion in Customizing the Notarization Workflow. Stapler Once you have notarised your product, you should staple the resulting ticket to the file you intend to distribute. Customizing the Notarization Workflow discusses how to do this for a zip archive. The other common container formats (installer package and disk image) support stapling directly. For example: % xcrun stapler staple FlyingAnimals.dmg Note Stapling is recommended but not mandatory. If you don’t staple, a user may have problems if they try to install or run your app for the first time when the Mac is offline. Change history: 20 Jan 2020 — First version. 27 Jan 2020 — Minor editorial changes. 9 Mar 2020 — Moved the details of --deep into a separate post, --deep Considered Harmful. 10 Mar 2020 — Fixed a typo. 30 Mar 2020 — Added a link to Manual Code Signing Example. 26 Feb 2021 — Fixed the formatting. Add a discussion of the entitlements file format. Minor editorial changes. 1 Mar 2021 — Added the Provisioning Profile section. 21 Oct 2021 — Updated the Structure Your Code Correctly section to reference Placing Content in a Bundle.
Asked
by eskimo.
Last updated
.
Post not yet marked as solved
693 Views

Embedding a Command-Line Tool in a Sandboxed App

I regularly help developers — both here on DevForums and as part of my Day Job™ in DTS — who have a sandboxed app, built with Xcode, and want to embed a helper tool within that app. For example: They have some of their own code that they want to run in a separate process. In many cases an XPC Service is a better choice for this, but sometimes it’s just easier to embed a command-line tool. They have a command-line tool that was built by an external build system (makefiles and so on). Doing this is a bit tricky, so I thought I’d write down the process for the benefit of all. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Embedding a Command-Line Tool in a Sandboxed App Using Xcode to emded a command-line tool in a sandboxed app is a little tricky. The exact process you use depends whether you want to build the tool using Xcode or you have an existing tool that was built by an external build system. I’ll cover each scenario in turn. Note This post focuses on building an app for the App Store because that’s where most sandboxed apps are destined. However, the same basic process works for Developer ID; you just need to choose a different distribution path in the Organizer. The post assumes Xcode 12.5 running on macOS 11.3. Embed a Tool Built With Xcode This section describes how to use Xcode to create a sandboxed app and then embed a helper tool, also built with Xcode, into that app. Create an App Project To get started, first create a new project from the macOS > App template. In this example I named it Test768613894, resulting in a bundle ID of com.example.apple-samplecode.Test768613894. In the project editor, set the deployment target to 10.15. This isn’t strictly necessary but I’ll use it to show how to configure the app and its embedded helper tools to use the same deployment target. In the General tab of the app target editor, set the App Category to Utilities. This avoids a warning when you try to submit to the store. In the Signing & Capabilities tab of the app target editor, make sure that “Automatically manage signing” is checked and then select the appropriate team. The Signing Certificate popup will switch to Development, which is exactly what you want for day-to-day development. Add the Hardened Runtime capability. This isn’t necessary for App Store submission but it’s a good idea to use it on all new projects. Choose Product > Archive. This builds the app into an Xcode archive and reveals that archive in the Organizer. The goal here is to simply check that everything is working so far. In the Organizer, delete the new archive, just to reset things back to the original state. Create the Helper Tool With the app target in the project building correctly, it’s time to create a helper tool target so that you can embed its product into the app. To start, create a new target from the macOS > Command Line Tool template. I named this ToolX, where the X stands for built with Xcode. In the General tab of the tool target editor, clear the Deployment Target field. The tool will now inherit its deployment target (macOS 10.15) from the project. In the Signing & Capabilities tab of the tool target editor, make sure that “Automatically manage signing” is checked and then select the appropriate team. Again, the Signing Certificate popup will switch to Development. Fill in the Bundle Identifier field. As my app’s bundle ID is com.example.apple-samplecode.Test768613894 I set this to com.example.apple-samplecode.Test768613894.ToolX. Bundle IDs generally don’t play a big part in command-line tools but it’s necessary in this case because of the way that I set up the code signing identifier (see below). Add the App Sandbox and Hardened Runtime capabilities. Again, the Hardened Runtime isn’t required but it’s good to start as you mean to go on. In the Build Settings tab, set the Skip Install (SKIP_INSTALL) build setting to true. Without this Xcode copies the tool into the ‘root’ of your Xcode archive, which causes grief later on. Also set Code Signing Inject Base Entitlements (CODE_SIGN_INJECT_BASE_ENTITLEMENTS) to false. If you leave this set then Xcode will include the get-task-allow entitlement in development builds of your tool, but this entitlement is incompatible with the com.apple.security.inherit entitlement. IMPORTANT This means that you won’t be able to debug your tool. If you need to do this, create a new target for the tool, one that’s not sandboxed at all. Be warned, however, that this target may behave differently from the embedded tool target because it’s not running under the sandbox. Finally, set Other Code Signing Flags (OTHER_CODE_SIGN_FLAGS) to $(inherited) -i $(PRODUCT_BUNDLE_IDENTIFIER). This ensures that the tool’s code signing identifier matches its bundle ID, a matter of best practice. Select ToolX.entitlements in the Project navigator and added com.apple.security.inherit to it, with a Boolean value of true. Select the ToolX scheme and chose Product > Build, just to make sure that it builds correctly. Now switch back to the app (Test768613894) scheme. Embed the Helper Tool In the Build Phases tab of the app target editor, add the ToolX target to the Dependencies build phase. This ensures that Xcode builds the tool before building the app. Add a new Copy Files build phase. Named this Embed Helper Tools (the exact name doesn’t matter but it’s best to pick a descriptive one) and set the Destination popup to Executables. Note This will place the helper tool in your app’s Contents/MacOS directory, the location recommended by Placing Content in a Bundle. Add the ToolX executable to that build phase, making sure that Code Sign On Copy is checked. Build and Validate With the project now set up it’s time to test that everything builds correctly. To start, do another Product > Archive. This will build the tool target and then the app target, embedding the former within the latter. In the Organiser, select the newly-created archive and click Distribute App. Note If the button says Distribute Content rather than Distribute App, go back and check that you set the Skip Install build setting on the tool target. Select App Store Connect, clicked Next, then Export and clicked Next. Go through the rest of the export workflow. The end result is a directory with a name like Test768613894 2021-05-17 14-07-21. In that directory is an installer package. Unpack that. Note I used Pacifist for this but, if you don’t have that app, and you should!, see Unpacking Apple Archives. Run the following commands to validate that Xcode constructed everything correctly. % codesign -d -vvv --entitlements :- Test768613894.app … Identifier=com.example.apple-samplecode.Test768613894 Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=822 flags=0x10000(runtime) hashes=14+7 location=embedded … Authority=Apple Distribution: Quinn Quinn (SKMME9E2Y8) … TeamIdentifier=SKMME9E2Y8 … <dict> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.files.user-selected.read-only</key> <true/> </dict> </plist> % codesign -d -vvv --entitlements :- Test768613894.app/Contents/MacOS/ToolX … Identifier=com.example.apple-samplecode.Test768613894.ToolX Format=Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=796 flags=0x10000(runtime) hashes=13+7 location=embedded … Authority=Apple Distribution: Quinn Quinn (SKMME9E2Y8) … TeamIdentifier=SKMME9E2Y8 … <dict> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.inherit</key> <true/> </dict> </plist> I want to highlight some things in this output: The Identifier field is the code signing identifier. The Format field shows that both executables are universal. The runtime flag, in the CodeDirectory field, shows that the hardened runtime is enabled. The Authority field shows that the code was signed by my Apple Distribution signing identity, which is what you’d expect for an App Store submission. The TeamIdentifier is… well… the Team ID. The app’s entitlements include com.apple.security.app-sandbox and whatever other entitlements are appropriate for this app. The tool’s entitlements include just com.apple.security.app-sandbox and com.apple.security.inherit. IMPORTANT Any other entitlements here can cause problems. If you find that, when your app runs the tool, it immediately crashes with a code signing error, check that the tool is signed with just these two entitlements. Embedding an Externally-Built Tool With the app and Xcode-built helper tool working correctly, it’s time to repeat the process for a tool built using an external build system. In this example we’ll create a dummy helper tool from the command line and then embed that in the Test768613894 app. Build the Tool Create a new directory and change into it: % mkdir ToolC % cd ToolC Here C stands for built with Clang. Create a source file in that directory that looks like this: % cat main.c #include <stdio.h> int main(int argc, char ** argv) { printf("Hello Cruel World!\n"); return 0; } Build that with clang twice, once for each architecture, and then lipo them together: % clang -o ToolC-x86_64 -mmacosx-version-min=10.15 -arch x86_64 main.c % clang -o ToolC-arm64 -mmacosx-version-min=10.15 -arch arm64 main.c % lipo ToolC-x86_64 ToolC-arm64 -create -output ToolC The -mmacosx-version-min option sets the deployment target to match the Test768613894 app. Create an entitlements file for the tool: % cat ToolC.entitlements <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.inherit</key> <true/> </dict> </plist> Sign the tool as shown below: % codesign -s - -i com.example.apple-samplecode.Test768613894.ToolC -o runtime --entitlements ToolC.entitlements -f ToolC This breaks down as follows: The -s - argument applies an ad-hoc signature (in Xcode parlance this is Sign to Run Locally). More on this below. The -i com.example.apple-samplecode.Test768613894.ToolC option sets the code signing identifier. The -o runtime option enables the hardened runtime. Again, this isn’t necessary for App Store distribution but it’s a good idea in general. The --entitlements ToolC.entitlements option supplies the signature’s entitlements. The -f option overrides any existing signature. This isn’t strictly necessary but it avoids any confusion about the existing ad-hoc signature applied by the linker to the arm64 architecture. IMPORTANT Setting up the code signature here is critical. It sets up a ‘pattern’ that Xcode uses when it re-signs the tool while embedding it into the final app. The only thing that doesn’t matter here is the signing identity. Xcode will override that with the project’s signing identity during this embedding process. That’s why we can get away with an ad-hoc signature. Add the ToolC executable to your Test768613894 project. When you do this: Enable “Copy items if needed”. Select “Create groups” rather than “Create folder reference.” Uncheck all the boxes in the “Add to targets” list. In the Build Phases tab of the app target editor, add ToolC to the build phase, making sure that Code Sign On Copy is checked. Validate To validate your work, follow the same process as described in the Build and Validate section, substituting ToolC for ToolX everywhere. Change History 17 May 2021 — First posted. 21 Oct 2021 — Updated the Embed the Helper Tool section to reference the new Placing Content in a Bundle article.
Asked
by eskimo.
Last updated
.
Post not yet marked as solved
57 Views

My app is damaged and can't be opened when porting to M1 ?

I have porting my existing application to support native M1, there a a lot of framework and library that I have already build for both platform. The strange result is when I archive the app on Intel machine. The binary work on Intel platform well. When I archive my application on M1 machine, the app can work on M1 well. But when I try to run app that build on M1 on Intel Machine, then I got the message said my app is damaged and can't be opened. The same situation got for build in Intel platform one. I try "lipo -archs" command on my app and I did get "x86_64 arm64" as result, so my app should already a universal app I guess. Does any body know are there some way to check what happened on my application? Thanks, any opinion will be appreciated ! Eric
Asked
by Eric Peng.
Last updated
.
Post not yet marked as solved
85 Views

Signing an app

Hi I am working on a MacOs based application. we were signing application using certificate via Xcode. but now my company is not going to provide certificate to us due to some security issue. I have xcarchive file and need to sign it, is it a correct way to get .app signed it and put it back in xcarchive. I am trying to sign .app through command line. there are some third party static libraries in code (SparkleFramework). so signed those too. and then signed .app as well. When I check code sign using "codesign -vvv --deep --strict" it shows me error .app: a sealed resource is missing or invalid any help would be appreciated.
Asked Last updated
.
Post not yet marked as solved
50 Views

Build Project Xcode to ipa file

I have completed the code project in Xcode and I want to build in ipa file for installing it in iphone. When I go to archive it then I get error that build failed because I haven't created provisioning profile. I made some search online and If I have understood well, I should register an iphone to my account. How can I do this ? I ahve found some instructions like "Log into your developer.apple.com account and click on Certificates, Identifiers & Profiles." but when I login in the  developer.apple.com then not existed somewhere the "Certificates, Identifiers & Profiles" option. In somewhere I read that it should have done this with permission of your account like account holder, admin, app manager etc... but I don't know what permission I have & how to change it so that to have the option of "Certificates, Identifiers & Profiles" enabled. Also I saw somewhere for enroll in app developer but needs to pay. Is it obligatory to pay so that to convert the project to ipa file ? I found and someother solutions in Xcode so that to disable the signing and use the Ad Hoc Code Sign but also this option misses to select it. Finally what should I do so that to convert the Xcode project to ipa file ?
Asked
by John78.
Last updated
.
Post not yet marked as solved
45 Views

Can't install app on device?

Hi, I'm just revisiting an app I developed a couple of years ago so I'm a bit rusty on iOS development. I am trying to run the app on an iPad, and installation fails without any helpful information "Unable to install". It runs fine on an emulator, so I'm assuming its a signing/profile issue. When I started up Xcode it asked me to update the information on my Apple account, because I guess my Apple password changed since I last used Xcode. I did that and got the message "Signing update finished. No issues". So it seems it should work but it doesn't. Any advice would be much appreciated.
Asked
by mfleming.
Last updated
.
Post not yet marked as solved
4.2k Views

Signing failed: Provisioning profile "iOS Team Provisioning Profile: xx" doesn't match the entitlements file's value for the com.apple.developer.associated-appclip-app-identifiers entitlement.

Hello everyone, I'm trying to create an App Clip for my existing app (it's a multiplatform app). Now Xcode can't sign my app, and the following error appears: Provisioning profile "iOS Team Provisioning Profile: xx" doesn't match the entitlements file's value for the com.apple.developer.associated-appclip-app-identifiers entitlement. If I don't add that row in my project's entitlement then I can sign my app but I can't upload it to App Store Connect, telling me that the value is missing. I've tried to delete the saved profiles in my Mac and force Xcode to download them again. I started thinking about if you can create an App Clip for a multiplatform project or even if it's a bug in Xcode 12.5 beta 3. Does anyone experienced the same or have some suggestion to try? Thank you! Aniol
Asked Last updated
.