Hi,
We have an app that is a default mail client, so it has this entry in its entitlements file: com.apple.developer.mail-client. This seems to create issues with ad-hoc distribution.
We can distribute the app on App Store Connect without any issues and have been doing so for a while.
We wanted to try using Xcode Cloud to manage our releases. The app export works fine for both App Store Distribution and Development Distribution.
However, the ad-hoc distribution step fails. (We don't need ad-hoc distribution, but Xcode Cloud seems to prevent us from removing this step.)
I tried building and releasing the app locally for ad-hoc distribution and encountered the same error as on Xcode Cloud.
When Xcode tries to generate the profile, it outputs the following error:
Provisioning profile "iOS Team Ad Hoc Provisioning Profile: com.infomaniak.mail" failed qualification checks:
Profile doesn't support Default Mail App.
Profile doesn't include the com.apple.developer.mail-client entitlement.
Is it something broken with our config ? What are we missing ?
Local error in Xcode Organizer:
Remote error on Xcode cloud:
Demystify code signing and its importance in app development. Get help troubleshooting code signing issues and ensure your app is properly signed for distribution.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I’ve been working on a Catalyst version of my iOS apps.
Finally everything is working apart from the custom intents the user user to configure the widgets.
The config UI loads:
And changing settings at this level works.
But it can’t load the options for the other settings:
“No options were provided for this parameter”
I see this crash in the intent:
Termination Reason: Namespace DYLD, Code 1 Library missing
Library not loaded: @rpath/CocoaLumberjack.framework/Versions/A/CocoaLumberjack
Referenced from: <E1BF4CC5-4181-3272-828C-86B1CD1A66BF> /Applications/my.app/Contents/PlugIns/Intents.appex/Contents/MacOS/Intents
Reason: , (security policy does not allow @ path expansion)
(terminated at launch; ignore backtrace)
I have added the Hardened Runtime Capability to the Main App Target, the Widget Target and the Intents Target. I also allowed “Disable Library Validation” just in case.
What am I missing?
I requested the Family Controls Entitlement last week and haven’t heard back at all. I’ve submitted the request three times now, but I haven’t received a confirmation, a case number, or even an acknowledgment that it was received.
I called Apple Support, but they said they have no visibility into the entitlement request process, which leaves me completely in the dark. I just want to know if my request is under consideration or not.
This is especially frustrating because I’ve had strong engagement on social media around my app, and I have stakeholders waiting for updates. Right now, I can’t send the app for review, and I can’t even distribute it via TestFlight to internal testers.
Honestly, I didn’t expect this kind of radio silence from Apple. Has anyone else experienced this when requesting entitlements?
My app records the screen to use the audio for audio analysis for a music visualization. The app works perfectly in production but when uploaded to Transporter is rejected as below. What is the correct entitlement to use as the entitlement I am using seems deprecated.
Validation failed (409)
Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on macOS. Specifically, key 'com.apple.security.screen-capture' in 'com.boxedpandora.pulse.pkg/Payload/PuLsE.app/Contents/MacOS/PuLsE' is not supported. (ID: a1a436f5-925d-43bc-908d-0761064d589b)
Many thanks for any input provided!
On MacOS, I know that App Groups (com.apple.security.application-groups) do not require a provisioning profile.
I was wondering if it's possible to sign them "ad hoc" and have it work? So maybe use a random TEAMID prefix and have it work?
I would only need the app to work locally (for testing), not be distributed in that fashion, of course.
My app designer cannot sign his code changes. He says the only way he can sign his code is for me to give him my Admin privileges. I have revoked and recreated my certificate, hoping to get a private passkey, but there was no private passkey issued with the certificate. Help, please?
Topic:
Code Signing
SubTopic:
General
Hi,
I got the error:
/usr/bin/codesign exited with code 1:
Warning: unable to build chain to self-signed root for signer "Apple Distribution: Q.A.C.F. - Quality Academy Consultoria E Formacao, Unipessoal, Lda (xxxxxx)"
/Users/pedroramalho/Library/Caches/Xamarin/mtbs/builds/drBoxSaude.iOS/3bed3d51415af2e100a4d2bc57e1d36fb42d76ceb190de1db1c4d0dbccbff863/bin/iPhone/Release/drBoxSaude.iOS.app: errSecInternalComponent
and
/usr/bin/codesign exited with code 1:
/Users/pedroramalho/Library/Caches/Xamarin/mtbs/builds/drBoxSaude.iOS/3bed3d51415af2e100a4d2bc57e1d36fb42d76ceb190de1db1c4d0dbccbff863/bin/iPhone/Release/drBoxSaude.iOS.app/Frameworks/libSkiaSharp.framework: replacing existing signature
Warning: unable to build chain to self-signed root for signer "Apple Distribution: Q.A.C.F. - Quality Academy Consultoria E Formacao, Unipessoal, Lda (xxxxx)"
/Users/pedroramalho/Library/Caches/Xamarin/mtbs/builds/drBoxSaude.iOS/3bed3d51415af2e100a4d2bc57e1d36fb42d76ceb190de1db1c4d0dbccbff863/bin/iPhone/Release/drBoxSaude.iOS.app/Frameworks/libSkiaSharp.framework: errSecInternalComponent
Some one can help please
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Sign in with Apple
Signing Certificates
I have been trying to notarize my application for about a month via this command -
xcrun notarytool submit "Backlsh.zip" --apple-id "" --password "" --team-id ""
but it throws error -
{
"logFormatVersion": 1,
"jobId": "c8173ee6-edd2-4c51-a86b-8f3b8dea0a84",
"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,
"archiveFilename": "Backlsh.zip",
"uploadDate": "2025-03-06T05:33:56.287Z",
"sha256": "b45e579f0c47070b55d74ac49e49c81d32f2315bd290ca5592f71f314018c44d",
"ticketContents": null,
"issues": null
}
I have raised ticket to apple support but i havent received any help yet !
I have tried to submit 5 times.
Kindly help !
The notary service requires that all Mach-O images be linked against the macOS 10.9 SDK or later. This isn’t an arbitrary limitation. The hardened runtime, another notarisation requirement, relies on code signing features that were introduced along with macOS 10.9 and it uses the SDK version to check for their presence. Specifically, it checks the SDK version using the sdk field in the LC_BUILD_VERSION Mach-O load command (or the older LC_VERSION_MIN_MACOSX command).
There are three common symptoms of this problem:
When notarising your product, the notary service rejects a Mach-O image with the error The binary uses an SDK older than the 10.9 SDK.
When loading a dynamic library, the system fails with the error mapped file has no cdhash, completely unsigned?.
When displaying the code signature of a library, codesign prints this warning:
% codesign -d vvv /path/to/your.dylib
…
Library validation warning=OS X SDK version before 10.9 does not support Library Validation
…
If you see any of these errors, read on…
The best way to avoid this problem is to rebuild your code with modern tools. However, in some cases that’s not possible. Imagine if your app relies on the closed source libDodo.dylib library. That library’s vendor went out of business 10 years ago, and so the library hasn’t been updated since then. Indeed, the library was linked against the macOS 10.6 SDK. What can you do?
The first thing to do is come up with a medium-term plan for breaking your dependency on libDodo.dylib. Relying on an unmaintained library is not something that’s sustainable in the long term. The history of the Mac is one of architecture transitions — 68K to PowerPC to Intel, 32- to 64-bit, and so on — and this unmaintained library will make it much harder to deal with the next transition.
IMPORTANT I wrote the above prior to the announcement of the latest Apple architecture transition, Apple silicon. When you update your product to a universal binary, you might as well fix this problem on the Intel side as well. Do not delay that any further: While Apple silicon Macs are currently able to run Intel code using Rosetta 2, that’s not something you want to rely on in the long term. Heed this advice from About the Rosetta Translation Environment:
Rosetta is meant to ease the transition to Apple silicon, giving you
time to create a universal binary for your app. It is not a substitute
for creating a native version of your app.
But what about the short term? Historically I wasn’t able to offer any help on that front, but this has changed recently. Xcode 11 ships with a command-line tool, vtool, that can change the LC_BUILD_VERSION and LC_VERSION_MIN_MACOSX commands in a Mach-O. You can use this to change the sdk field of these commands, and thus make your Mach-O image ‘compatible’ with notarisation and the hardened runtime.
Before doing this, consider these caveats:
Any given Mach-O image has only a limited amount of space for load commands. When you use vtool to set or modify the SDK version, the Mach-O could run out of load command space. The tool will fail cleanly in this case but, if it that happens, this technique simply won’t work.
Changing a Mach-O image’s load commands will break the seal on its code signature. If the image is signed, remove the signature before doing that. To do this run codesign with the --remove-signature argument. You must then re-sign the library as part of your normal development and distribution process.
Remember that a Mach-O image might contain multiple architectures. All of the tools discussed here have an option to work with a specific architecture (usually -arch or --architecture). Keep in mind, however, that macOS 10.7 and later do not run on 32-bit Macs, so if your deployment target is 10.7 or later then it’s safe to drop any 32-bit code. If you’re dealing with a Mach-O image that includes 32-bit Intel code, or indeed PowerPC code, make your life simpler by removing it from the image. Use lipo for this; see its man page for details.
It’s possible that changing a Mach-O image’s SDK version could break something. Indeed, many system components use the main executable’s SDK version as part of their backwards compatibility story. If you change a main executable’s SDK version, you might run into hard-to-debug compatibility problems. Test such a change extensively.
It’s also possible, but much less likely, that changing the SDK version of a non-main executable Mach-O image might break something. Again, this is something you should test extensively.
This list of caveats should make it clear that this is a technique of last resort. I strongly recommend that you build your code with modern tools, and work with your vendors to ensure that they do the same. Only use this technique as part of a short-term compatibility measure while you implement a proper solution in the medium term.
For more details on vtool, read its man page. Also familiarise yourself with otool, and specifically the -l option which dumps a Mach-O image’s load commands. Read its man page for details.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Revision history:
2025-04-03 — Added a discussion of common symptoms. Made other minor editorial changes.
2022-05-09 — Updated with a note about Apple silicon.
2020-09-11 — First posted.
I'm getting this error when uploading a build of my macOS app to App Store Connect. It has always worked before, and nothing changed about my use of app groups, and the iOS build uploaded without any problems. Cleaning the build folder and derived data folder doesn't help. I'm using automatically managed signing in Xcode.
Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “[group.]” value for the com.apple.security.application-groups key in “.pkg/Payload/.app/Contents/MacOS/” isn’t supported. This value should be a string or an array of strings, where each string is the “group” value or your Team ID, followed by a dot (“.”), followed by the group name. If you're using the “group” prefix, verify that the provisioning profile used to sign the app contains the com.apple.security.application-groups entitlement and its associated value(s).
Hi,
I developed a Flutter app that works well in the iOS simulator, but that fails to deploy on my physical iPhone 13 Pro Max. Here is the error I get:
Target debug_unpack_ios failed: Exception: Failed to codesign /Users//Library/Developer/Xcode/DerivedData/Runner-/Build/Products/Debug-iphoneos/Flutter.framework/Flutter with identity
I've followed all the instructions that I found online, like moving my project from cloud storage to my local hard drive, but nothing has worked.
Thank you so much for your help!
Topic:
Code Signing
SubTopic:
General
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
Topic:
Code Signing
SubTopic:
General
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
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Extensions
Xcode
Debugging
Developer ID
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?
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
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
Topic:
Code Signing
SubTopic:
Notarization
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.
Topic:
Code Signing
SubTopic:
Notarization