Overview

Hello, I’m encountering a persistent code-signing verification failure when installing a development build on a registered physical iPhone. The project builds and signs successfully in Xcode, and the .app is transferred to the device. However, the installation fails when installd verifies the app’s signature. The relevant error is: Failed to verify code signature of Runner.app: 0xe8008018 The identity used to sign the executable is no longer valid. Domain: MIInstallerErrorDomain Code: 13 LegacyErrorString: ApplicationVerificationFailed Domain: IXUserPresentableErrorDomain Code: 14 Failure Reason: The app cannot be installed because its integrity could not be verified. Environment macOS: 26.6.2 (25G83) Xcode: 27.0 (27A266a) iOS: 26.6.2 (23G90) Device: iPhone15,4 Architecture: arm64 Installation method: Xcode Run on a registered physical device Signing type: Apple Development Provisioning: Development provisioning profile Important account history Our Apple Developer Program account was previously suspended and was later reinstated by Apple. Apple Developer Support has checked the account and stated that the membership account currently appears normal. However, development builds signed by this Team are still rejected by the device with 0xe8008018. This makes us suspect that the membership itself was restored, but some signing-related backend state may not have been fully restored or propagated, such as: Development certificate trust or revocation state Registered-device installation authorization Provisioning-profile validity A restriction or risk flag associated with the previous suspension Synchronization between the Developer account system and Apple’s device-side certificate trust services What I have verified The Apple Developer Program membership is active. The physical iPhone is registered with the Developer Team. The Bundle ID matches the provisioning profile. The build uses an Apple Development certificate and a development provisioning profile. The application builds successfully. Xcode completes the signing phase successfully. The resulting app contains an embedded provisioning profile. The app is successfully transferred to the device. The failure occurs during device-side signature verification, not during compilation or transfer. Cleaning and rebuilding the project produces the same result. The original missing-product-path issue has been resolved; Xcode is now installing the correct Runner.app. I have also reviewed Apple’s certificate documentation and discussions involving the same 0xe8008018 error. Some developers report that the same device accepts an app signed with another Apple ID or Team while rejecting builds signed by the affected paid Developer Team. I also found reports involving Sideloadly where forcing a different installation mode once and then returning to Apple ID signing caused the signing flow to recover. That exact workaround is not applicable here because this is a normal Xcode development build, not third-party IPA sideloading. However, it suggests that refreshing signing state on Apple’s side may affect the result. Questions Can a Developer Program membership appear active while the Team’s development certificates are still treated as revoked or invalid by device-side trust services? After a previously suspended account is reinstated, is there a separate process for restoring or resynchronizing development-signing privileges? Is there a way to determine whether this Team still has a backend restriction or stale certificate-revocation state? Has anyone resolved this without switching to a different Apple ID or Developer Team? What diagnostic files would be most useful for confirming whether this is a Team-level backend issue? Apple Developer Support case reference: 102975363424. I can provide an .xcresult, signed IPA, embedded provisioning profile, certificate details, and complete installation logs privately if requested. Thank you.

Hi, Safari shows a “Deceptive Website” warning for https://mim-kulinariya.com/. It’s a simple café menu with prices and contact details. No login, payments, personal data collection forms or tracking scripts. It’s hosted on GitHub Pages with a valid Let’s Encrypt certificate. I submitted a review request through websitereview.apple.com but have received no response at all. The warning discourages customers from visiting our website. Could someone from Apple please help expedite the review or explain how to escalate this? If a specific page or resource triggered the warning, please let us know so we can address it promptly. Thank you.

Hi, I'm currently in the process of updating my app, which only supports iPhone at the moment, and I'm wondering how I could update my onboarding flow to take advantage of the iPhone Duo when unfolded. Basically the onboarding is a succession of screens, all presented inside a NavigationStack one after the other. I had the idea of using all the screen area to show those screens 2 by 2 (side by side). At first I thought about using NavigationSplitView to accomplish this (pairs of them) but I couldn't get a 50/50 ratio and it felt more of a hack. I then turned my attention to ArrangementView using an horizontal split but in certain layouts only the primary is shown and I'm not sure how I can detect that to show the secondary on push. Would anybody know what the best way would be to accomplish this? Or is it not a good idea at all? Thanks!

Good day! I'm an individual developer in South Africa completing the EU Digital Services Act trader requirements (Business → Agreements → Compliance). The email verification code arrives every time. The phone verification code never arrives, by SMS or by call, on two different South African mobile numbers, both of which receive SMS normally from other senders. Tried Safari, Firefox private browsing and other browsers. I requested manual verification and opened support case 102972183599 on 22 September. I would like to launch in all regions at once, so this has to be done before I can launch. If this cannot be done online, I've heard of others providing a sworn affidavit signed by a Commissioner of Oaths confirming my name, address, email and phone number, plus proof of address. Could someone from Apple advise how to complete this manual verification, if needed?

Universal Clipboard from iPhone to Mac works after an iPhone restart, then silently stops after a while. Mac to iPhone and Mac to Mac keep working. Only restarting the iPhone fixes it; toggling Bluetooth or Handoff does not. What the Mac's unified log shows while broken (useractivityd + sharingd): Mac to Mac (working): Received Ad ... CopyPasteKey = 1, then [PBOARD] Received pboard available advertisement, then Requesting complete: 1713 bytes, error: (null). iPhone to Mac (broken): zero Received Ad and zero pboard advertisements from the iPhone, even while copying every few seconds with the phone next to the Mac. No errors. The Mac still recognises the iPhone as a paired own-account device (Paired yes, identity resolved, distance Immediate), so pairing and receiving are fine. So the iPhone appears to stop broadcasting Handoff advertisements entirely, and the stuck state survives Bluetooth and Handoff toggles.

Xcode / Claude Agent says "Approve the plan using the Exit Plan button when you're ready, and I'll start building." There is no Exit Plan button. How do I approve the plan?

My share extension accepts a shared location and I want to bring the user into the containing app at the corresponding map screen. I understandNSExtensionContext.open(_:completionHandler:) is restricted to Today widgets per the App Extension Programming Guide, and I observe it reporting success == false. The technique I am asking about is different: walking the extension's responder chain to obtain the UIApplication instance, then calling open(_:options:completionHandler:) on it. In a minimal sample this launches the containing app and the completion handler reports success == true, on both iOS 26 and iOS 27. What makes this worth asking rather than assuming: It never references UIApplication.shared, which is annotated NS_EXTENSION_UNAVAILABLE_IOS. open(_:options:completionHandler:) itself carries no extension-unavailable annotation in the SDK, so the call compiles cleanly even with APPLICATION_EXTENSION_API_ONLY = YES. I am aware of https://developer.apple.com/forums/thread/773342, where an Apple Frameworks Engineer wrote that "There's no supported way for you to launch your app directly from App Extensions, except Today and Widgets." That thread does not cover the responder chain specifically, which is why I am asking. My questions: a) Is this permitted? Is obtaining UIApplication via the responder chain from a Share Extension and calling open(_:options:completionHandler:) considered a violation of App Store Review Guideline 2.5.1 (public APIs used as intended), independent of whether it currently functions? b) If it is not permitted, what is the recommended way for a Share Extension to hand a location to its containing app such that the user arrives at the relevant screen? The code in question, in its entirety: @objc private func openUsingResponderChain() { var responder: UIResponder? = self while let currentResponder = responder { if let application = currentResponder as? UIApplication { application.open(targetURL, options: [:]) { [weak self] success in self?.report("UIApplication via responder chain -> success = \(success)") } return } responder = currentResponder.next } report("No UIApplication found in the responder chain") } Full sample project: https://github.com/valtermak-voya/share-extension-open-url-repro A containing app registering opensample:// plus a share extension target built with APPLICATION_EXTENSION_API_ONLY = YES. The method above is the whole of the extension's logic. Filed with DTS as Case-ID 22452440.

Through log analysis, I found that the SQLite files generated after signing in to Game Center are located in: ~/Library/Group Containers/group.com.apple.gamecenter/Library/Caches com.apple.deleted automatically cleans up cache files. This causes the following problem: after I have been signed in for some time, when I check Game Center again, I find that the profile name has changed to Unknown. When I launch Apple Arcade games, I am always asked to sign in to Game Center, and “Show Profile” also shows the same symptoms as described in this post: https://discussions.apple.com/thread/256053912 I believe they are caused by the same issue. I have to log out and then log back in to Game Center to temporarily resolve the problem, but once the cache is cleaned again, I have to repeat the same process. I also think that having less remaining free storage space may make system cache cleanup more likely to be triggered, although this is only my guess. https://www.reddit.com/r/macgaming/comments/1l0f8i4/the_avatar_and_name_in_game_center_are_displayed My system is macOS 15.7.9. I have already submitted a complete Feedback Report. FB ID: FB24975495

We handle App Store Server Notifications V2 for an auto-renewable subscription. When we receive REFUND for the current period, we revoke the customer's access. We now want to reinstate access on REFUND_REVERSED, as the documentation says: "If your app revoked content or services as a result of the related refund, it needs to reinstate them." Before reinstating, our server verifies the transaction in signedTransactionInfo and rejects it if revocationDate is present or expiresDate is in the past. We'd like to confirm a few behaviors so that the reinstatement doesn't get rejected by our own checks: In a REFUND_REVERSED notification, does the signedTransactionInfo still contain revocationDate (and revocationReason), or are they removed? Likewise, after the reversal, does Get Transaction Info / Get All Subscription Statuses return the transaction without revocationDate? An App Store Commerce Engineer explained in thread/757119 that when a customer requests a refund, the subscription's auto-renew status is set to false. Does this apply to every refund path (for example, refunds initiated by Apple or via chargebacks), or only to refunds requested by the customer? After REFUND_REVERSED, does the auto-renew status stay off, or can it be turned back on automatically? If it stays off, is the customer expected to re-enable auto-renew themselves? We have seen reports that REFUND_REVERSED can arrive weeks after REFUND, even when expiresDate has already passed. In that case, is it correct to reinstate access only up to the original expiresDate (i.e. nothing to reinstate if it has already passed)? Thank you.

We are designing a bounded local macOS operation with a supervisor, controller and helper. All three must be unable to cause prohibited network effects, including attributable delegated requests, before admission and until quiescence. Unrelated applications must retain their normal network access. We are seeking an API contract clarification, not reporting a reproduced OS bug. No NetworkExtension provider has been activated for this design. Our reviewed SDK is MacOSX27.0.sdk; its presence is not a runtime qualification. Please identify the supported macOS versions for your answer. The design must tolerate provider crash, termination, disconnection and unresponsiveness, and operation lease expiry/revocation. Administrative filter disablement or privileged reconfiguration is a separate unresolved threat-model case, not something we assume ordinary failure handling covers. We reviewed content-filter deployment in TN3134 and the nullable/delegated audit tokens in NEFilterFlow. We understand that NEURLFilterManager.shouldFailClosed concerns URL-filter decisions, not an established guarantee for arbitrary content-filter traffic. EndpointSecurity AUTH deadlines are also a separate mechanism. The VPN routing article documents dropping during specific transitions, but has system exceptions; TN3120 excludes using a packet tunnel as a dropping content filter. We therefore have not adopted that workaround. For macOS NEFilterDataProvider / NEFilterPacketProvider, is there a supported configuration that keeps prohibited operation traffic denied when the provider crashes, is killed, disconnects, hangs or cannot deliver a decision? Please distinguish new flows, existing/previously permitted flows, queued data, restart intervals, and configuration disable/removal. What supported admission and teardown guarantees allow releasing the first protected process only after enforcement is effective, then retaining denial through lease revocation and shutdown? An enabled configuration alone would not demonstrate that barrier. How should this guarantee cover operation-caused DNS and delegated system-service traffic, including absent/ambiguous audit tokens, without denying unrelated host traffic? If content filters cannot meet that scope, can App Sandbox without network entitlements provide the independent denial boundary for these roles, and what documented exclusions or additional constraints apply? A reference to the supported contract, or a precise statement of the requirement that needs to change, would let us select an architecture before implementing and activating a native provider. We are not requesting private APIs or an unsupported packet-tunnel filter.

Hi, we have a bug report in Cholesky implementation of Accelerate on the LAPACK GitHub. See: https://github.com/Reference-LAPACK/lapack/issues/1408 This is to let you know. This might be a user error but I thought I'd let you know. I did not try out for myself. Julien.

Summary The Apple Developer Forums profile lets me enable push notification preferences, but Safari is never asked for permission. The profile still says that this browser has not opted in to receive pushes, so I cannot receive forum push notifications in Safari. Environment macOS 26.7 and Safari 26.6.2 on a Mac mini. Signed in to Apple Developer Forums at https://developer.apple.com/forums/profile/preferences. In Safari → Settings → Websites → Notifications, Allow websites to ask for permission to send notifications is enabled. developer.apple.com does not appear in the site list. Content blockers are disabled for developer.apple.com. Steps to reproduce Open the Apple Developer Forums profile preferences in Safari while signed in. Under Receive push notifications when, enable There's a response to my post or reply. Click Save Profile. Return to the profile preferences and check the browser opt-in status. I also turned this preference off and on again. Neither that action nor saving the profile displayed a Safari permission prompt. Expected result The forum offers a way to request Safari's notification permission and subscribe this browser to push notifications. Once permission is granted, the profile should show that this browser is opted in. Actual result No Safari notification permission prompt appears. The push preference remains checked after saving, but the profile says: “You haven’t opted in to receive pushes from Apple Developer Forums on this browser.” developer.apple.com remains absent from Safari's Notifications website list. In Safari Web Inspector on the forum profile page, Notification.permission returns "default", and (await navigator.serviceWorker.ready).pushManager.getSubscription() returns null. A service worker registration is present for the forums. This indicates that the browser has neither made a permission decision nor acquired a push subscription. I have not identified why the forum's opt-in flow does not reach the browser permission request.

Hi, I’m reaching out to see if anyone or Apple themself might be able to provide some guidance regarding my app submission. It has been in “Waiting for Review” for quite some time, and I’m hoping there may be a way to have it reviewed soon. The app is part of my submission for an ongoing competition, and the deadline is approaching. Having the app reviewed and available on the App Store before the deadline is important for my submission. I completely understand that review times can vary, but given the upcoming deadline and how long the submission has been waiting, I wanted to ask if there’s anything I can do or anyone I can contact to help get the review completed sooner. I have contacted Apple Support through email and have not received any response. Any help or guidance would be greatly appreciated. Thank you!

On macOS 27.2 beta 1/2 our URL filter never starts: the session loops starting -> stopping. The same build works on macOS 27.0 (26A428). Both our TestFlight and notarized standalone builds fail. Prefilter and PIR registration succeed. The PIR status request then fails: NWPath is satisfied, the connection is configured proxy fail closed, proxy strict fail closed, the proxy fails (event: proxy:children_failed), and the error is NSURLErrorDomain -1009 / POSIX 50 "Network is down" with _NSURLErrorPrivacyProxyFailureKey=true. NEMembershipCheckerErrorDomain Code=3 -> NEAgentURLFilterErrorDomain Code=3; the app sees serverSetupIncomplete. The privacy-proxy allow-list entry is identical on macOS 27.0 and 27.2 beta (com.adguard). Disabling the VPN, rebooting, and recreating the URL filter configuration do not help. Log excerpt: neagent: updatePrefilterWithCompletionHandler - result 1 neagent: <NEPIRChecker> - Register with PIR Server (group <com.adguard.safari.AdGuard> ... PrivacyProxyFailOpen <0> ...) -> completed registration ciphermld: [C3 ...] proxy fail closed, proxy strict fail closed ciphermld: [C3.1.1 ... failed proxy (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, flow divert agg: 2, LQM: good)] event: proxy:children_failed ciphermld: queryStatus: NSURLErrorDomain -1009 / POSIX 50 "Network is down", _NSURLErrorPrivacyProxyFailureKey=true, NWPath=satisfied neagent: Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> nesessionmanager: NEURLFilterPlugin(com.adguard.safari.AdGuard[url-filter][inactive]): setStatus:error: - err Error Domain=NEAgentURLFilterErrorDomain Code=3 Filed as FB24933164.

Hi all, we are building a custom controller for ATDECC, which is a layer 2 protocol standardized by IEEE in 1722.1. Our controller can work on multiple network interfaces at the same time . It uses the interface's MAC address to identify, on which interface a certain AVB / ATDECC device was discovered. It then sends replies for this device only to this interface. This controller worked fine up to and including macOS 26, but when running the same code on macOS 27, we cannot get the MAC addresses for the local interfaces anymore, but we receive 02:00:00:00:00:00 for each of them. This seems to indicate that the MAC address was redacted (looks like the same MAC address, that is being returned since iOS 11 due to privacy reason). Is this a bug or is macOS going to redact the MAC addresses also in the final release? If MAC addresses are being redacted, would it help to request access to the new entitlement called com.apple.developer.networking.topology-observation? I attached a little code snippet, that returns actual MAC addresses on macOS 26, but redacted ones on macOS 27. Build with clang++ -std=c++23 -o ifprobe ifprobe.cpp and then run it with ./ifprobe. ifprobe.cpp

I regularly see folks run into problems with their Developer ID signing identities. Historically I pointed them to my posts on this thread, but I’ve decided to collect these ideas together in one place. If you have questions or comments, start a new thread here on DevForums and tag it with Developer ID so that I see it. IMPORTANT Nothing I write here on DevForums is considered official documentation. It’s just my personal ramblings based on hard-won experience. There is a bunch of official documentation that covers the topics I touch on here, including: Xcode documentation Xcode Help Developer Account Help Developer > Support > Certificates For a lot more information about code signing, see the Code Signing Resources pinned post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" The Care and Feeding of Developer ID Most Apple signing assets are replaceable. For example, if you accidentally lose access to your Apple Development signing identity, it’s a minor inconvenience. Just use the Developer website to revoke your previous certificate and create a replacement. Or have Xcode do that for you. IMPORTANT If you don’t understand the difference between a certificate and a digital identity, and hence signing identity, read Certificate Signing Requests Explained before reading this post. Some signing assets are precious. Losing access to such assets has significant consequences. Foremost amongst those are Developer ID signing identities. These allow you to sign Mac products that ship independently. Anyone with access to your Developer ID signing identity can sign code as you. This has a number of consequences, both for you and for your relationship with Apple. Identify a Developer ID Signing Identity A Developer ID signing identity consists of two parts: the certificate and the private key. There are two different flavours, identifiable by the subject name in the certificate: Developer ID Application — This is named Developer ID Application: TTT, where TTT identifies your team. Use this to sign code and disk images. Developer ID Installer — This is named Developer ID Installer: TTT, where TTT identifies your team. Use this to sign installer packages. Note If you do KEXT development, there’s a third flavour, namely a KEXT-enabled Developer ID Application signing identity. For more details, see KEXT Code Signing Problems. This post focuses on traditional signing identities, where you manage the private key. Xcode Cloud introduced cloud signing, where signing identities are “stored securely in the cloud”. These identities have the Managed suffix in Certificates, Identifiers, and Profiles. For example, Developer ID Application Managed is the cloud signing equivalent of Developer ID Application. To learn more about cloud signing, watch WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing. To identify these certificates ‘in the wild’, see Identifying a Cloud Managed Signing Certificate. Limit Access to Developer ID Anyone with your Developer ID signing identity can sign code as you. Given that, be careful to limit access to these signing identities. This is true both for large organisations and small developers. In a large organisation, ensure that only folks authorised to ship code on behalf of your organisation have access to your Developer ID signing identities. Most organisations have some sort of release process that they use to build, test, and authorise a release. This often involves a continuous integration (CI) system. Restrict CI access to only those folks involved in the release process. Even if you’re a small developer with no formal release process, you can still take steps to restrict access to Developer ID signing identities. See Don’t Leak Your Private Key, below. In all cases, don’t use your Developer ID signing identities for day-to-day development. That’s what Apple Development signing identities are for. Create Developer ID Signing Identities as the Account Holder Because Developer ID signing identities are precious, the Developer website will only let the Account Holder create them. For instructions on how to do this, see Developer Account Help > Create certificates > Create Developer ID certificates. For more information about programme roles, see Developer > Support > Program Roles. IMPORTANT In an Organization team it’s common for the Account Holder to be non-technical. They may need help getting this done. For hints and tips on how to avoid problems while doing this, see Don’t Lose Your Private Key and Don’t Leak Your Private Key, both below. Limit the Number of Developer ID Signing Identities You Create Don’t create Developer ID signing identities unnecessarily. Most folks only need to create one. Well, one Developer ID Application and maybe one Developer ID Installer. A large organisation might need more, perhaps one for each sub-unit, but that’s it. There are two reasons why this is important: The more you have, the more likely it is for one to get into the wrong hands. Remember that anyone with your Developer ID signing identity can sign code as you. The Developer website limits you to 5 Developer ID certificates. Note I can never remember where this limit is actually documented, so here’s the exact quote from this page: You can create up to five Developer ID Application certificates and up to five Developer ID Installer certificates using either your developer account or Xcode. Don’t Lose Your Private Key There are two standard processes for creating a Developer ID signing identity: Developer website — See Developer Account Help > Create certificates > Create Developer ID certificates. Xcode — See Xcode Help > Maintaining signing assets > Manage signing certificates. Both processes implicitly create a private key in your login keychain. This makes it easy to lose your private key. For example: If you do this on one Mac and then get a new Mac, you might forget to move the private key to the new Mac. If you’re helping your Organization team’s Account Holder to create a Developer ID signing identity, you might forget to export the private key from their login keychain. It also makes it easy to accidentally leave a copy of the private key on a machine that doesn’t need it; see Don’t Leak Your Private Key, below, for specific advice on that front. Every time you create a Developer ID signing identity, it’s a good idea to make an independent backup of it. For advice on how to do that, see Back Up Your Signing Identities, below. That technique is also useful if you need to copy the signing identity to a continuous integration system. If you think you’ve lost the private key for a Developer ID signing identity, do a proper search for it. Finding it will save you a bunch of grief. You might be able to find it on your old Mac, in a backup, in a backup for your old Mac, and so on. For instructions on how to extract your private key from a general backup, see Recover a Signing Identity from a Mac Backup. If you’re absolutely sure that you previous private key is lost, use the Developer website to create a replacement signing identity. If the Developer website won’t let you create any more because you’ve hit the limit discussed above, talk to Developer Programs Support. Go to Apple > Developer > Contact Us and follow the path Development and Technical > Certificates, Identifiers, and Provisioning Profiles. Don’t Leak Your Private Key Anyone with your Developer ID signing identity can sign code as you. Thus, it’s important to take steps to prevent its private key from leaking. A critical first step is to limit access to your Developer ID signing identities. For advice on that front, see Limit Access to Developer ID, above. In an Organization team, only the Account Holder can create Developer ID signing identities. When they do this, a copy of the identity’s private key will most likely end up in their login keychain. Once you’ve exported the signing identity, and confirmed that everything is working, make sure to delete that copy of the private key. Some organisations have specific rules for managing Developer ID signing identities. For example, an organisation might require that the private key be stored in a hardware token, which prevents it from being exported. Setting that up is a bit tricky, but it offers important security benefits. Even without a hardware token, there are steps you can take to protect your Developer ID signing identity. For example, you might put it in a separate keychain, one with a different password and locking policy than your login keychain. That way signing code for distribution will prompt you to unlock the keychain, which reminds you that this is a significant event and ensures that you don’t do it accidentally. If you believe that your private key has been compromised, follow the instructions in the Compromised Certificates section of Developer > Support > Certificates. IMPORTANT Don’t go down this path if you’ve simply lost your private key. Back Up Your Signing Identities Given that Developer ID signing identities are precious, consider making an independent backup of them. To back up a signing identity to a PKCS#12 (.p12) file: Launch Keychain Access. At the top, select My Certificates. On the left, select the keychain you use for signing identities. For most folks this is the login keychain. Select the identity. Choose File > Export Items. In the file dialog, select Personal Information Exchange (.p12) in the File Format popup. Enter a name, navigate to your preferred location, and click Save. You might be prompted to enter the keychain password. If so, do that and click OK. You will be prompted to enter a password to protect the identity. Use a strong password and save this securely in a password manager, corporate password store, on a piece of paper in a safe, or whatever. You might be prompted to enter the keychain password again. If so, do that and click Allow. The end result is a .p12 file holding your signing identity. Save that file in a secure location, and make sure that you have a way to connect it to the password you saved in step 9. Remember to backup all your Developer ID signing identities, including the Developer ID Installer one if you created it. To restore a signing identity from a backup: Launch Keychain Access. Choose File > Import Items. In the open sheet, click Show Options. Use the Destination Keychain popup to select the target keychain. Navigate to and select the .p12 file, and then click Open. Enter the .p12 file’s password and click OK. If prompted, enter the destination keychain password and click OK. Recover a Signing Identity from a Mac Backup If you didn’t independently backup your Developer ID signing identity, you may still be able to recover it from a general backup of your Mac. To start, work out roughly when you created your Developer ID signing identity: Download your Developer ID certificate from the Developer website. In the Finder, Quick Look it. The Not Valid Before field is the date you’re looking for. Now it’s time to look in your backups. The exact details depend on the backup software you’re using, but the basic process runs something like this: Look for a backup taken shortly after the date you determined above. In that backup, look for the file ~/Library/Keychains/login.keychain. Recover that to a convenient location, like your desktop. Don’t put it in ~/Library/Keychains because that’ll just confuse things. Rename it to something unique, like login-YYYY-MM-DD.keychain, where YYYY-MM-DD is the date of the backup. In Keychain Access, choose File > Add Keychain and, in the resulting standard file panel, choose that .keychain file. On the left, select login-YYYY-MM-DD. Chose File > Unlock Keychain “login-YYYY-MM-DD“. In the resulting password dialog, enter your login password at the date of the backup. At the top, select My Certificates. Look through the list of digital identities to find the Developer ID identity you want. If you don’t see the one you’re looking for, see Further Recovery Tips below. Export it using the process described at the start of Back Up Your Signing Identities. IMPORTANT If the original Mac was running macOS 26.4 or later, you might also need to recover this keychain’s protected entropy file. For more about that, see TN3137 On Mac keychain APIs and implementations Once you’re done, remove the keychain from Keychain Access: On the left, select the login-YYYY-MM-DD keychain. Choose File > Delete Keychain “login-YYYY-MM-DD”. In the confirmation alert, click Remove Reference. The login-YYYY-MM-DD.keychain is now just a file. You can trash it, keep it, whatever, at your discretion. This process creates a .p12 file. To work with that, import it into your keychain using the process described at the end of Back Up Your Signing Identities. IMPORTANT Keep that .p12 file as your own independent backup of your signing identity. Further Recovery Tips If, in the previous section, you can’t find the Developer ID identity you want, there are a few things you might do: Look in a different backup. If your account has more than one keychain, look in your other keychains. If you have more than one login account, look at the keychains for your other accounts. If you have more than one Mac, look at the backups for your other Macs. The login-YYYY-MM-DD keychain might have the private key but not the certificate. Add your Developer ID certificate to that keychain to see if it pairs with a private key. Revision History 2026-09-29 Added a link to the protected entropy file discussion in TN3137. 2025-03-28 Excised the discussion of Xcode’s import and export feature because that was removed in Xcode 16. 2025-02-20 Added some clarification to the end of Don’t Leak Your Private Key. 2023-10-05 Added the Recover a Signing Identity from a Mac Backup and Further Recovery Tips sections. 2023-06-23 Added a link to Identifying a Cloud Managed Signing Certificate. 2023-06-21 First posted.

Hi, My app Duo Queue has been in "Waiting for Review" since September 22, about 160 hours now, with no status change since then. App: Duo Queue: Game Tracker Apple ID: 6809453548 Version: 1.1 (build 21), submitted with the in-app purchase com.adgames.duoqueue.full_shelf Submission ID: 3ff2dc7d-2435-43a3-bc3f-33b1ae3478d2 Submitted: Sep 22, 2026, 09:05 UTC An earlier submission was rejected under Guideline 4.3(a). For 1.1 I rebuilt the core of the app. Users now photograph a game box and the app identifies it, and game detail pages include trailers where available. I also renamed Swift types that shared names with types in my other apps, and attached a demo video for the reviewer. I withdrew the previous submissions for this app, so this is its only active submission in the queue. I know the team has a lot of apps to get through. I'd just like to confirm that the submission isn't stuck somewhere, or find out if I need to do anything on my side. Thank you.

Hi everyone, My app, QuitIt, has been waiting for review for quite some time after my appeal was accepted. I’m keen to get it through the review process and released, but I haven’t received an update on what happens next or whether anything else is needed from me. Has anyone experienced a similar delay following a successful appeal? Is there a recommended way to follow up with App Review and confirm that my submission is moving forward? I understand review times can vary, and I’d appreciate any guidance. Thank you!

Trivial pass-through compositor fails on Xcode 27 (beta 2, beta 3); error code -11800 underlying error -12784. Repro included https://github.com/BugorBN/avplayer-custom-compositor-repro It works well on Xcode26 and lower

We ship a ~6.2 GB Apple-hosted managed asset pack and request it with AssetPackManager.ensureLocalAvailability(of:). If the app goes to the background even once while the download runs, the transfer continues to the end and then fails with ManagedBackgroundAssetsProcessingPipeline.Dispatcher.PipelineNotFound. The system discards the resume data, and the next attempt starts again from byte 0. What the sysdiagnose shows: On backgrounding, backgroundassets.user logs allows BG activity, pausing any foreground downloads for background demotion and hands the download to nsurlsessiond. On return it logs re-promoted 1 previously-demoted foreground downloads. Each handoff moves the stream to another STExtractionService.privileged instance, which logs No processing pipeline with the ID "…" was found; defaulting to an extraction memory footprint of 50 MB. When the HTTP response ends: [Relay] No endpoint was found for the key "…" (fault) → The stream couldn't be finished: No processing pipeline with the ID "…" was found → Removing the resumption info → the download fails. This happened on every app-requested download that was backgrounded at least once. One run reached 100 % in the foreground and still failed. The only download that ever completed was the system's own prefetch download, which ran entirely in the background with the app never launched. Over one afternoon about 46 GB were downloaded for a single 6.2 GB pack. Questions: Is this a known issue with the demotion/promotion of foreground asset-pack downloads? Is AssetPack.download(for: nil) plus BADownloadManager.scheduleDownload(_:) a supported way to request a managed pack from the app, so the download never gets foreground priority? We're testing it now. Is there any other way to keep a download requested from a foreground app from being demoted? Filed as FB24888599.