I am seeking clarification on the possibility of notarizing apps without an active Apple Developer Program membership, as I currently possess a 10-year installer signing certificate. However, when attempting to store credentials for notarization, I encounter the following error message: Error: HTTP status code: 403. A required agreement is missing or has expired. This request requires an in-effect agreement that has not been signed or has expired. Ensure your team has signed the necessary legal agreements and that they are not expired.

Hello! I'm relatively new (started a week ago) to creating MacOS applications. I had built an application in Python for Windows devices, and now I'm looking to distribute the beta to some friends who use Mac devices. I don't intend to put the app on the App Store, so I think that means I won't need to sandbox it. I've figured out how to adapt all of the functionality of the app to work on MacOS. I'm able to get the app to run successfully after using py2app and setting the required permissions in my .plist file. However, I'm trying to sign and notarize the functioning application and I'm hitting some challenges. I've tried a few combinations of things, but to no avail and I'm hoping someone can help me. I start by running the following to build my .app bundle: python setup.py py2app from setuptools import setup import os APP = ['App Name.py'] DATA_FILES = [ ('static', ['path/to/icons', 'path/to/styles']), ('static/fonts/Inter', ['path/to/font']), ] OPTIONS = { 'argv_emulation': True, 'iconfile': 'App Name.icns', 'packages': ['chardet', 'charset_normalizer', 'soundfile', 'sounddevice', '_sounddevice_data'], 'plist': { 'CFBundleIdentifier': 'com.companyname.appname', 'CFBundleName': 'App Name', 'CFBundleVersion': '1.0.0', 'CFBundleShortVersionString': '1.0.0', 'CFBundleExecutable': 'App Name', 'CFBundleIconFile': 'App Name.icns', 'NSMicrophoneUsageDescription': 'We need access to your microphone to provide transcripts of what you say.', 'com.apple.security.cs.allow-unsigned-executable-memory': True, 'com.apple.security.cs.disable-library-validation': True, 'com.apple.security.cs.allow-jit': True, }, } setup( app=APP, data_files=DATA_FILES, options={'py2app': OPTIONS}, setup_requires=['py2app'], ) os.system('find "dist/App Name.app" -iname "*.so" -or -iname "*.dylib" | while read libfile; do codesign -s "DEVELOPER CERTIFICATE" --timestamp -o runtime --entitlements Info.plist "${libfile}"; done;') Note that I have some codesigning happening at the bottom based on what I'd seen in some of the other forum posts. After running this, the standalone app works as expected on my computer. I've tried a few things from here, including: Creating a .dmg of the .app and submitting that for notarization - the response from the notary service just says "invalid" and I'm not sure how to get more details on why the request was invalid. Codesigning the .app - in this case, the codesign action appears to work when I run it in the terminal. When I double click on the .app bundle after codesigning, the app encounters a fatal error when launching (no errors are reported when launching this from the terminal and no crash logs are created either). Creating a .dmg of the .app, codesigning the .dmg, and submitting that for notarization - this resulted in an "invalid" response from the notary service (same as #1), but it wasn't clear why my request had failed. My codesign script looks like this. I've tried this with and without the entitlements record. I've also tried this with and without the --deep flag which seems to be a thing that other people have tried. For the Info.plist, I copied over the one that was automatically generated by py2app during the creation of the .app bundle, which looked to have all of the permissions my app needed. codesign \ -vvv \ --strict \ --force \ --timestamp \ --options runtime \ --entitlements "Info.plist" \ --sign "Developer ID Application: MY NAME (LETTERS_AND_NUMBERS)" \ "dist/App Name.app" My notarization request looks like this. xcrun notarytool --vvv submit --wait --keychain-profile "profilename" "dist/App Name.dmg" xcrun stapler staple "dist/App Name.dmg" I had previously successfully codesigned and notarized a simple "hello world" app, so I'm fairly sure my credentials are correct for both my codesign and notarytool.

I help a lot of developers with macOS trusted execution problems. For example, they might have an app being blocked by Gatekeeper, or an app that crashes on launch with a code signing error. If you encounter a problem that’s not explained here, start a new thread with the details. Make sure to add relevant tags — like Gatekeeper, Code Signing, and Notarization — so that I see your post. IMPORTANT macOS 14 has a new tool, syspolicy_check, that was specifically designed to help diagnose problems like this. I plan to update this post once I have more experience with it. In the meantime, however, if you hit a trusted execution problem and it reproduces on macOS 14, please try out syspolicy_check and let us know how that pans out. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Trusted Execution Problems macOS supports three software distribution channels: The user downloads an app from the App Store. The user gets a Developer ID-signed program directly from its developer. The user builds programs locally using Apple or third-party developer tools. The trusted execution system aims to protect users from malicious code. It’s comprised of a number of different subsystems. For example, Gatekeeper strives to ensure that only trusted software runs on a user’s Mac, while XProtect is the platform’s built-in anti-malware technology. Note To learn more about these technologies, see Apple Platform Security. If you’re developing software for macOS your goal is to avoid trusted execution entanglements. You want users to install and use your product without taking any special steps. If, for example, you ship an app that’s blocked by Gatekeeper, you’re likely to lose a lot of customers, and your users’ hard-won trust. Trusted execution problems are rare with Mac App Store apps because the Mac App Store validation process tends to catch things early. This post is primarily focused on Developer ID-signed programs. Developers who use Xcode encounter fewer trusted execution problems because Xcode takes care of many code signing and packaging chores. If you’re not using Xcode, consider making the switch. If you can’t, consult the following for information on how to structure, sign, and package your code: Placing Content in a Bundle Embedding Nonstandard Code Structures in a Bundle Embedding a Command-Line Tool in a Sandboxed App Creating Distribution-Signed Code for Mac DevForums post Packaging Mac Software for Distribution DevForums post Gatekeeper Basics User-level apps on macOS implement a quarantine system for new downloads. For example, if Safari downloads a zip archive, it quarantines that archive. This involves setting the com.apple.quarantine extended attribute on the file. Note The com.apple.quarantine extended attribute is not documented as API. If you need to add, check, or remove quarantine from a file programmatically, use the quarantinePropertiesKey property. User-level unarchiving tools preserve quarantine. To continue the above example, if you double click the quarantined zip archive in the Finder, Archive Utility will unpack the archive and quarantine the resulting files. If you launch a quarantined app, the system invokes Gatekeeper. Gatekeeper checks the app for problems. If it finds no problems, it asks the user to confirm the launch, just to be sure. If it finds a problem, it displays an alert to the user and prevents them from launching it. The exact wording of this alert varies depending on the specific problem, and from release to release of macOS, but it generally looks like the ones shown in Apple > Support > Safely open apps on your Mac. The system may run Gatekeeper at other times as well. The exact circumstances under which it runs Gatekeeper is not documented and changes over time. However, running a quarantined app always invokes Gatekeeper. Unix-y networking tools, like curl and scp, don’t quarantine the files they download. Unix-y unarchiving tools, like tar and unzip, don’t propagate quarantine to the unarchived files. Confirm the Problem Trusted execution problems can be tricky to reproduce: You may encounter false negatives, that is, you have a trusted execution problem but you don’t see it during development. You may also encounter false positives, that is, things fail on one specific Mac but otherwise work. To avoid chasing your own tail, test your product on a fresh Mac, one that’s never seen your product before. The best way to do this is using a VM, restoring to a snapshot between runs. For a concrete example of this, see Testing a Notarised Product. The most common cause of problems is a Gatekeeper alert saying that it’s blocked your product from running. However, that’s not the only possibility. Before going further, confirm that Gatekeeper is the problem by running your product without quarantine. That is, repeat the steps in Testing a Notarised Product except, in step 2, download your product in a way that doesn’t set quarantine. Then try launching your app. If that launch fails then Gatekeeper is not the problem, or it’s not the only problem! Note The easiest way to download your app to your test environment without setting quarantine is curl or scp. Alternatively, use xattr to remove the com.apple.quarantine extended attribute from the download before you unpack it. For more information about the xattr tool, see the xattr man page. Trusted execution problems come in all shapes and sizes. The remaining sections address the most common ones. App Blocked by Gatekeeper If your product is an app and it works correctly when not quarantined but is blocked by Gatekeeper when it is, you have a Gatekeeper problem. For advice on how to investigate such issues, see Resolving Gatekeeper Problems. App Can’t Be Opened Not all failures to launch are Gatekeeper errors. In some cases the app is just broken. For example: The app’s executable might be missing the x bit set in its file permissions. The app’s executable might be subtly incompatible with the current system. A classic example of this is trying to run a third-party app that contains arm64e code. macOS requires that third-party kernel extensions use the arm64e architecture. In other circumstances, stick to arm64 for your shipping products. If you want to test arm64e code locally, see Preparing Your App to Work with Pointer Authentication. The app’s executable might claim restricted entitlements that aren’t authorised by a provisioning profile. Or the app might have some other code signing problem. Note For more information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. In such cases the system displays an alert saying: The application “NoExec” can’t be opened. [[OK]] Note In macOS 11 this alert was: You do not have permission to open the application “NoExec”. Contact your computer or network administrator for assistance. [[OK]] which was much more confusing. A good diagnostic here is to run the app’s executable from Terminal. For example, an app with a missing x bit will fail to run like so: % NoExec.app/Contents/MacOS/NoExec zsh: permission denied: NoExec.app/Contents/MacOS/NoExec And an app with unauthorised entitlements will be killed by the trusted execution system: % OverClaim.app/Contents/MacOS/OverClaim zsh: killed OverClaim.app/Contents/MacOS/OverClaim In some cases running the executable from Terminal will reveal useful diagnostics. For example, if the app references a library that’s not available, the dynamic linker will print a helpful diagnostic: % MissingLibrary.app/Contents/MacOS/MissingLibrary dyld[88394]: Library not loaded: @rpath/CoreWaffleVarnishing.framework/Versions/A/CoreWaffleVarnishing … zsh: abort MissingLibrary.app/Contents/MacOS/MissingLibrary Code Signing Crashes on Launch A code signing crash has the following exception information: Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) The most common such crash is a crash on launch. To confirm that, look at the thread backtraces: Backtrace not available For steps to debug this, see Resolving Code Signing Crashes on Launch. One common cause of this problem is running distribution-signed code. Don’t do that! For details on why that’s a bad idea, see Don’t Run App Store Distribution-Signed Code. Code Signing Crashes After Launch If your program crashes due to a code signing problem after launch, you might have encountered the issue discussed in Updating Mac Software. Non-Code Signing Failures After Launch The hardened runtime enables a number of security checks within a process. Some coding techniques are incompatible with the hardened runtime. If you suspect that your code is incompatible with the hardened runtime, see Resolving Hardened Runtime Incompatibilities. App Sandbox Inheritance If you’re creating a product with the App Sandbox enabled and it crashes with a trap within _libsecinit_appsandbox, it’s likely that you’re having App Sandbox inheritance problems. For the details, see Resolving App Sandbox Inheritance Problems. Library Loading Problem Most library loading problems have an obvious cause. For example, the library might not be where you expect it, or it might be built with the wrong platform or architecture. However, some library loading problems are caused by the trusted execution system. For the details, see Resolving Library Loading Problems. Explore the System Log If none of the above resolves your issue, look in the system log for clues as to what’s gone wrong. Some good keywords to search for include: gk, for Gatekeeper xprotect syspolicy, per the syspolicyd man page cmd, for Mach-O load command oddities amfi, for Apple mobile file integrity, per the amfid man page taskgated, see its taskgated man page yara, discussed in Apple Platform Security ProvisioningProfiles Here’s a log command that I often use when I’m investigating a trusted execution problem and I don’t know here to start: % log stream --predicate "sender == 'AppleMobileFileIntegrity' or sender == 'AppleSystemPolicy' or process == 'amfid' or process == 'taskgated-helper' or process == 'syspolicyd'" For general information the system log, see Your Friend the System Log. Revision History 2024-01-12 Added a specific command to the Explore the System Log section. Change the syspolicy_check callout to reflect that macOS 14 is no longer in beta. Made minor editorial changes. 2023-06-14 Added a quick call-out to the new syspolicy_check tool. 2022-06-09 Added the Non-Code Signing Failures After Launch section. 2022-06-03 Added a link to Don’t Run App Store Distribution-Signed Code. Fixed the link to TN3125. 2022-05-20 First posted.

What is the way to update notarized app distributed outside the MAC Appstore in .zip format?

After years of working flawlessly, notarization stopped working for me. Yesterday It suddenly gave me "Team is not yet configured for notarization", I contacted developer support as advised by the eskimo (no answer yet) but upon trying again today I got the following: Error: HTTP status code: 403. A required agreement is missing or has expired. This request requires an in-effect agreement that has not been signed or has expired. Ensure your team has signed the necessary legal agreements and that they are not expired. I signed the agreement, everything looks clean and nice, no notifications about any agreement pending approval but I still get this error.

What is the proper process for notarizing an installer package? I have tried every permutation I can find and it always returns "The signature of the binary is invalid". It's a Qt6 app if that is relevant. I've bundled and signed the app using: macdeployqt myapp.app \ -always-overwrite -verbose=1 \ -hardened-runtime \ -sign-for-notarization=\"$${sign_name}\" \ It verifies OK codesign -v --verify --deep myapp.app myapp.app: valid on disk myapp.app: satisfies its Designated Requirement I have successfully notarized and stapled it: ... The staple and validate action worked! This is where I'm not sure of the proper process. I've used pkgbuild to put the app into .pkg file and successfully signed that using an Installer ID. pkgutil --check-signature myapp-signed.pkg Package "myapp-signed.pkg": Status: signed by a developer certificate issued by Apple for distribution ... On attempting to notarise this packge I get The signature of the binary is invalid for every shared library and the executable in the package. That error message is not very useful so how do I diagnose the issue? So far I've tried a few things I've found on the forum but the error is always the same unhelpful one.

Hello, I need to notarize my java application in order to upload it to brew. The files that need to notarize are: "uber.jar" file shell script file without any file type. To my understanding those files are not notarizable files, what can i do in order to solve it?

questions about Apple's notarization standards I've found that notarization seems to be based on the team ID, with a shared history. Is my understanding correct? If an app named ABC is initially notarized under team A, and then later updates are notarized under team B, will there be any issues? In my tests, notarizing the same app under teams A and B didn't cause any problems, but I'm curious about potential issues if there's a change in team IDs in the future. Is it possible to delete the notarization history or transfer it to a different team ID?

I have create an installer with self app and some app in public domain (such as GIMP). The installer and self app are all signed without error. But after notarisation, it reported that the app in public domain has error. (The signature of the binary is invalid.) But my self app has no error. I had checked the app in public domain is signed also. What is the possible problem and how can I fix it?

Greetings, everyone! In case it proves helpful, I've crafted a Bash script to streamline the notarization process. Here's a breakdown of its features: Prompts you to select the app for notarization Offers optional codesigning before notarization Generates a ZIP file for notarization Requests your credentials (Apple ID, Team ID, and app-specific password) Submits the ZIP file for notarization Cleans up by deleting the ZIP file used for notarization Staples the app after notarization Creates a new ZIP file for distribution You can check it out on GitHub: Notarization Assistant

I know I have to be doing something wrong. I've been trying notarize my app for a few days. I've bundled my app and am able to sign with hardened runtime. When I submit for notary with this command /Applications/Xcode.app/Contents/Developer/usr/bin/notarytool submit /path/to/your/file.zip --wait --key "/path/to/your/AuthKey_ABCD1234.p8" --key-id "ABCD1234" --issuer "uuid-issuer-id" it just eventually times out with no feedback or error report.

We have developed a secure desktop app using QT, we are developing and delivering this app for more than 2 years. While deploying app we perform codesigning and notarization of app and we use Ventura on build system. So the issue we observed is that if we install this app on any macOS version below Sonoma it works as expected and in Apparency we can see code signature is verified and also app in notarized. But if we install the same app on Sonoma and check in Apparency, it shows signature can't be verified.

For reasons beyond the scope of this post, I need to build one of my products on macOS 10.14 I was using xcrun altool --notarize-app but it stopped working today (per the recent announcement that it was going away, so not a surprise) I am told that it is possible to run the notarytool on 10.14, i.e. xcrun notarytool, which is what I use for builds on newer platforms. I'm hoping that someone can help me to get a version of notarytool that will run on 10.14 Thanks in advance

Throws an eroor [2023-12-07 07:55:36 UZT] DBG-X: parameter MetadataChecksum = 62c853b5b00cf96f96576b4d48ce6d0a [2023-12-07 07:55:36 UZT] DBG-X: parameter MetadataCompressed = (suppressed) [2023-12-07 07:55:36 UZT] DBG-X: parameter MetadataInfo = {app_platform=osx, primary_bundle_identifier=ocean.drive.app, device_id=, bundle_identifier=, packageVersion=software5.9, apple_id=, asset_types=[developer-id-package], bundle_version=, bundle_short_version_string=} [2023-12-07 07:55:36 UZT] DBG-X: parameter OSIdentifier = Mac OS X 12.2.1 (x86_64); jvm=14.0.2+12-iTunesOpenJDK-8; jre=14.0.2+12-iTunesOpenJDK-8 [2023-12-07 07:55:36 UZT] DBG-X: parameter PackageName = 0b641208d73f17697b28370fa99ad8a7.itmsp [2023-12-07 07:55:36 UZT] DBG-X: parameter PackageSize = 228662271 [2023-12-07 07:55:36 UZT] DBG-X: parameter StatisticsClientStartDateTimeZoneISO = 2023-12-07T07:55:36+05:00 [2023-12-07 07:55:36 UZT] DBG-X: parameter TransporterArguments = -m upload -u @@@@ -vp json -DTxHeaders=eyJqZW5nYSI6dHJ1ZX0= -sessionid @env:8A006125-AC15-400B-9FC2-C4D609DB7FA1 -sharedsecret hidden value -itc_provider PROVIDER -f /var/folders/g9/kz8cw8b57rg14vlnwhc77j840000gn/T/F75419E9-DDDB-4F74-BC71-B970FD924FB4/0b641208d73f17697b28370fa99ad8a7.itmsp -indicator true -v eXtreme -Dtransporter.client=altool -Dtransporter.client.version=5.329 (1309) [2023-12-07 07:55:36 UZT] DBG-X: parameter Version = 3.3.0 [2023-12-07 07:55:36 UZT] DBG-X: parameter iTMSTransporterMode = upload [2023-12-07 07:55:36 UZT] INFO: id = 20231207075536-140 [2023-12-07 07:55:36 UZT] INFO: iTMSTransporter Correlation Key: f33460ff-fc03-4158-bed2-b2e99ffd521c-0001 [2023-12-07 07:55:36 UZT] DEBUG: SMART-CLIENT: Host HTTP header: contentdelivery01.itunes.apple.com [2023-12-07 07:55:36 UZT] DBG-X: Apple's web service operation return value: [2023-12-07 07:55:36 UZT] DBG-X: parameter Errors = [Unable to process validateMetadata request at this time due to a general error (1019)] [2023-12-07 07:55:36 UZT] DBG-X: parameter RestartClient = false [2023-12-07 07:55:36 UZT] DBG-X: parameter ErrorCode = 1019 [2023-12-07 07:55:36 UZT] DBG-X: parameter ErrorMessage = Unable to process validateMetadata request at this time due to a general error (1019) [2023-12-07 07:55:36 UZT] DBG-X: parameter ShouldUseRESTAPIs = false [2023-12-07 07:55:36 UZT] DBG-X: parameter Success = false [2023-12-07 07:55:36 UZT] ERROR: Unable to process validateMetadata request at this time due to a general error (1019) [2023-12-07 07:55:36 UZT] DBG-X: The error code is: 1019 [2023-12-07 07:55:36 UZT] INFO: JSON:{"msg":{"phase":"Upload","count":2,"description":"Operation failed","index":2},"messageType":"VerifyProgress"} [2023-12-07 07:55:36 UZT] DBG-X: Returning 1 2023-12-07 07:55:36.750 Out: Package Summary: 1 package(s) were not uploaded because they had problems: /var/folders/g9/kz8cw8b57rg14vlnwhc77j840000gn/T/F75419E9-DDDB-4F74-BC71-B970FD924FB4/0b641208d73f17697b28370fa99ad8a7.itmsp - Error Messages: Unable to process validateMetadata request at this time due to a general error (1019) 2023-12-07 07:55:36.797 *** Error: Notarization failed for '/var/folders/g9/kz8cw8b57rg14vlnwhc77j840000gn/T/electron-notarize-LC5Kmm/OceanDrive.zip'. 2023-12-07 07:55:36.797 *** Error: Unable to process validateMetadata request at this time due to a general error (1019) (1019) 2023-12-07 07:55:36.797 *** Warning: altool has been deprecated for notarization and starting in late 2023 will no longer be supported by the Apple notary service. You should start using notarytool to notarize your software. (-1030)

Hi Guys, I am facing a problem I find difficult to debug. I had a company Apple ID, member of team, that I used for notaryzation of an app via: res=$(xcrun notarytool submit ${file_to_notarize} --apple-id stepan.svoboda@memsource.com --password ${password} --team-id PK8H4S4HPF --wait 2>&1) But I will be leaving the company soon so we created new apple ID. desktop@phrase.com We invited this ID to team. And assigned it admin role. I generated app specific password and I am using it with this new apple ID But then running: res=$(xcrun notarytool submit ${file_to_notarize} --apple-id desktop@phrase.com --password ${password} --team-id PK8H4S4HPF --wait 2>&1) Fails with: Error: HTTP status code: 401. Unable to authenticate. Invalid session. Ensure that all authentication arguments are correct. And I run out of ideas what to check, what could be wrong.

Hi, I want to use notarytool to let my installer *pkg being notarized by apple. The app is a swift desktop app, not supposed to be distributed through the app store. It is already signed and notarized through xcode. Verification done and it has been aproved. So the process should be working. I'm facing an issue when using notarytool to store cretentials. I followed the steps for described here https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow My app specific password I created here: https://appleid.apple.com/account/manage When I try to strore credentials I get a 401, what did I miss here? xcrun notarytool store-credentials --verbose [07:21:52.672Z] Debug [MAIN] Running notarytool version: 1.0.0 (32), date: 2023-12-01T07:21:52Z, command: /Applications/Xcode.app/Contents/Developer/usr/bin/notarytool store-credentials --verbose This process stores your credentials securely in the Keychain. You reference these credentials later using a profile name. Profile name: notarytool-pw We recommend using App Store Connect API keys for authentication. If you'd like to authenticate with an Apple ID and app-specific password instead, leave this unspecified. Path to App Store Connect API private key: Switching prompts to app-specific password credentials. Developer Apple ID: <my developer Apple ID> App-specific password for <my developer Apple ID>: <the app specific password I created earlier> Developer Team ID: <my developer team ID> Validating your credentials... [07:31:40.888Z] Info [API] Initialized Notary API with base URL: https://appstoreconnect.apple.com/notary/v2/ [07:31:40.890Z] Info [API] Preparing GET request to URL: https://appstoreconnect.apple.com/notary/v2/test?, Parameters: [:], Custom Headers: private<Dictionary<String, String>> [07:31:40.890Z] Debug [AUTHENTICATION] Delaying current request to refresh app-specific password token. [07:31:40.891Z] Info [API] Preparing GET request to URL: https://appstoreconnect.apple.com/notary/v2/asp?, Parameters: [:], Custom Headers: private<Dictionary<String, String>> [07:31:40.891Z] Debug [AUTHENTICATION] Authenticating request to '/notary/v2/asp' with Basic Auth. Username: <my developer Apple ID>, Password: private<String>, Team ID: <my developer team ID> [07:31:40.892Z] Debug [TASKMANAGER] Starting Task Manager loop to wait for asynchronous HTTP calls. [07:31:41.921Z] Debug [API] Received response status code: 401, message: unauthorized, URL: https://appstoreconnect.apple.com/notary/v2/asp?, Correlation Key: 6WYAHNFB6NYEVPPJOT5KJMNPAE [07:31:41.922Z] Error [TASKMANAGER] Completed Task with ID 2 has encountered an error. [07:31:41.922Z] Debug [TASKMANAGER] Ending Task Manager loop. Error: HTTP status code: 401. Unable to authenticate. Invalid session. Ensure that all authentication arguments are correct.

I am trying to package a Mac Electron app using Electron Forge capabilities. Code signing works fine, but there is a problem with notarising. I get "Finalizing package Failed to staple your application with code: 65". The notarize component of my forge.config.js is: "osxNotarize: { tool: 'notarytool', appBundleId: 'com.ImmersiveDSP.ImmerGo-StudioLive', appleId: process.env.APPLE_ID, appleIdPassword: process.env.APPLE_PASSWORD, teamId: process.env.APPLE_TEAM_ID, }" I provide my Apple ID and the app password in a terminal message together with npm run make. This worked in May this year, but now not. In a JSON response, I do get " reason = "Record not found". Anyone else had this issue and resolved it? Is there a way that I can view my notarize requests and see what the issue is?

Notarizing was working fine on my account, but suddenly stopped working with this error message. I've contacted Apple Developer Program support and they told me it's an internal issue on their side, that their engineers are working on it and that they'll answer me when the engineers have an answer. The thing is, this thing has been going for 3 months. Every time I email the support I get a bot message saying "our engineers are looking into it". And my account still is unable to notarize my app. What's going on? I've message several other Apple Developers and none of them had to deal with this. Why is this happening to my account? This is blocking the launch of my project(https://focuslit.app), which I worked months and have costumers asking about the new features, but I can't release a new version without notarizing. What can I do? I'm seriously thinking about refunding everyone and dropping the project, I never felt this mistreated by a company(which I have all products and used to love) before.