Hey there, I'm experiencing an issue with notarization of my macOS application, which is blocking a release. We have signing/notarization hooked up to our CI process, both for prior releases as well as development builds (at the trunk tip). The notarization process has typically taken anywhere from a few minutes to a few tens of minutes, but for our most recent release, it's taking an unreasonably long time. I've compiled the submission info for each build (+ reattempted notarizations) below. What's interesting is that the oldest one was accepted- however, it timed out our CI process, so we never actually released it. Subsequent builds are more or less identical in terms of their content, however, they've been stewing in the notarization process for over 13 hours in some cases. % xcrun notarytool info 67413dae-64f5-4372-972d-e0ac158e18e3 Successfully received submission info createdDate: 2025-04-02T16:28:25.999Z id: 67413dae-64f5-4372-972d-e0ac158e18e3 name: Warp Vault.app.zip status: In Progress % xcrun notarytool info 0c72b243-4a8d-4976-a97b-75689d7e2497 Successfully received submission info createdDate: 2025-04-02T05:49:05.861Z id: 0c72b243-4a8d-4976-a97b-75689d7e2497 name: Warp Vault.app.zip status: In Progress % xcrun notarytool info 8e2edfc2-58bc-4b33-bc8e-078155759a81 Successfully received submission info createdDate: 2025-04-02T05:23:28.870Z id: 8e2edfc2-58bc-4b33-bc8e-078155759a81 name: Warp Vault.app.zip status: In Progress % xcrun notarytool info 8fb17b0c-ace4-4b6f-bef8-68d22696814d Successfully received submission info createdDate: 2025-04-02T05:07:48.187Z id: 8fb17b0c-ace4-4b6f-bef8-68d22696814d name: Warp Vault.app.zip status: Accepted At the time of checking, the UTC date was: % TZ="UTC" date Wed Apr 2 18:42:14 UTC 2025 It's interesting to me that the notarization process is taking this long. We've notarized many development builds (with debugging flags enabled) in the time between our last public release and our attempt to notarize this one. What's more, the original build for this release was notarized within the span of about 15 minutes, but subsequent submissions of the same build have hung for tens of hours. My two questions are: How can I get our pending notarizations "unstuck"?, and To prevent these types of hangs in the future, should I also routinely build/sign/notarize non-debug builds of my application during the development process? Best regards and many thanks, Charlton

Hi, I have created a conda python environment which I have packaged into a .tar.gz (using conda-pack) and which runs correctly when extracted (in this example, it only contains the scipy package). However, when I sign the necessary files within the environment (i.e. the binaries, the dylibs, the .so files), attempting to load scipy.sparse now fails with the error "mapped file has no cdhash, completely unsigned" about one of the .so files. Furthermore, I believe that this file does in fact have a cdhash. The signing process represented by my example below has been working for about a year, and I am unsure why it has suddenly stopped working. I am on a 2020 MacBook Pro with an i7 processor and running Sequoia 15.1.1. Here is a minimal example showing the creating of the conda environment, codesigning, and the error message. Many thanks in advance! # Create and activate conda env > conda create -y -n mwe_env python=3.10 > conda activate mwe_env # Verify scipy not initially installed (mwe_env) > python Python 3.10.16 (main, Dec 11 2024, 10:24:41) [Clang 14.0.6 ] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy Traceback (most recent call last): File "<stdin>", line 1, in <module> ModuleNotFoundError: No module named 'scipy' (mwe_env) > pip install scipy Collecting scipy Downloading scipy-1.15.2-cp310-cp310-macosx_14_0_x86_64.whl.metadata (61 kB) Collecting numpy<2.5,>=1.23.5 (from scipy) Downloading numpy-2.2.4-cp310-cp310-macosx_14_0_x86_64.whl.metadata (62 kB) Downloading scipy-1.15.2-cp310-cp310-macosx_14_0_x86_64.whl (25.1 MB) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 25.1/25.1 MB 17.3 MB/s eta 0:00:00 Downloading numpy-2.2.4-cp310-cp310-macosx_14_0_x86_64.whl (7.0 MB) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 7.0/7.0 MB 16.4 MB/s eta 0:00:00 Installing collected packages: numpy, scipy Successfully installed numpy-2.2.4 scipy-1.15.2 (mwe_env) > python Python 3.10.16 (main, Dec 11 2024, 10:24:41) [Clang 14.0.6 ] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy.sparse >>> # success! # Package conda env (mwe_env) > conda-pack --output mwe_env.tar.gz --name mwe_env Collecting packages... Packing environment at '/path/to/my/conda/envs/mwe_env' to 'mwe_env.tar.gz' [########################################] | 100% Completed | 7.8s (mwe_env) > conda deactivate > mkdir mwe_dir && cd mwe_dir > tar -xzvf ../mwe_env.tar.gz > source bin/activate (mwe_dir) > python Python 3.10.16 (main, Dec 11 2024, 10:24:41) [Clang 14.0.6 ] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy.sparse >>> # success! # Sign the binaries and .dylibs and .so files (mwe_dir) > find bin -type f | xargs -n1 xcrun codesign -f -o runtime --timestamp --sign "Developer ID Application: MY_TEAM_ID" (mwe_dir) > find . -name "*.dylib" -o -name "*.so" -type f | xargs -n1 xcrun codesign -f -o runtime --timestamp --sign "Developer ID Application: MY_TEAM_ID" # the second command prints many lines saying it is "replacing existing signature" (mwe_dir) > python Python 3.10.16 (main, Dec 11 2024, 10:24:41) [Clang 14.0.6 ] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy.sparse Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/__init__.py", line 315, in <module> from . import csgraph File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/csgraph/__init__.py", line 187, in <module> from ._laplacian import laplacian File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/csgraph/_laplacian.py", line 7, in <module> from scipy.sparse.linalg import LinearOperator File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/__init__.py", line 134, in <module> from ._eigen import * File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/__init__.py", line 9, in <module> from .arpack import * File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/__init__.py", line 20, in <module> from .arpack import * File "/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/arpack.py", line 50, in <module> from . import _arpack ImportError: dlopen(/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so, 0x0002): tried: '/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so' (code signature in <5DD8FC01-7360-3DB9-8273-C8A45ABB19A9> '/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so' not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.), '/System/Volumes/Preboot/Cryptexes/OS/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so' (no such file), '/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so' (code signature in <5DD8FC01-7360-3DB9-8273-C8A45ABB19A9> '/path/to/mwe_dir/conda_env/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so' not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.) # But: (mwe_dir) > xcrun codesign -dvvv /path/to/mwe_dir/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so Executable=/path/to/mwe_dir/lib/python3.10/site-packages/scipy/sparse/linalg/_eigen/arpack/_arpack.cpython-310-darwin.so Identifier=_arpack.cpython-310-darwin Format=Mach-O thin (x86_64) CodeDirectory v=20400 size=4318 flags=0x10000(runtime) hashes=129+2 location=embedded Library validation warning=OS X SDK version before 10.9 does not support Library Validation Hash type=sha256 size=32 CandidateCDHash sha256=816731ecd1ad01b38555cbfef8c000628696d0ca CandidateCDHashFull sha256=816731ecd1ad01b38555cbfef8c000628696d0ca53376aebf6fae28d8c02f519 Hash choices=sha256 CMSDigest=816731ecd1ad01b38555cbfef8c000628696d0ca53376aebf6fae28d8c02f519 CMSDigestType=2 CDHash=816731ecd1ad01b38555cbfef8c000628696d0ca Signature size=9000 Authority=Developer ID Application: MY_TEAM_ID Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=2 Apr 2025 at 16:24:52 Info.plist=not bound TeamIdentifier=MY_TEAM_ID Sealed Resources=none Internal requirements count=1 size=188

Hi all, I'm developing a simple Finder Sync Extension, using Xcode 16.3. When running in Debug with Xcode, everything works fine. Instead, when compiling in Release and launching the containing app (by double-clicking on it), the Extension is not recognized (neither loaded) by the system. The only difference between Debug and Release stands in Signing configuration: Debug: Release: As you can see, in Release I'm using a Provisiong Profile, configured with my company's Developer ID. I'm wondering if Capabilities and Entitlements are not what is needed by my app. Anyway, I have no idea what the issue is. Any suggestion will be appreciated. Thank you in advance _Alex

Hey all! I'm building a Python based app with PySide6-deploy. This gives me a .app directory with all the necessary things already in it. To be able to distribute this I provided just the .app path to the codesign looking like this: codesign -s "My Name" --keychain "keychain" -f --deep RenderRob.app If I try to check or sign the package, it looks promising: codesign --verify ... RenderRob.app: valid on disk RenderRob.app: satisfies its Designated Requirement Unfortunately this signed package does not work when checking with spctl. spctl --assess --verbose RenderRob.app/Contents/MacOS/libcrypto.3.dylib RenderRob.app/Contents/MacOS/libcrypto.3.dylib: rejected If I look in the log of the notarizing, I saw that something is off with signature of the binary dependencies. Then I checked the binary dependencies, it turns out it complains about an edited signature: codesign -dv -verbose=4 RenderRob.app/Contents/MacOS/libcrypto.3.dylib RenderRob.app/Contents/MacOS/libcrypto.3.dylib: edited signature Mach-O thin (arm64) [com.dreisicht.renderrob] I then also tried to move this into RendeRob.app/Contents/Frameworks, but there it's also having the same issue. Any idea what this could be?

I had submitted my app for notarization and it shows the below error - "status": "Rejected", "statusSummary": "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.", "statusCode": 7000, I have raised a ticket in the support but no reply yet. Kindly help ASAP

I submitted a Mac application for a safari ad blocker extension about 15 hours ago and it's still in progress. Is it normal for notarization to take this long? It's my first time submitting something for notarization so maybe that's why it's taking longer than expected? ID: 8BDB3D5E-3A42-469F-9479-AC76229C6BB5

Hi, I recently got a consistent delay from notary tool. I have viewed all your suggestions and understand that it "occasionally" will have further review and take longer time, but then it will be faster. However, in my case, my app although is accepted many times. It is still significantly delay. It is a native macOS app called ConniePad. Whenever I submit, it took me 2 days or more to finish notarise, which significantly affect my business. Could you please have a look on it. For log detail about the time, and the ids: -------------------------------------------------- createdDate: 2025-04-05T22:54:45.815Z id: 998b5aa8-fc9c-4469-98fe-950d815e734e name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-05T21:32:22.679Z id: c7b1ab49-6f46-4998-8d06-2ffe8a180c8f name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T08:39:52.594Z id: aa33d9d0-9d2f-4296-8fc3-d7e0b404596b name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T01:23:31.077Z id: b0333d78-497d-491c-b36c-bdfb64520296 name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T01:17:20.925Z id: 83aa12f2-f1bb-457f-940a-4c2281cf8a5f name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T01:12:52.932Z id: 0a921069-fb37-469a-bfb0-6be82e9320ba name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T01:03:30.584Z id: a607fe3c-d10f-43d6-a184-e97df7b632fd name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T00:52:47.322Z id: c42d0ca0-db8a-4431-b5b4-646ccfcad003 name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T00:28:18.626Z id: 7ef8777f-7add-4440-abb5-3c0b19cf92d4 name: ConniePad.app.zip status: Invalid -------------------------------------------------- createdDate: 2025-04-03T00:24:37.320Z id: 36bb1285-0aeb-4c48-b23c-fac737a3d93f name: ConniePad.app.zip status: Invalid -------------------------------------------------- createdDate: 2025-04-02T23:59:27.940Z id: bb4578a5-a67b-49e8-afd0-a9d707c10091 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T08:51:38.295Z id: 93ff89f4-98d3-45ac-9ee8-9483726a9666 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T08:19:13.762Z id: 9e4a62df-3d8a-4cfa-ae9e-56ff35ffe137 name: ConniePad-ConverterTool.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T04:15:34.508Z id: 7ee43b74-f73f-462a-bb3d-f6bc53b1cb80 name: ConniePad-ConverterTool.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T02:11:53.312Z id: d675e8f6-dc30-48e9-9269-9bc376f1b29e name: ConniePad-ConverterTool.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T01:30:32.768Z id: 9901f125-4355-4812-936b-97578ac2de2f name: ConniePad-ConverterTool.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-01T20:47:26.035Z id: a79265bc-8ad3-4a4b-ae39-150801aa9da9 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-18T22:39:54.189Z id: b808b676-a41c-4536-b4fd-4b567701adcb name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-18T05:21:23.607Z id: 797f5d4f-cd94-4511-9217-11e57c2c7ac3 name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-18T05:18:30.707Z id: c5b5c260-fb7f-4bda-9548-f5b7e57cb2f3 name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:45:37.831Z id: f24c1017-9171-4796-bf97-ea47ef83f7ce name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:38:17.981Z id: 8dd0ea7e-e810-48f9-a48f-62dcc1406284 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:33:27.649Z id: 704e339a-4d99-4e5e-8414-deb8b26c57ac name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:32:06.925Z id: 8e9b09b6-e061-4361-abc1-0bbd8f33b599 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:26:52.444Z id: 2b564641-eb87-4de9-a59c-ff5362b8bf4a name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:22:04.790Z id: 1aa158bd-0afd-4c60-8e2f-3029388710ab name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:17:17.141Z id: 3bffcf1d-2fd7-41ba-b70c-f85837499736 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T02:38:47.102Z id: 2dd2fb47-7dff-4f30-b2e0-d8c2bfcf10f5 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-14T03:23:54.671Z id: 5cafb2a9-03e3-468e-b918-ff24b17fceee name: ConniePad.app.zip status: Accepted

Hi, At work, we've done some development on an Apple Vision Pro. On the project, we used object tracking to track an object in 3D and found the default tracking refresh rate (I believe 5Hz)to be too slow so we applied for enterprise APIs so we could change it. At some point, in the capabilities (as a beginner to Swift and the Apple development environment) I noticed that's where you enable the Object Tracking Parameter Adjustment API and I did so, before hearing back about whether we got access to the enterprise API's and the license file that comes with it. So I setup the re-fresh rate to 30Hz and logged the settings of the ObjectTrackingProvider, showing it was set at 30Hz and felt like it was better than the default when we ran our app. In the Xcode runtime logs, there was no warning or error saying that the license file for the enterprise API was not found (and I don't think we heard back from Apple if they had granted our request or not - even if they did I think the license would be expired by now). Fast forward to today, I was running the sample code of the Main Camera access for VisionOS linked in the official developer documentation and when I ran the project in Xcode, I noticed in the logs that it wanted an enterprise license and that's why it wasn't running as expected in the immersive space. We've since applied for the Enterprise API for Main Camera Access. I'm now confused - did I mistakenly believe the object tracking refresh rate was set to 30Hz but it actually wasn't due to the lack of a license file/being granted access to the enterprise APIs? It seemed to be running as expected without a license file. Is Object tracking Parameter Adjustment API handled with different permissions than Main Camera Access API even though they are both enterprise APIs? This is all for internal development and not planning on distributing an app but I find the behaviour to be confusing between the different enterprise API? Does anyone have more insight as I find the developer notes on the enterprise APIs to be a bit sparse.

Hi All. I'm having a notarization issue trying to get a product built. Starting around the beginning of April, I have a notarization process failing every time with an invalid server certificate. The returned error is: Error: HTTPError(statusCode: nil, error: Error Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “notary-artifacts-prod.s3.amazonaws.com” which could put your confidential information at risk." UserInfo={NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, NSErrorPeerCertificateChainKey=( "<cert(0x107810200) s: *.s3.amazonaws.com i: Amazon RSA 2048 M01>", "<cert(0x107810c00) s: Amazon RSA 2048 M01 i: Amazon Root CA 1>", "<cert(0x107811400) s: Amazon Root CA 1 i: Starfield Services Root Certificate Authority - G2>", "<cert(0x107811c00) s: Starfield Services Root Certificate Authority - G2 i: Starfield Class 2 Certification Authority>" The problem certificate appears to be "Amazon RSA 2048 M01" which appears to be expired. The error fires in response to an 'xcrun notarytool log' command. The initial ' xcrun notarytool submit' has already worked. The build server in this case is running Jenkins, with a Makefile driven notarization stage. It all worked perfectly until a build on April 3rd, all builds have failed since. I have tried using '--no-s3-acceleration'. But that fails even faster with: Conducting pre-submission checks for ICFA.zip and initiating connection to the Apple notary service... Submission ID received id: d50a2157-7acb-4bd6-b1d1-6d0b1d52d5c9 Error: The operation couldn’t be completed. (Network.NWError error 2.) Any help or suggestions would be appreciated. Right now I have folks needing a valid build. Thanks in advance.

Hi, I have some doubts about certificates expiration given this "new" requirement around signing for some common third party SDKs: https://developer.apple.com/support/third-party-SDK-requirements/ Use case: I build an SDK that will be distributed as an XCFramework and will be used in AppStore apps from different people. My SDK internally uses some other third party libraries that are integrated as binaries Let's assume some of those third party libraries are from the list above and therefore seem to be required to be signed. I distribute my SDK with all in order (third party SDKs from that list with valid signatures) People using my SDK over the time provide an update to their apps on the AppStore but by then some of the third party libraries of my SDK has an expired certificate. What would happen? People using my SDK won't have any issues as far as my SDK has a valid signature (despite third party libraries from the list have expired signatures) People using my SDK will get a warning about it but still will be able to submit to the AppStore. In that case, would AppStore Review process decline the update? People using my SDK will get an error, not being able to submit to the AppStore and will require me an update version of the SDK with those third party libraries re-signed. My understanding is that all would work as far as my SDK has a valid signature (after all is the one taking responsibility of the code inside), independently of what happens with the signature of those libraries themselves, am I correct?.

When building to macOS on GameMaker, I get the error "this identity cannot be used for signing code" when using the Developer ID Installer certificate. The certificate was neither expired nor revoked, but nonetheless I created new certificates to start fresh but am still getting that error. I don't get issues building to iOS via GameMaker, just to macOS. If it makes any difference, I only noticed this issue started happening after I converted my Apple Developer Program account from an individual account to an organizational account, although it was weeks to months before I built to macOS via GameMaker before then, so I don't know if it correlates with that.

Hi all, I've submitted multiple notarization requests for an Electron app using notarytool since (april 12) at 6:30. All are stuck in the "In Progress" state Successfully received submission history. history -------------------------------------------------- createdDate: 2025-04-13T12:38:56.866Z id: 51897340-9547-4172-bad4-ae15f78e1ab0 name: theAIParalegal.zip status: In Progress -------------------------------------------------- createdDate: 2025-04-13T12:38:55.790Z id: ebcd8a15-613c-41e0-b8cc-6895a0a6785a name: theAIParalegal.zip status: In Progress -------------------------------------------------- createdDate: 2025-04-13T12:14:33.553Z id: 59a078dc-e613-4933-b440-8695e2204eac name: theAIParalegal.zip status: In Progress -------------------------------------------------- createdDate: 2025-04-13T12:14:32.108Z id: 987879aa-db15-405b-bd1d-76db31218f49 name: theAIParalegal.zip status: In Progress -------------------------------------------------- createdDate: 2025-04-12T22:06:30.869Z id: b1f4231c-6d13-4292-88f0-e8ce53cb0141 name: theAIParalegal.zip status: In Progress nicolasserna@Mac ~ %

I’ve developed a macOS app, but I’ve had trouble using a script to fully codesign it and package it into a .dmg file. I was only able to complete codesigning using the third-party app itself—not via command-line scripts. Is it possible to write a script that automates the entire process of codesigning the app? To provide the best user experience for those downloading the app outside of the Mac App Store, is it correct to first package it as a .app and then wrap that into a .dmg file for distribution? Currently, the app is available on the web as a .dmg. When downloaded, it appears in a folder and can be double-clicked to launch. However, macOS displays a warning that it was downloaded from the internet. Can I use a script to remove that quarantine warning? If possible, I’d appreciate a step-by-step explanation and a sample command-line script to: Codesign the app properly Package it into a signed .dmg Remove the quarantine attribute for local testing or distribution Is the reason I was only able to codesign it inside the third-party app due to how that app was built, or can this always be done from the command line?

Hello, For my macOS app, on Xcode version 15.4 (15F31d) on macOS 14.5 (23F79) I follow Organizer > Distribute App > Direct Distribution, and I get a Notary Error "The operation couldn't be completed. (SotoS3.S3ErrorType.multipart error 1.)" It's been happening since 3 days. In the IDEDistribution.verbose.log file I see: https://gist.github.com/atacan/5dec7a5e26dde0ec06a5bc4eb3607461

Hi there, We've discovered a problem with our iOS app. We've been attempting to add a Driverkit driver to it, but any time we run the app through Testflight, the driver installs fine, but when we go to enable the driver toggle in the app's settings, the toggle stays on, but in the device logs I can see: could not insert bundle at <private> into manager: <private> As you would expect - this means the driver is not actually enabled and does not respond to a device being connected to the iPad. This does not happen when building & running the app locally, nor does it happen when installing an Ad Hoc build. We also have a different app, not yet shipped. We are able to add the driver to that app without issue. It works after going through Testflight. What we have discovered now is that everything works fine even if we just create an entirely new app with it's own bundle IDs. I should point out that in all cases, we're keeping the capabilities the same for each of these apps/IDs - including the managed capabilities. The bundle IDs that have this problem are older (5 years old or more). It seems like any newer ID will work, but trying to add the driver (and the associated managed capabilities) to an older app/ID results in this vague error message, with no further details. If we inspect the resulting dexts, we can also see that the "Internal requirements code size" is different on the ones that fail. The failing ones have a size of 204 bytes, whereas the working ones all have a size of 220 bytes. Not sure if that's related but it's strikingly consistent. Does this mean there is an issue with older app IDs, and we need Apple to manually refresh them in some way before the driverkit capabilities will work after going through Testflight? We have two apps in this state, both are of the same vintage (~5 years+). We've been battling this issue for months on and off, so would appreciate some help.

Hello, I recently had my Electron app notarized by Apple and then performed the following steps: Stapling the Notarization Ticket: xcrun stapler staple "appPath/Aiparalegal.app" Zipping the App for Distribution: ditto -c -k --keepParent "appPath/Aiparalegal.app" theAIParalegal.zip However, after unzipping and attempting to launch the app, macOS displays the following message: Apple could not verify "theAIParalegal" is free of malware that may harm your Mac or compromise your privacy. Yet, when I run validation using: xcrun stapler validate "theAIParalegal.app" I receive confirmation: The validate action worked! spctl -a -vvv -t install "theAIParalegal.app" theAIParalegal.app: accepted source=Notarized Developer ID origin=Developer ID Application: NIPartnership LLC (M92N2796Q9) Could you help me understand why the notarization validation appears successful, yet macOS still displays this security warning? Any advice on how to resolve this would be greatly appreciated. Thank you!

Hello, I recently had my Electron app notarized by Apple and then performed the following steps: Stapling the Notarization Ticket: xcrun stapler staple "appPath/Aiparalegal.app" Zipping the App for Distribution: ditto -c -k --keepParent "appPath/Aiparalegal.app" theAIParalegal.zip However, after unzipping and attempting to launch the app, macOS displays the following message: Apple could not verify "theAIParalegal" is free of malware that may harm your Mac or compromise your privacy. Yet, when I run validation using: xcrun stapler validate "theAIParalegal.app" I receive confirmation: The validate action worked! I then tried restarting my computer but the problem persist Could you help me understand why the notarization validation appears successful, yet macOS still displays this security warning? Any advice on how to resolve this would be greatly appreciated. Thank you!

We had an issue with IDrive Online Backup which has started discussing on the Developer forum at https://developer.apple.com/forums/thread/756904 and as suggested raised a technical support ticket Case-ID: 7747625. At last the old legacy bundle ID prefix changed to to the new Team ID prefix. As a result  one-time loss of keychain data occurs, however we requested and were granted an additional keychain capability that allowed access to keychain data stored under the old legacy prefix, even after transitioning to the new Team ID prefix. We are currently facing a similar challenge with our other application, IBackup. As with the earlier case, we had a mismatch between the App ID prefix and the Team ID, which we resolved by updating the prefix to match the Team ID. Again now encountered a blocker with Keychain data recovery. We have already requested the additional Keychain capability that would allow access to keychain data stored under the old legacy prefix, even after transitioning to the new Team ID prefix. Unfortunately, the team responsible for this has some uncertainty about the process. Please review the details under case 102398017929 and extend this capability to our application to ensure a seamless user experience.

Background I've repeatedly run into codesigning (and missing provisioning profile) issues for my Ruby/Glimmer app and am looking for ways to troubleshoot this outside of Xcode. The app structure is as follows: PATHmanager.app └── Contents ├── Info.plist ├── MacOS │   └── PATHmanager ├── PkgInfo ├── Resources │   └── AppIcon.icns ├── _CodeSignature │   └── CodeResources └── embedded.provisionprofile Architecture I have a Mac mini Apple M2 Pro with macOS Ventura 13.4. Xcode is not used directly, but the underlying command line tools (e.g., codesign, productbuild, pkgutil, xcrun) are run from a custom Ruby script. xcodebuild -version Xcode 14.3.1 Build version 14E300c Questions Is the .app directory and file structure/naming sufficient? If not, can you point me in the direction of a minimal example that does not use Xcode? Info.plist is an XML text document (not binary), which I believe is in an acceptable format, but how do I lint this file and determine if it contains all of the necessary key/value pairs? <?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>CFBundleDevelopmentRegion</key> <string>en</string> <key>CFBundleDisplayName</key> <string>PATH manager</string> <key>CFBundleExecutable</key> <string>PATHmanager</string> <key>CFBundleIconFile</key> <string>AppIcon.icns</string> <key>CFBundleIdentifier</key> <string>com.chipcastle.pathmanager</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>PATHmanager</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleShortVersionString</key> <string>1.15</string> <key>CFBundleSupportedPlatforms</key> <array> <string>MacOSX</string> </array> <key>CFBundleVersion</key> <string>1.15</string> <key>ITSAppUsesNonExemptEncryption</key> <false/> <key>LSApplicationCategoryType</key> <string>public.app-category.developer-tools</string> <key>LSMinimumSystemVersion</key> <string>12.0</string> <key>LSUIElement</key> <false/> <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> </dict> <key>NSHumanReadableCopyright</key> <string>© 2025 Chip Castle Dot Com, Inc.</string> <key>NSMainNibFile</key> <string>MainMenu</string> <key>NSPrincipalClass</key> <string>NSApplication</string> </dict> </plist> PATHmanager is a Mach-O 64-bit executable arm64 file created by using Tebako. Does this executable need to be codesigned, or is codesigning the .app folder sufficient? Does the .app directory need an entitlements file? Here's how I codesign it: codesign --deep --force --verify --verbose=4 --options runtime --timestamp --sign 'Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' '/Users/chip/Desktop/distribution/PATHmanager.app' Does the PATHmanager binary need an entitlements file? Here's how I codesign it: codesign --deep --force --verify --verbose=4 --options runtime --timestamp --entitlements '/Users/chip/Desktop/PATHmanager.entitlements' --sign 'Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' '/Users/chip/Desktop/distribution/PATHmanager.app/Contents/MacOS/PATHmanager' How can I verify what entitlements, if any, are required for codesigning the binary? The PATHmanager.entitlements file is an XML text file containing only 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/> </dict> </plist> Is the embedded.provisionprofile necessary, and if so, how do I know determine if it matches the certificate or entitlements that I'm using? Additionally, is it named and located properly? I submitted this to the AppStore several weeks ago and the reviewer reported that the executable would not load on their machine (even though it worked on mine.) Is it better for me to release via TestFlight for testing, and if so, do I need to following a separate process for codesigning (i.e., using different entitlements, profiles, certs, etc) when doing so? I've been playing whack-a-mole with this for too long to mention and am hoping to nail down a better deployment flow, so any suggestions for improvement will be greatly appreciated. Thank you in advance.

Hi everyone, I applied for CarPlay Entitlements on [Date 04. 26, 2024] using CarPlay is Case ID "13045151". I haven't received any updates or responses regarding my application yet. It's been 7 days since the application. My service requires CarPlay integration with a Black Box device. The primary purpose of this integration is to allow users to configure device settings through CarPlay. Furthermore, we plan to utilize the "Communication" category of Entitlements to notify users of parking incidents detected by the Black Box device while parked. This functionality is crucial for alerting drivers to potential issues affecting their vehicles. Could anyone share their experience with the typical turnaround time for CarPlay Entitlements, especially for applications involving device integration and the "Communication" category? Is this delay normal? Is there any way to check the application status or contact the appropriate team to inquire about its progress? Thank you for any insights or advice you can provide! Sincerely,