I am able to codesign my app and see it signed successfully. But then when I run it is just hangs, i.e. it does launch and shows in the system tray but no window pops up. I am also able to notarize the app successfully, but it seems code signing did something to cause it to not work the same. codesign -dvvv WhoStoleMyBeard.app Builds/MacOS/Native/App/WhoStoleMyBeard.app/Contents/MacOS/nwjs Identifier=io.nwjs.nwjs Format=app bundle with Mach-O thin (x86_64) CodeDirectory v=20500 size=440 flags=0x10000(runtime) hashes=3+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha1=04d39f1aa101d131750387c732d865e4187a8084 CandidateCDHashFull sha1=04d39f1aa101d131750387c732d865e4187a8084 CandidateCDHash sha256=476a47ff9f5fb21f44ddee8292c769d4178e02fd CandidateCDHashFull sha256=476a47ff9f5fb21f44ddee8292c769d4178e02fdbeb14a2893133dc64fd818f1 Hash choices=sha1,sha256 CMSDigest=36b3ddcf11edb24217ebb11c435b4b8a745ddbed0d29ec2b9573edce3298e4a1 CMSDigestType=2 CDHash=476a47ff9f5fb21f44ddee8292c769d4178e02fd Signature size=9055 Authority=Developer ID Application: *** Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Jul 19, 2021 at 4:03:15 PM Info.plist entries=31 TeamIdentifier=*** Runtime Version=10.12.0 Sealed Resources version=2 rules=13 files=2235 Internal requirements count=1 size=172 codesign -v --strict --deep --verbose=2 WhoStoleMyBeard.app WhoStoleMyBeard.app: valid on disk WhoStoleMyBeard.app: satisfies its Designated Requirement

I'm working on a MacOS desktop Electron app that is for distribution outside the app store using Developer ID. Before code signing, the app opened and was working well. But after code signing, I get the following error. stderr:dyld: Library not loaded: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libR.dylib Referenced from: /Users/home/Desktop/electron-start/dist/mac-arm64/electron1.app/Contents/Frameworks/R.framework/Versions/3.5/Resources/bin/exec/R Reason: image not found Before code signing I think the file was looking for a path within the app /Users/home/Desktop/electron-start/dist/mac-arm64/electron1.app/Contents/Frameworks/R.framework/Versions/3.5/Resources/bin/exec/R But now I think the file is looking for a path outside Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libR.dylib I used this entitlements file: <?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.cs.allow-unsigned-executable-memory</key> <true/> <key>com.apple.security.cs.disable-library-validation</key> <true/> <key>com.apple.security.cs.allow-dyld-environment-variables</key> <true/> </dict> </plist> Can anyone please help me? I've looked at many places and willing to learn. Thanks for your time. I really appreciate it.

We are building an open source, electron-based application and using electron-builder's code signing support to sign our application (that is distributed outside of the App Store). Unfortunately, we seem to have hit an impasse due to what appears to be a limitation (or bug) of the underlying Apple codesign utility. Our application bundles a couple of other open source projects "installed versions" inside of it. These applications, as well as our own, include TXT files mixed in with binary files and at least a couple of them cannot me separated from the binary directory. If codesign does not sign text files, why not just have a mechanism to skip over the text file (printing a warning if you must) and allow electron-builder's code signing process to continue?

I built a flutter app. I have built the app as Personal team user on my iphone and runned through Xcode. The app is installed on the device and Runner launches it. It works perfectly. But if i quit and try to launch the installed app manually by my self it does not launch

IMPORTANT This post is now retired in favour of TN3125 Inside Code Signing: Provisioning Profiles. I’m leaving the original post here just for the record, but you should consider the official documentation authoritative. I regularly help folks with code signing issues and have learnt that a lot of people are confused by the whole concept of a provisioning profile. This is my attempt to clear that up (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" What exactly is a provisioning profile? Apple platforms will not run arbitrary third-party code [1]. All execution of third-party code must be specifically authorised by Apple. This is done using a provisioning profile [2], which describes five requirements: Who is allowed to sign code? What apps [3] are they allowed to sign? Where can those apps run? When can those apps run? How are those apps entitled? When the developer web site creates a profile [4] it cryptographically signs it. When you run an app on a device, the device checks this signature to determine if the profile is valid and, if so, checks that all of the app’s requirements are met by that profile. [1] Except for macOS, although provisioning profiles are still relevant on macOS, as we’ll see later. [2] There is an interesting edge case here. When you submit your app to the App Store, it re-signs your app as part of the distribution process. Before doing that, it checks that the app is signed and provisioned correctly. That ingestion check means that each individual iOS device does not need to perform further security checks, so the final app does not have a provisioning profile. However, this third-party code was still, technically, authorised by a profile, albeit during the App Store ingestion process. [3] In this document I’m using the term app to refer to a main executable packaged in a bundle structure. So everything I say about apps also applies to app extensions, App Clips (iOS), system extensions (macOS), and XPC Services (macOS). [4] Either directly, using the web site itself, or indirectly, using tools like Xcode. Unpack a Profile A profile is a property list wrapped within a CMS signature [1]. To view the original property list, remove the CMS wrapper using the security tool: % security cms -D -i Profile_Explainer_iOS_Dev.mobileprovision -o Profile_Explainer_iOS_Dev.plist % cat Profile_Explainer_iOS_Dev.plist … <dict> … lots of properties … </dict> </plist> IMPORTANT The exact format of a provisioning profile is not documented and could change at any time. I discuss these details here because I think it’s useful to understand how things work under the covers. I recommend against building a product based on these details; if you do build such a product be prepared to update it as the Apple development story evolves. [1] Cryptographic Message Syntax, as defined by RFC 5652. The Who Every profile has a DeveloperCertificates property holding the certificates of each developer who is allowed to sign code that’s covered by the profile. For example: % cat Profile_Explainer_iOS_Dev.plist … <dict> … <key>DeveloperCertificates</key> <array> <data>MIIFxDCC…tOLykA==</data> … more certificates … </array> … </dict> </plist> Use PlistBuddy to extract a specific certificate: % /usr/libexec/PlistBuddy -c "Print :DeveloperCertificates:0" Profile_Explainer_iOS_Dev.plist > cert0.cer % certtool d cert0.cer Serial Number : 7E FF 9C 91 BB EB D8 AB 42 81 52 35 64 F9 0F 72 Issuer Name : Common Name : Apple Worldwide Developer Relations Certification Authority … Subject Name : … Common Name : Apple Development: Quinn Quinn (7XFU7D52S4) … Not Before : 09:15:23 Apr 21, 2021 Not After : 09:15:22 Apr 21, 2022 … The What Most profiles apply to a single App ID. This is encoded in the Entitlements > application-identifier [1] property: % cat Profile_Explainer_iOS_Dev.plist … <dict> … <key>Entitlements</key> <dict> … <key>application-identifier</key> <string>SKMME9E2Y8.com.example.apple-samplecode.ProfileExplainer</string> … </dict> … </dict> </plist> This property holds an App ID, composed of an App ID prefix (SKMME9E2Y8 in this example) and a bundle ID (com.example.apple-samplecode.ProfileExplainer). It is also possible to create a profile for a wildcard App ID: % security cms -D -i Profile_Explainer_Wild_iOS_Dev.mobileprovision -o Profile_Explainer_Wild_iOS_Dev.plist % cat Profile_Explainer_Wild_iOS_Dev.plist <dict> … <key>Entitlements</key> <dict> … <key>application-identifier</key> <string>SKMME9E2Y8.com.example.apple-samplecode.*</string> … </dict> … </dict> </plist> </plist> This profile is valid for any App ID starting with SKMME9E2Y8.com.example.apple-samplecode. [1] On macOS this is Entitlements > com.apple.application-identifier. The Where Most profiles apply to a specific list of devices. This is encoded in the ProvisionedDevices property: % cat Profile_Explainer_iOS_Dev.plist … <dict> … <key>ProvisionedDevices</key> <array> <string>00008030-001544522E60802E</string> </array> … </dict> </plist> App Store distribution profiles have no ProvisionedDevices property because you can’t run a distribution-signed app locally. Developer ID and In-House (Enterprise) distribution profiles have the ProvisionsAllDevices property, indicating that they apply to all devices. The When Every profile has an ExpirationDate property which limits how long the profile remains valid. For example: % cat Profile_Explainer_iOS_Dev.plist … <dict> … <key>ExpirationDate</key> <date>2022-07-23T14:30:34Z</date> … </dict> </plist> Developer ID profiles do not expire and thus their expiration date is far in the future. The How Every profile has an Entitlements property which authorises the app to use specific entitlements. For example: % cat Profile_Explainer_iOS_Dev.plist … <key>Entitlements</key> <dict> <key>application-identifier</key> <string>SKMME9E2Y8.com.example.apple-samplecode.ProfileExplainer</string> <key>keychain-access-groups</key> <array> <string>SKMME9E2Y8.*</string> <string>com.apple.token</string> </array> <key>get-task-allow</key> <true/> <key>com.apple.developer.team-identifier</key> <string>SKMME9E2Y8</string> </dict> The entitlements in the profile act as an allowlist. This is not the same as the entitlements claimed by the app. To actually claim an entitlement you must include the entitlement in the app’s code signature. Every entitlement claimed by the app must be in the profile’s allowlist [1] but the reverse is not true. It’s fine for the allowlist to include entitlements that the app does not claim. The wildcard syntax only make sense in a profile’s allowlist. In the above example, SKMME9E2Y8.* means that the app can claim any keychain access group starting with SKMME9E2Y8. Wildcards do not make sense in the app’s code signature. To dump the entitlements claimed by the the app, use codesign with the --entitlements argument: % codesign -d --entitlements :- ProfileExplainer.app … <dict> <key>application-identifier</key> <string>SKMME9E2Y8.com.example.apple-samplecode.ProfileExplainer</string> <key>keychain-access-groups</key> <array> <string>SKMME9E2Y8.com.example.apple-samplecode.ProfileExplainer</string> </array> <key>get-task-allow</key> <true/> <key>com.apple.developer.team-identifier</key> <string>SKMME9E2Y8</string> </dict> </plist> As you can see, every entitlement claimed here is allowed by the profile, and thus the app should run. Note that the keychain-access-groups value, SKMME9E2Y8.com.example.apple-samplecode.ProfileExplainer, starts with SKMME9E2Y8.* and thus is allowed by the wildcard. [1] Except on macOS, as discussed in the next section. Entitlements on the Mac A macOS app can claim certain entitlements without them being authorised by a provisioning profile. These unrestricted entitlements include: com.apple.security.get-task-allow [1] com.apple.security.application-groups [2] Those used to enable and configure the App Sandbox Those used to configure the Hardened Runtime Other entitlements must be allowlisted by a provisioning profile, just like on iOS. This is an important security feature on macOS. For example, the fact that the keychain-access-groups entitlement must be allowlisted by a profile means that other developers can’t impersonate your app in order to steal its keychain items. [1] On iOS this is named get-task-allow and, as with all entitlements on iOS, must be allowlisted by the profile. [2] App Groups work differently on macOS and iOS; see this post for the gory details. Profile Location Historically it was common to install provisioning profiles on the device as a whole (in Settings on iOS or System Preferences > Profiles on the Mac). That’s still possible, but standard practice is to embed the profile within the app itself: iOS expects to find the profile at MyApp.app/embedded.mobileprovision. macOS expects to find the profile at MyApp.app/Contents/embedded.provisionprofile. Note The platforms use different file name extensions for these profiles (.mobileprovision on iOS, .provisionprofile on macOS) App Store apps do not contain an embedded provisioning profile because the App Store checks that the app is signed and provisioned correctly as part of its app ingestion process.

Hello, all developers. I have some questions about code signing strategy, according to the sequence of signing (which I couldn't reached the answer by searching). That is, What happens when we DON'T provide any code signing identity and profile on ARCHIVE, and then we DO provide them on EXPORTING step? for example, xcodebuild archive \ -project <ProjectName>.xcodeproj \ -sdk iphoneos \ -scheme <SchemeName> -configuration Release \ CODE_SIGN_IDENTITY="" \#disable code sign CODE_SIGNING_REQUIRED=NO \#disable code sign CODE_SIGNING_ALLOWED=NO \#disable code sign Above is the code for archive without code sign. And below, for exporting, I provide profile using exportOptions.plist. xcodebuild -exportArchive -archivePath <ProjectName>.xcarchive -exportOptionsPlist <ProjectName>/exportOptions.plist -exportPath <ProjectName>.ipa Is this available for app-store distribution, if I used profile with distribution option? Are these right option to provide details of provisioning profile, when archiving the project? I've search lots of examples but the answers are slightly different. xcodebuild archive \ -project <ProjectName>.xcodeproj \ -sdk iphoneos \ -scheme <SchemeName> \ -configuration Release \ CODE_SIGN_IDENTITY="****D21C78" \ PROVISIONING_PROFILE="********-****-..." the code above keeps making the error : <ProjectName> requires a provisioning profile. Select a provisioning profile in the Signing & Capabilities editor, even though I'm working on CLI. If there's any solution for questions, please guide me. Any document / paper or other materials are fine too.

I already installed the code certificate of my .app in Mac OS but this error ""App name here.app" is damaged and can't be opened." still showing, and when I check the “Obtained from” in System Information>Software>Applications of my app it says “Unknown”. Is there any way to set my app as “Identified Developer” after code signing my app? Please help.

Hi people,  I’m trying to submit Mac App to the AppStore. An app is created with Unreal Engine. Of course, I spent some time reading every guide that I found on the web. I made all kinds of certificates, Identifiers&Profiles. Everything is correct and showing up where it must be. I’m running Unreal Engine 4.26.1 (already tried 4.26.2) on Mac. I’m generating an X-code project. Inside X-code, I edit info and adding profiles, then after I click "ARCHIVE", I’m getting a signing error. Already tried both manual and automatically manage signing and many, many more solutions from the web. And I’m always getting the same error: Command /usr/bin/codesign failed with exit code 1. Please, have a look at the attached screenshots. Any thoughts? I’m trying to add an app to AppStore because if I’m trying to spread it by myself, people get these “undefined developer” warnings and frustrating issues.  Any help is much appreciated!  Thank you so much, people!

Embedded binary is not signed with the same certificate as the parent app. Verify the embedded binary target's code sign settings match the parent app's. I don't know the real issue. Anyone help!!!

We are seeing mysterious crashes in our app when running on the Apple Silicon machines using Rosetta. The crash is coming from Apple's runtime and dyld libraries, and always has the same kind of stack, but without much useful information. All have the same pattern of 5 stack frames, the bottom being dyld, and then 4 in runtime, but all just addresses, no idea what symbols are being called Sometimes the offset values are the same, other times they are not. When you group them together, we have at least two sets of stacks; but close enough that it appears the same root issue. Only these two libraries appear to be loaded, so perhaps it's a crash on launch before things are adequately setup, or something weird happens during the crash and we are only getting a small part of the picture captured in the .crash, or some corruption happens All are in Apple Silicon machines Some are on macOS 11, and some on macOS 12, so it's not a Monterey beta issue They are all crashing for reason Code Signature Invalid, but this seems unreliable, if indeed we can launch the app afterwards without issue, which appears to be the case (based on log reports we've received). Here is a typical example (with some app info redacted): Version: ??? Code Type: X86-64 (Translated) Parent Process: ??? [1] User ID: 503 Date/Time: 2021-08-06 14:38:06.408 +0200 OS Version: macOS 11.5.1 (20G80) Report Version: 12 Time Awake Since Boot: 21000 seconds Time Since Wake: 15000 seconds System Integrity Protection: enabled Crashed Thread: 0 Exception Type: EXC_BAD_ACCESS (Code Signature Invalid) Exception Codes: 0x0000000000000032, 0x0000000106675000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace CODESIGNING, Code 0x2 kernel messages: VM Regions Near 0x106675000: VM_ALLOCATE (reserved) 106671000-106675000 [ 16K] r--/r-- SM=NUL reserved VM address space (unallocated) --> mapped file 106675000-107ff9000 [ 25.5M] r-x/rwx SM=COW Object_id=695dd8f1 mapped file 107ff9000-107ffd000 [ 16K] r-x/r-x SM=COW Object_id=6aaf57f1 Thread 0 Crashed: 0 runtime 0x00007ffdffe9ac40 0x7ffdffe96000 + 19520 1 runtime 0x00007ffdffea3df4 0x7ffdffe96000 + 56820 2 runtime 0x00007ffdffea35ec 0x7ffdffe96000 + 54764 3 runtime 0x00007ffdffe9a440 0x7ffdffe96000 + 17472 4 dyld 0x000000020683f000 0x20683f000 + 0 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x0000000106675000 x1: 0x000000030d81b730 x2: 0x0000000000000218 x3: 0x0000000000000012 x4: 0x0000000000000004 x5: 0x0000000001984000 x6: 0x0000000000000000 x7: 0x0000000000000a40 x8: 0x0000000000000007 x9: 0x0000000000000012 x10: 0x0000000106675fff x11: 0x0000000100000000 x12: 0x0000000000000000 x13: 0x0000000000000000 x14: 0x0000000000000000 x15: 0x000007d900018601 x16: 0x00000000000000c5 x17: 0x000000000220bef3 x18: 0x000000030d81b073 x19: 0x000000030d81b730 x20: 0x000000030d81aa78 x21: 0x0000000106675000 x22: 0x0000000000000004 x23: 0x0000000106675000 x24: 0x0000000000000003 x25: 0x0000000000000001 x26: 0x000000030d81ab90 x27: 0x000000020683f000 x28: 0x000000030d823960 fp: 0x000000030d81aa20 lr: 0x00007ffdffea267c sp: 0x000000030d81a9b0 pc: 0x00007ffdffe9ac40 cpsr: 0x20000000 far: 0x0000000106675000 esr: 0x92000006 Binary Images: 0x20683f000 - 0x2068dafff dyld (852.2) <57DB2053-BFD5-3683-97C6-F1DB2A1F1D09> /usr/lib/dyld 0x7ffdffe96000 - 0x7ffdffec5fff runtime (203.58) <52A2E5D0-FAA3-34EF-8BB7-07F73718C034> /usr/libexec/rosetta/runtime External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 0 thread_create: 0 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=1048K resident=0K(0%) swapped_out_or_unallocated=1048K(100%) Writable regions: Total=19.8M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=19.8M(100%) VIRTUAL REGION REGION TYPE SIZE COUNT (non-coalesced) =========== ======= ======= STACK GUARD 56.0M 1 Stack 8176K 1 VM_ALLOCATE 10.5M 1 VM_ALLOCATE (reserved) 1132K 3 reserved VM address space (unallocated) __DATA 288K 4 __DATA_CONST 32K 1 __LINKEDIT 272K 4 __TEXT 816K 2 mapped file 4.8G 11 =========== ======= ======= TOTAL 4.9G 28 TOTAL, minus reserved VM space 4.9G 28 Any help or guidance is much appreciated. I cannot say for sure this is an Apple issue, as I have no way to reproduce it reliably, either in our app or another. But it seems doubtful it's a bug in our app. Thank you!

I have an app not made in Xcode, which I notarize. I have no problem notarizing it in a Catalina VM I run with Xcode 11.4 but on my BigSur MacBook Pro with Xcode 12.5.1 (the latest) I cannot code sign. I get the message "resource fork and finder info and similar detritus not allowed". I get this even if I do Xattrib -cr first to clear it all. Code signing my app takes a few code signing commands. The first few go OK but then on the next couple it immediately says that error message as if the first ones inserted more detritus. I cannot finish code signing. First I do this: xattr -cr "/Users/richard/Desktop/Deploying/Jyotish Studio 5/Jyotish Studio 7.1.app" Then I do this: codesign -f --deep -o runtime --entitlements /Users/richard/Desktop/Deploying/standard_entitlements.plist --timestamp --verbose -s "Developer ID Application: Das Goravani (K6ZXXXXRU)" /Users/richard/Desktop/Deploying/Jyotish\ Studio\ 5/Jyotish\ Studio\ 7.1.app that one above signs everything, and it seems to insert some detritus because when I issue the next one to seal up the app it gives the error now, but note it does not give the error using the exact same commands in 11.4 on Catalina. Here's the command that gives the error after doing the above: codesign -f -o runtime --entitlements /Users/richard/Desktop/Deploying/standard_entitlements.plist --timestamp --verbose -s "Developer ID Application: Das Goravani (K6XXXXXRU)" /Users/richard/Desktop/Deploying/Jyotish\ Studio\ 5/Jyotish\ Studio\ 7.1.app Why do the exact same commands work on 11.4 Xcode and Catalina on a Virtual machine I run and not on BigSur with Xcode 12.5.1? I cannot now notarize if I use only my main Mac main OS which is BigSur.. can't notarize. I have to run the VM, I have to keep it around, which takes up a lot of drive space, just for notarizing, which bugs me. Note that I AM doing the xattrib -cr command first to clear all finder info etc.. but somehow it comes back due to signing the app. I also downloaded and tried an app for cleaning detritus from the app, it's called Clean Detritus.. I tried that, ran it, and got the same problem anyway. Please help.

I'm trying to migrate the scripts that build my application from an Intel Mac running Mojave (Xcode 10.3) to an M1 Mac running Big Sur (Xcode 12.5.1). On the M1 Mac, codesign triggers a pop up a window asking for an admin username/password each time it signs something. This happens whether it is invoked via a script or directly in Terminal. The pop-up appears twice when signing a Universal binary, once when signing a single-architecture binary. The popup says: macOS wants to make changes. Enter an adminstrator's name and password to allow this. macOS wants to use the "System" keychain. and it has a "Deny" button and an "Allow" button, but not an "Always Allow" button. (Another issue: the username is not pre-populated, even though I am logged in as an admin.) My "Developer ID Application" certificate is stored in my login keychain, as is the "Apple Worldwide Developer Relations Certification Authority" certificate, which expires 2030-02-19. The "System" keychain contains an "Apple Application Integration Certification Authority" certificate expiring 2026-10-20. (Another issue: that certificate can't be deleted!) Suggestions?

I'm trying to profile app launch of an iOS app running on an M1 Mac. After downloading a Mac compatible app from the iOS App Store (Airbnb) I'm able to select it in instruments by selecting the .app in /Applications This allows me to launch the app and profile it by pressing the record button Now I want to do this in an automated way with xctrace so I ran : xcrun xctrace record --template 'App Launch' --device CE3D229D-A2BF-5455-8923-5D49498F06DC --launch -- '/Applications/Airbnb.app' Using the id of my Mac returned from xcrun xctrace list devices. This attempts to launch the app but it immediately crashes with an error about an invalid code signature: If I try the same process with a MacOS app like Twitter, instead of an iOS app running on Mac, I'm able to launch it with xctrace. I'm also able to attach to Airbnb using the --attach PID option, but this doesn't help for testing app launch. I also tried launching the internal iOS .app using: xcrun xctrace record --template 'App Launch' --device CE3D229D-A2BF-5455-8923-5D49498F06DC --launch -- '/Applications/Airbnb.app/Wrapper/Airbnb.app' but got the same crash. How can I use the command line to launch an iOS app for profiling instruments? This is using Xcode 12.5.1 on macOS 11.5.2

je me demande comment résoudre se problème

Xcode: 12.5.1 macOS: 11.5.2 I have an app I'm building in Xcode that has several dependencies (Cocoapods). After adding one framework in particular (Wikitude AR framework), my build succeeds but I can no longer install the app on my device (iPhone 11, 14.7.1). The install fails with the following error: Unable to install "my-cool-app" Domain: com.apple.dt.MobileDeviceErrorDomain Code: -402620388 -- No code signature found. Domain: com.apple.dt.MobileDeviceErrorDomain Code: -402620388 User Info: { DVTRadarComponentKey = 261622; MobileDeviceErrorCode = "(0xE800801C)"; "com.apple.dtdevicekit.stacktrace" = ( 0 DTDeviceKitBase 0x00000001246963b8 DTDKCreateNSErrorFromAMDErrorCode + 220 1 DTDeviceKitBase 0x00000001246d4ae1 __90-[DTDKMobileDeviceToken installApplicationBundleAtPath:withOptions:andError:withCallback:]_block_invoke + 155 2 DVTFoundation 0x0000000108ef2bac DVTInvokeWithStrongOwnership + 71 3 DTDeviceKitBase 0x00000001246d4822 -[DTDKMobileDeviceToken installApplicationBundleAtPath:withOptions:andError:withCallback:] + 1440 4 IDEiOSSupportCore 0x000000011867d999 __118-[DVTiOSDevice(DVTiPhoneApplicationInstallation) processAppInstallSet:appUninstallSet:installOptions:completionBlock:]_block_invoke.294 + 3534 5 DVTFoundation 0x0000000109025921 __DVT_CALLING_CLIENT_BLOCK__ + 7 6 DVTFoundation 0x000000010902754b __DVTDispatchAsync_block_invoke + 1191 7 libdispatch.dylib 0x00007fff20165623 _dispatch_call_block_and_release + 12 8 libdispatch.dylib 0x00007fff20166806 _dispatch_client_callout + 8 9 libdispatch.dylib 0x00007fff2016c5ea _dispatch_lane_serial_drain + 606 10 libdispatch.dylib 0x00007fff2016d0ad _dispatch_lane_invoke + 366 11 libdispatch.dylib 0x00007fff20176c0d _dispatch_workloop_worker_thread + 811 12 libsystem_pthread.dylib 0x00007fff2030d45d _pthread_wqthread + 314 13 libsystem_pthread.dylib 0x00007fff2030c42f start_wqthread + 15 ); } -- System Information macOS Version 11.5.2 (Build 20G95) Xcode 12.5.1 (18212) (Build 12E507) Timestamp: 2021-08-16T14:42:04-04:00 I assume that this means the framework needs to be signed somehow. However, if I add the framework to "Frameworks, Libraries, and Embedded Content", the build immediately fails with the following error: Multiple commands produce 'my-cool-app/ios/Build/Products/Debug-iphoneos/my-cool-app.app/Frameworks/WikitudeSDK.framework': 1) Target 'my-cool-app' has copy command from 'my-cool-app/node_modules/react-native-wikitude-sdk/ios/WikitudeSDK.framework' to 'my-cool-app/ios/Build/Products/Debug-iphoneos/my-cool-app.app/Frameworks/WikitudeSDK.framework' 2) That command depends on command in Target 'my-cool-app': script phase “[CP] Embed Pods Frameworks” How can I install and run my application on my device? I've tried about 100 different solutions from SO and other sources -- none have made a difference. Any help is appreciated.

I have had a developer account that had expired a year a ago, I am trying to test an application via sideloading into my iPhone, every time I try to side- load I get an email from apple like so; ,  You have revoked your certificate, so it is no longer valid. Certificate: Development Team Name: Taiseer Ashouri  Any provisioning profiles that include this certificate are no longer valid and must be regenerated for future use.  Best regards,  Apple Developer Program Support I have asked apple to delete my developer account, they say the did,,,, Any help

I have a framework in my project that is composed of a main framework binary, with a number of dylibs that it depends on bundled with it: MyFramework.framework/ Versions/ A/ Frameworks/ foo.dylib bar.dylib Resources/ ... MyFramework _CodeSignature/ ... It is signed to run locally before being bundled into my main app project. Unfortunately, when embedding and signing the framework into my app, codesign is skipping re-signing the dylibs, which causes my hardened app to reject them from being loaded. Am I doing something wrong, or is this a bug?

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