I'm trying to download a profile for a developer download for an app, but I get this error and can't install the profile. I've already registered the device and UDID and added it to the profile. Please let me know what I need to do.

i was complete my program, and export a mac app already it work ok in my macmini, but if i want send it to app store, that i have no way now i still do not know how to make this app perfect like, when i use pyinstaller to build this app, is there any info or elements need make with? i can sign my app now, even i use codesign -dvvv my.app to check the sign, it is also ok, there no any feedback said it anything wrong. so, any master know fix app sign or any infoplist please tech me... help

The product archive package's signature is invalid. Ensure that it is signed with your "3rd Party Mac Developer Installer" certificate. (90237) I'm receiving this error, despite the fact that I'm using this certificate when creating the pkg (with electron-forge) My configuration is shown below - note the 3rd Party Mac Developer Installer identity when using new MakerPKG. const config: ForgeConfig = { packagerConfig: { asar: true, name: 'Deep Focus', icon: 'resources/icon.icns', osxSign: { identity: 'Apple Distribution: Timeo Williams (3Y4F3KTSJA)', type: 'distribution', provisioningProfile: '/Users/timeo/Desktop/Deep Focus/deepWork/distribution.provisionprofile', preAutoEntitlements: false, // eslint-disable-next-line @typescript-eslint/explicit-function-return-type optionsForFile() { return { entitlements: 'build/entitlements.mas.plist' } } }, extendInfo: 'build/info.plist', osxUniversal: { mergeASARs: true }, appCategoryType: 'public.app-category.productivity', appBundleId: 'com.electron.deepfocus', extraResource: [ 'resources/.env', 'resources/icon.icns', ] }, rebuildConfig: {}, makers: [ new MakerSquirrel({}), new MakerZIP({}), new MakerRpm({}), new MakerDeb({}), new MakerDMG({ appPath: './out/Deep Focus-darwin-arm64/Deep Focus.app', name: 'Deep Focus', icon: './resources/icon.icns', format: 'ULFO', overwrite: true, contents: (opts) => [ { x: 130, y: 220, type: 'file', path: opts.appPath }, { x: 410, y: 220, type: 'link', path: '/Applications' } ] }), new MakerPKG({ name: 'Deep Focus', identity: '3rd Party Mac Developer Installer: Timeo Williams (3Y4F3KTSJA)' }) ], plugins: [ new VitePlugin({ build: [ { entry: 'src/main.ts', config: 'vite.main.config.ts', target: 'main' }, { entry: 'src/preload.ts', config: 'vite.preload.config.ts', target: 'preload' } ], renderer: [ { name: 'main_window', config: 'vite.renderer.config.mts' // Path to Vite config for renderer process } ] }), new FusesPlugin({ version: FuseVersion.V1, [FuseV1Options.RunAsNode]: false, [FuseV1Options.EnableCookieEncryption]: true, [FuseV1Options.EnableNodeOptionsEnvironmentVariable]: false, [FuseV1Options.EnableNodeCliInspectArguments]: false, [FuseV1Options.EnableEmbeddedAsarIntegrityValidation]: true, [FuseV1Options.OnlyLoadAppFromAsar]: true }) ] } Yet, I'm getting the error from Transporter that it's invalid?

Hi, we have received an Application via App Transfer recently. I am now trying to generate a provisioning profile for App Store distribution. When we set the checkmark in Capabilities to use "iCloud Key-value storage" we cannot get "automatically manage signing" to work with an error: Provisioning profile "iOS Team Provisioning Profile: com.some.bundle.identifier" doesn't match the entitlements file's value for the com.apple.developer.ubiquity-kvstore-identifier entitlement. When a Provisioning Profile is manually generated via Developer Portal the com.apple.developer.ubiquity-kvstore-identifier entry shows the value of the previous app owner: "OLDTEAM.com.some.bundle.identifier". How can we change the com.apple.developer.ubiquity-kvstore-identifier value in our provisioning profile to get rid of the old team identifier? Help is much appreciated, thank you. FB15898983

Hello, Recently our team requested the "Notification (NSE) filtering" capability. Our request was rejected but we sent a new request with a more detailed explanation of our need. However if we go check the status of the request in the Capability Requests tab the status is "No requests". We sent the new request yesterday. Is it even possible to request a capability after a rejected request? We really need the capability and the absence of it is blocking our progress.

Xcode 16.2 無法在IOS 18.2 Debug Xcode 16.2 iOS 18.2 直接建立新專案 Xcode -> Create New Project -> Multiplatform -> Application -> App 選擇 實體手機 -> 執行 error: attach by pid '1050' failed -- attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.) Logging Error: Failed to initialize logging system due to time out. Log messages may be missing. If this issue persists, try setting IDEPreferLogStreaming=YES in the active scheme actions environment variables.

I need to get the distribution certificate SHA-1 and public key in order to apply an official filing, but the certificate in deveoper account page is not downloadble. could someone help me on this? how to download certicate or to get SHA-1 and pubkey of the cert? thanks.

I would like to code sign an app or installer with an RSA 4096-bit code signing certificate. I created a CSR using RSA4096bit and ECC in Mac Keychain Access, but I was unable to use that CSR to create a code signing certificate on the Apple Developer site. How do I issue an RSA4096-bit or ECC code signing certificate?

I'm trying to add keychain-access-groups capability to my app for MacOs devices and I'm getting an error while signing the code. If I add this capability to an app for iOS devices, this does not happen and it works correctly. Are there any limitations to using this capability on MacOS devices? My entitlement file is the following: <?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.application-groups</key> <array> <string>group.com.cqesolutions</string> </array> <key>com.apple.security.files.user-selected.read-only</key> <true/> <key>com.apple.security.smartcard</key> <true/> <key>keychain-access-groups</key> <array> <string>$(AppIdentifierPrefix)com.cqesolutions.desktopDNIe</string> <!--<string>$(AppIdentifierPrefix)com.apple.token</string>--> <string>com.apple.token</string> </array> </dict> </plist>

I am reaching out regarding a persistent issue I have been facing with code signing. Despite extensive troubleshooting, I am unable to resolve the problem, and I would greatly appreciate your assistance. When attempting to sign my electron application with codesign with the following command: codesign --keychain ~/Library/Keychains/login.keychain --sign “Developer ID Application: MYNAME (DEV-ID)” --force --timestamp --options runtime --verbose=4 dist/mac-arm64/my.app I receive the following error message: “Warning: unable to build chain to self-signed root for signer ‘Developer ID Application: MYNAME (DEV-ID)‘“. This prevents me from successfully completing the code signing and notarization process. To resolve this, I have meticulously tried to troubleshoot the problem. Here are the steps taken so far: Imported Certificates into Keychains: I imported all necessary certificates (including Developer ID Application, Developer ID Certification Authority, Apple Root CA and Apple Root CA - G2) into the keychain. I tested with both the System and Login keychains (one at a time to avoid errors due to duplicates) Checked Trust Settings: I confirmed that the trust settings for the certificates are properly configured to “Always Trust.” I verified the private key is present in Keychain Access and is properly linked to the public certificate. Ensured valid identity: I ensured that the correct Developer ID identity is valid and the associated private key is available (security find-identity -v -p codesigning and security find-key -t private | grep “MY NAME”) Ensured keychain access permissions: I ensured that the respective keychain has access permissions (security set-key-partition-list -S apple-tool:,apple: -s -k ~/Library/Keychains/login.keychain) Verified matching Issuer and Subject to build certificate chain: I verified that the Issuer and Subject fields in the certificates show the correct references to build the certificate chain. Deleted and Re-imported Certificates: I deleted and re-imported the certificates multiple times to ensure there were no import issues or corruption in the certificates. Tested simplified setup: I attempted to sign simple files, such as a plain .txt file, using the Developer ID Application certificate I also attempted signing with minimal flags to rule out any issues with the app structure or build configuration Updated Xcode Command Line Tools One potential factor is that I am signing the application on a different machine from the one where the certificates were originally generated. I included the private key when exporting the certificate as a .p12 file from the original computer and imported it into the second computer’s keychain. This second computer is not connected to iCloud, and I suspect this could potentially affect the signing process. Despite all these efforts, the issue persists, and I am unable to identify the root cause. I would greatly appreciate your guidance on resolving this matter so I can successfully complete the code signing and notarization process. Thank you for your time and support.

I am developing and distributing an XCFramework, and I want to ensure that it remains valid for as long as possible. I have some questions regarding certificate expiration and revocation: I understand that if an XCFramework is signed with a timestamp, it remains valid even after the signing certificate expires. However, if the signing certificate is revoked, the XCFramework immediately becomes unusable. As far as I know, Apple allows a maximum of two active distribution certificates at the same time. I assume that once a certificate expires, it will eventually need to be revoked in order to issue a third certificate. Is this correct? If an expired certificate is later revoked, will the XCFrameworks signed with that certificate also become invalid, even though they were timestamped? I want to ensure that released XCFrameworks remain valid for as long as possible. What is the best approach to achieve this? If anyone has insights or official documentation references on how to manage signing certificates for long-term XCFramework validity, I would appreciate your guidance. Thank you!

We've been trying to get the CarPlay Navigation Entitlement for a couple years now without much luck. Did you have a similar experience? How did you succeed getting the entitlement? Part of the form requires us to submit Screenshots. Did you provide screenshots of your on-device experience or wireframe for CarPlay? How was your experience?

When I submit my app for notarization, it takes more than 24 hours but still shows "In progress". Does anyone else experience the same issue? Here is the history records: Successfully received submission history. history -------------------------------------------------- createdDate: 2024-12-22T07:32:20.998Z id: 81f36df5-21a2-4101-a264-9ac62e7b85a5 name: Gatsbi.zip status: In Progress -------------------------------------------------- createdDate: 2024-12-22T04:00:29.496Z id: 6d99632c-7aef-4e46-bdef-d70845cd39b5 name: Gatsbi.zip status: In Progress -------------------------------------------------- createdDate: 2024-12-21T10:54:48.433Z id: 1fdcd6c6-d707-4521-9b4d-4a5f3e03959a name: Gatsbi.zip status: In Progress -------------------------------------------------- createdDate: 2024-12-21T10:05:02.700Z id: 4237e15e-00e3-4884-9bdd-f7f900af2dc1 name: Gatsbi.zip status: In Progress -------------------------------------------------- createdDate: 2024-12-21T08:40:19.404Z id: 102039b9-4a16-4fbb-8371-f9b6cb0e1a80 name: Gatsbi.zip status: In Progress -------------------------------------------------- createdDate: 2024-12-21T07:31:01.588Z id: b6f82941-1ac2-4f5d-99ed-c44141934a0d name: Gatsbi.zip status: Accepted

I regularly see questions from folks who’ve run into code-signing problems with their third-party IDE. There’s a limit to how much I can help you with such problems. This post explains a simple test you can run to determine what side of that limit you’re on. If you have any questions or comments, please put them in a new thread here on DevForums. Put it in Code Signing > General topic area and apply whatever tags make sense for your specific situation. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Investigating Third-Party IDE Code-Signing Problems DTS doesn’t support third-party tools. If you’re using third-party tooling and encounter a code-signing problem, run this test to determine whether you should seek help from Apple or from your tool’s vendor. IMPORTANT Some third-party tools create Xcode projects that you then build and run in Xcode. While that approach is understandable, it’s not something that DTS supports. So, the steps below make sense even if you’re already using Xcode. To check that code-signing is working in general: Launch Xcode. In Xcode > Settings > Accounts, make sure you’re signed in with your developer account. Create a new project from the app project template for your target platform. For example, if you’re targeting iOS, use the iOS > App project template. When creating the project: Select the appropriate team in the Team popup. Choose a bundle ID that’s not the same as your main app’s bundle ID. Choose whatever language and interface you want. Your language and interface choices are irrelevant to code signing. Choose None for your testing system and storage model. This simplifies your project setup. In the Signing & Capabilities editor, make sure that: "Automatically manage signing” is checked. The Team popup and Bundle Identifier fields match the value you chose in the previous step. Select a simulator as the run destination. Choose Product > Build. This should always work because the simulator doesn’t use code signing [1]. However, doing this step is important because it confirms that your project is working general. Select your target device as the run destination. Choose Product > Build. Then Product > Run. If you continue to have problems, that’s something that Apple folks can help you with. If this works, there’s a second diagnostic test: Repeat steps 1 through 10 above, except this time, in step 4, choose a bundle ID that is the same as your main app’s bundle ID. If this works then your issue is not on the Apple side of the fence, and you should escalate it via the support channel for the third-party tools you’re using. On the other hand, if this fails, that’s something we can help you with. I recommend that you first try to fix the issue yourself. For links to relevant resources, see Code Signing Resources. You should also search the forums, because we’ve helped a lot of folks with a lot of code-signing issues over the years. If you’re unable to resolve the issue yourself, feel free to start a thread here in the forums. Put it in Code Signing > General topic area and apply whatever tags make sense for your specific situation.

I have 14 total devices, from way back. I am currently in a financial bind and can't renew just yet. BUT I am at past my time to reset the device list back to zero. But the screen to do that is behind the paid account. Catch 22 Can we fix it? As it stands I must email tech support, but this is a bug so I posted

You can now easily request access to managed capabilities for your App IDs directly from the new Capability Requests tab in Certificates, Identifiers & Profiles > Identifiers. With this update, view available capabilities in one convenient location, check the status of your requested capabilities, and see any notes from Apple related to your requests. Learn more about capability requests.

Starting Point I recently transferred an app from an old to a new developer account. The transfer itself went smoothly with the app using the following capabilities: CoreData, CloudKit, Push Notifications, In-App Purchases Keychain is not used After completing the app transfer, I worked on a new update. For this, I set the new developer account as the development team of the project in Xcode. However, as soon as I try to install the new version locally on my physical test device, I get the following error message: application-identifier entitlement string ({new_team_id}.{bundle_id}) does not match installed application's application-identifier string ({old_team_id}.{bundle_id}); rejecting upgrade.` (Note: The test device has the latest production version installed, which was still published by the old developer account. The update can be installed without any problems if no previous version is installed. {new_team_id}, {old_team_id} and {bundle_id} are a substitute for the original content.) What I've tried so far I found a Technical Note on this topic and followed the steps suggested. However, the Apple Support wasn't able to provide me with the required Special Provisioning Profile. That's why I tested a different approach with a dummy application: I have completed an update as described above (new developer account selected as development team). Next, I uploaded it to App Store Connect and published it as a new version. I received the following warning during the upload process, but ignored it since I don't use the keychain: At first glance, the publication process appears to have gone smoothly. While the update caused the above error during local testing, the update via the App Store went smoothly. As the latest production version has now also been published from the new Apple Developer Account, further updates can now also be tested locally on a physical device without any problems. Questions Why is it that the update causes an error when tested locally, but works without problems via the App Store? Can this approach also be used without concern for an app with a large active user base, which also uses the capabilities described above (in particular CoreData & CloudKit) without causing problems? Thanks a lot for your support in advance!

To ship a product outside of the Mac App Store, you must notarise it. The notary service issues a notarised ticket, and the ultimate consumer of that ticket is Gatekeeper. However, Gatekeeper does not just check the ticket; it also applies a variety of other checks, and it’s possible for those checks to fail even if your notarised ticket is just fine. To avoid such problems showing up in the field, test your product’s compatibility with Gatekeeper before shipping it. To do this: Set up a fresh machine, one that’s never seen your product before. If your product supports macOS 10.15.x, x < 4, the best OS version to test with is 10.15.3 [1]. Download your product in a way that quarantines it (for example, using Safari). Disconnect the machine from the network. It might make sense to skip this step. See the discussion below. Install and use your product as your users would. If the product is signed, notarised, and stapled correctly, everything should work. If not, you’ll need to investigate what’s making Gatekeeper unhappy, fix that, and then retest. For detailed advice on that topic, see Resolving Trusted Execution Problems. Run this test on a fresh machine each time. This is necessary because Gatekeeper caches information about your product and it’s not easy to reset that cache. Your best option is to do this testing on a virtual machine (VM). Take a snapshot of the VM before the first test, and then restore to that snapshot when you want to retest. Also, by using a VM you can disable networking in step 3 without disrupting other work on your machine. The reason why you should disable networking in step 3 is to test that you’ve correctly stapled the notarised ticket on to your product. If, for some reason, you’re unable to do that stapling, it’s fine to skip step 3. However, be aware that this may cause problems for a user if they try to deploy your product to a Mac that does not have access to the wider Internet. For more background on this, see The Pros and Cons of Stapling. [1] macOS 10.15.4 fixes a bug that made Gatekeeper unnecessarily strict (r. 57278824), so by testing on 10.15.3 you’re exercising the worst case. The process described above is by far the best way to test your Gatekeeper compatibility because it accurately tests how your users run your product. However, you can also run a quick, albeit less accurate test, using various command-line tools. The exact process depends on the type of product you’re trying to check: App — Run syspolicy_check like this: % syspolicy_check distribution WaffleVarnish.app This tool was introduced in macOS 14. On older systems, use the older spctl tool. Run it like this: % spctl -a -t exec -vvv WaffleVarnish.app Be aware, however, that this check is much less accurate. Disk image — Run spctl like this: % spctl -a -t open -vvv --context context:primary-signature WaffleVarnish.dmg Installer package — Run spctl like this: % spctl -a -t install -vvv WaffleVarnish.pkg Other code — Run codesign like this: % codesign -vvvv -R="notarized" --check-notarization WaffleVarnish.bundle This command requires macOS 10.15 or later. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2024-12-05 Added instructions for using syspolicy_check. Made other minor editorial changes. 2023-10-20 Added links to Resolving Trusted Execution Problems and The Pros and Cons of Stapling. Made other minor editorial changes. 2021-02-26 Fixed the formatting. 2020-04-17 Added the section discussing spctl. 2020-03-25 First version.

Title: Apple's Outdated and Restrictive Certificate Signing Process: A Barrier to Innovation Introduction In the dynamic field of mobile app development, the agility and freedom offered to developers can significantly dictate the pace of innovation and user satisfaction. Apple's certificate signing process, a legacy from an earlier era of computing, starkly contrasts with more modern approaches, particularly Android's Keystore system. This article delves into the cumbersome nature of Apple's approach, arguing that its outdated and proprietary methods hinder the development process and stifle innovation. The Burdensome Nature of Apple's Certificate Signing Proprietary Restrictions: Apple's certificate signing is not just a process; it's a gatekeeper. By forcing developers to go through its own system to obtain certificates, Apple maintains a tight grip on what gets published and updated. This closed ecosystem approach reflects a dated philosophy in an age where flexibility and openness are key drivers of technological advancement. Complex and Time-Consuming: The process to acquire and maintain a valid certificate for app signing is notoriously intricate and bureaucratic. Developers must navigate a maze of procedures including certificate requests, renewals, and provisioning profiles. Each step is a potential roadblock, delaying urgent updates and bug fixes, which can be crucial for user retention and satisfaction. Lack of Autonomy: Apple's centralized control means every application must be signed under the stringent watch of its guidelines. This lack of autonomy not only slows down the release cycle but also curbs developers' creative processes, as they must often compromise on innovative features to meet Apple's strict approval standards. Comparing Android’s Keystore System Developer-Friendly: In stark contrast, Android’s Keystore system empowers developers by allowing them to manage their cryptographic keys independently. This system supports a more intuitive setup where keys can be generated and stored within the Android environment, bypassing the need for any external approval. Speed and Flexibility: Android developers can use the same key across multiple applications and decide their expiration terms, which can be set to never expire. This flexibility facilitates a quicker development process, enabling developers to push updates and new features with minimal delay. The Impact on the Developer Ecosystem Innovation Stifling: Apple's outdated certificate signing process does not just affect the technical side of app development but also impacts the broader ecosystem. It places unnecessary hurdles in front of developers, particularly small developers who may lack the resources to frequently manage certificate renewals and navigate Apple’s rigorous approval process. Market Response: The market has shown a preference for platforms that offer more freedom and less bureaucratic interference. Android's growing market share in many regions can be partially attributed to its more developer-friendly environment, which directly contrasts with Apple's tightly controlled ecosystem. Conclusion Apple’s certificate signing method, while ensuring a secure environment, is an archaic relic in today’s fast-paced tech world. It binds developers with outdated, proprietary chains that hinder rapid development and innovation. As the technological landscape evolves towards more open and flexible systems, Apple’s restrictive practices could potentially alienate developers and erode its competitive edge. For Apple to maintain its relevance and appeal among the developer community, a significant overhaul of its certificate signing process is not just beneficial—it's necessary.

Even if I recreate everything and register it, it does not register in xcode as shown below. No matter how many times I regenerate the certificate and profile, the same thing happens.