Notarization for macOS 10.14.5+: what changed

Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		## Overview
2	2
3	3		Beginning with macOS 10.14.5 (Mojave), software signed with a new Apple developer certificate and all new or updated kernel extensions must be notarized to run. Beginning in macOS 10.15 (Catalina), all software built after June 1, 2019, and code signed with an Apple developer certificate must be notarized. Notarization is not required for software distributed through the Apple App Store because the App Store submission process already includes equivalent security checks.
4	4
5	5		In November 2023, Apple amended the Notarizing process and rules, and changed the utility program to notarytool. These changes are now shown below.
6	6
7	7		Notarization is designed by Apple to give users more confidence that Apple developer-signed software has been checked by Apple for malicious components. Notarization is not an App Review. The Apple notary service is an automated system that scans software for malicious content, checks for code-signing issues, and returns the results. If there are no issues, the notary service generates a ticket to staple to the software; the notary service also publishes that ticket online where Gatekeeper can find it.
8	8
9	9		When the user first installs or runs software, the presence of a ticket (either online or attached to the executable) tells Gatekeeper that Apple notarized the software. Gatekeeper then places descriptive information in the initial launch dialog to help the user make an informed choice about whether to launch the app.
10	10
11	11		> Note: *Even if an application has not been notarized, it can still be run by control-clicking on the app, or right clicking for the context menu, and choosing Open* - see the Gatekeeper "bypass" dialog in the gallery [[Notarization for macOS 10.14.5+\|below]].**
12	12
13	13		Code signing an application without also notarizing it is now a totally pointless exercise unless you are only distributing your application via the App Store.
14	14
15	15		## Gatekeeper dialogs
16	16
17		-	<File:macos-mojave-app-downloaded-from-internet-alert-dark.jpg%7CGatekeeper> Dialog before Catalina where an app that is not notarized is first opened (Mojave macOS 10.14 dialog) <File:Screenshot_2020-01-02_at_22.42.01.png%7CGatekeeper> dialog where an app which is signed and notarized is first opened (Catalina macOS 10.15.1 dialog) <File:gatekeep_no.png%7CGatekeeper> dialog where an app is not signed nor notarized is first opened (Catalina macOS 10.15.1 dialog) <File:macos-catalina-alert-unsigned-override.jpg%7CThe> Gatekeeper "bypass" dialog, accessed by control-clicking on the app (Catalina macOS 10.15.3 dialog)
	17	+	![](/wiki-images/2/29/Macos-mojave-app-downloaded-from-internet-alert-dark.jpg)
	18	+
	19	+	Gatekeeper Dialog before Catalina where an app that is not notarized is first opened (Mojave macOS 10.14 dialog)
	20	+
	21	+	![](/wiki-images/c/c6/Screenshot_2020-01-02_at_22.42.01.png)
	22	+
	23	+	Gatekeeper dialog where an app which is signed and notarized is first opened (Catalina macOS 10.15.1 dialog)
	24	+
	25	+	![](/wiki-images/4/4a/Gatekeep_no.png)
	26	+
	27	+	Gatekeeper dialog where an app is not signed nor notarized is first opened (Catalina macOS 10.15.1 dialog)
	28	+
	29	+	![](/wiki-images/2/21/Macos-catalina-alert-unsigned-override.jpg)
	30	+
	31	+	The Gatekeeper "bypass" dialog, accessed by control-clicking on the app (Catalina macOS 10.15.3 dialog)
18	32
19	33		## Notarization requirements
20	34
21	35		Notarization requires the Xcode command line tools from Xcode 10 or later. Building a new app for notarization requires macOS 10.13.6 or later. Stapling an app requires macOS 10.12 or later.
22	36
23	37		Apple's notary service requires you to:
24	38
25	39		- Enable code-signing for all of the executables you distribute.
26	40		- Enable the [[Hardened runtime for macOS\|Hardened Runtime]] capability for your application and command line targets.
27	41		- Use a “Developer ID” application, kernel extension, or installer certificate for your code-signing signature.
28	42		- Include a secure timestamp with your code-signing signature (include the --timestamp option when running the codesign tool).
29	43		- Don’t include the com.apple.security.get-task-allow entitlement with the value set to any variation of true. If your software hosts third-party plug-ins and needs this entitlement to debug the plug-in in the context of a host executable, see [Avoid the Get-Task-Allow Entitlement](https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087731).
30	44		- Link against the macOS 10.9 or later SDK.
31	45
32	46		On 3 September 2019 Apple announced that until January 2020 developers could get new versions of applications notarized even though they were not [[Hardened runtime for macOS\|hardened]] or fully compliant with the normal requirements. That deadline was later extended to 3 February 2020. The above notarization requirements are now in full effect.
33	47
34	48		### Apple Statement 23 December 2019
35	49
36	50		In June, we announced that all Mac software distributed outside the Mac App Store must be notarized by Apple in order to run by default on macOS Catalina. In September, we temporarily adjusted the notarization prerequisites to make this transition easier and to protect users on macOS Catalina who continue to use older versions of software. Starting February 3, 2020, all submitted software must meet the original notarization prerequisites.
37	51
38	52		If you haven’t yet done so, upload your software to the notary service and review the developer log for warnings. These warnings will become errors starting February 3 and must be fixed in order to have your software notarized. Software notarized before February 3 will continue to run by default on macOS Catalina.
39	53
40	54		As a reminder, all installer packages must be signed since they may contain executable code. Disk images do not need to be signed, although signing them can help your users verify their contents.
41	55
42	56		## Notarizing an application
43	57
44	58		These instructions assume you have completed the other preparatory steps: [[Code Signing for macOS\|code signed]] the application, implemented the [[Hardened runtime for macOS\|hardened runtime capability]], [[Code Signing for macOS\|code signed]] the installer pkg (if you have one) etc.
45	59
46	60		You can't upload the .app bundle directly to the notary service, you need to create a compressed archive containing the application or you can put applications, kernel extensions, and other software in a container, like a disk image, and notarize the container. The notary service accepts disk images (UDIF format), signed flat installer packages, and ZIP archives. It processes nested containers as well, like packages inside a disk image.
47	61
48	62		### Step 1 - Create disk image
49	63
50	64		Create a disk image by opening a Terminal and running the following command:
51	65
52	66		``` bash
53	67		hdiutil create -volname MyApp -srcfolder /path/to/MyApp.app -ov -format UDBZ MyApp.dmg
54	68		```
55	69
56	70		### Step 2 - Code sign the disk image
57	71
58	72		Disk images must be signed with your Developer ID Application Certificate and include a secure timestamp.
59	73
60	74		Code sign the disk image by opening a Terminal and running the following command:
61	75
62	76		``` bash
63	77		codesign -s "Developer ID Application: Your Name (Team ID)" --timestamp MyApp.dmg
64	78		```
65	79
66	80		Note: See [[Code Signing for macOS]] for more details relevant to code signing especially if doing this on aarch64 for an x86_64 binary.
67	81
68	82		### Step 3 - Generate an app-specific password
69	83
70	84		To generate an app-specific password, refer to this [Apple Support article](https://support.apple.com/en-us/HT204397). Note: this is a password that will be specific to the notarization application (xcrun notarytool) and not to the application being notarized. You therefore only need to do this once, but make sure you copy the generated password and save it somewhere.
71	85
72	86		> Tip: Save the password to your keychain with:\
73	87		> \
74	88		> `xcrun notarytool store-credentials "notarytool-password" --apple-id "<AppleID>" --team-id <DeveloperTeamID> --password <secret_2FA_password>`\
75	89		> \
76	90		> and then you can use `"@keychain:<name for pwd>"` in the following commands.
77	91
78	92		### Step 4 - Upload the disk image to the notary service
79	93
80	94		> Note: When you notarize the container disk image, notarytool also notarizes the application inside, so you can skip the step of notarizing the application itself.
81	95
82	96		Upload the disk image file to the Apple notary service by opening a Terminal and running the following command:
83	97
84	98		``` bash
85	99		xcrun notarytool submit --apple-id "me@mysoftware.com" --password <app-specifc-password> --team-id <your 10 character team ID> /Path/to/MyApp.dmg
86	100		```
87	101
88	102		The response includes an id (session-ID) that we use later to keep track of this submission with the notarization service. It will be used again to check on the status.
89	103
90	104		If the upload is successful you should receive output similar to the following:
91	105
92	106		Conducting pre-submission checks for MyApp.dmg and initiating connection to the Apple notary service...
93	107		Submission ID received
94	108		id: 43e04940-1601-4959-a40c-79b83172d22b
95	109		Upload progress: 100,00% (3,97 MB of 3,97 MB)
96	110		Successfully uploaded file
97	111		id: 43e04940-1601-4959-a40c-79b83172d22b
98	112		path: /Path/to/MyApp.dmg
99	113
100	114		### Step 5 - Check the notarization process
101	115
102	116		The notarization process generally takes less than an hour, and usually just few minutes. They no longer issue emails, so you will need to check its progress from time to time by opening a Terminal and running the following command:
103	117
104	118		``` bash
105	119		xcrun notarytool info --apple-id "me@mysoftware.com" --password <app-specifc-password> --team-id <your 10 character team ID> session-ID
106	120		```
107	121
108	122		When the notarization process completes successfully the above command will return information similar to the following:
109	123
110	124		Looking up : 43e04940-1601-4959-a40c-79b83172d22b
111	125		Successfully received submission info
112	126		createdDate: 2024-05-06T10:16:46.448Z
113	127		id: 43e04940-1601-4959-a40c-79b83172d22b
114	128		name: MyApp.dmg
115	129		status: Accepted
116	130
117	131		The possible status results are: In process, Accepted or Failure.
118	132
119	133		Accepted means success in this context. If the status is failure, then further details can be obtained with the "log" command:
120	134
121	135		``` bash
122	136		xcrun notarytool log --apple-id "me@mysoftware.com" --password <app-specifc-password> --team-id <your 10 character team ID> session-ID
123	137		```
124	138
125	139		### Step 6 - Staple the ticket to the disk image
126	140
127	141		The notarization process produces a ticket that tells Gatekeeper that your application is notarized. After notarization completes successfully, the next time any user attempts to run your application on macOS 10.14 or later, Gatekeeper will find the ticket online. This includes users who downloaded your application before notarization.
128	142
129	143		After step 5 receives the "Package Approved" status message, you should also attach the ticket to the disk image file using the stapler tool, so that future distributions include the ticket. This ensures that Gatekeeper can find the ticket even when a network connection is not available.
130	144
131	145		To staple the ticket to the disk image file, open a Terminal and run the following command:
132	146
133	147		``` bash
134	148		xcrun stapler staple /path/to/MyApp.dmg
135	149		```
136	150
137	151		If the command completes successfully, the output should be similar to:
138	152
139	153		Processing: /Path/to/MyApp.dmg
140	154		Processing: /Path/to/MyApp.dmg
141	155		The staple and validate action worked!
142	156
143	157		Note: While you can staple an installer package and disk image directly, if notarization used a zip file, the application bundle needs to be unzipped and then it can be stapled and rezipped.
144	158
145	159		### Step 7 - Verify notarization of the disk image
146	160
147	161		To verify the notarization of the disk image, open a Terminal and run the following command:
148	162
149	163		``` bash
150	164		spctl -a -vv -t install MyApp.dmg
151	165		```
152	166
153	167		A successful verification of the notarization process should produce output similar to the following:
154	168
155	169		MyApp.dmg: accepted
156	170		source=Notarized Developer ID
157	171		origin=Developer ID Application: <Developer Name> (<TEAM_ID>)
158	172
159	173		### Step 8 - Verify notarization of the application
160	174
161	175		To verify the notarization of the application, install the application, open a Terminal and run the following command:
162	176
163	177		``` bash
164	178		spctl -a -vv /Applications/MyApp.app
165	179		```
166	180
167	181		A successful verification of the notarization process should produce output similar to the following:
168	182
169	183		/Applications/MyApp.app: accepted
170	184		source=Notarized Developer ID
171	185		origin=Developer ID Application: <Developer Name> (<TEAM_ID>)
172	186
173	187		Important: test the application by putting it in the Applications directory. It's treated differently by the Gatekeeper when in the "installed" location.
174	188
175	189		Alternatively, the Apple-recommended way to verify the notarization of an application is to open a Terminal and run the following command:
176	190
177	191		xcrun stapler validate MyApp.app
178	192
179	193		A successful verification of the notarization process should produce output similar to the following:
180	194
181	195		Processing: MyApp.app
182	196		The validate action worked!
183	197
184	198		## Notarizing a command line tool
185	199
186	200		Command line tools can be code signed, but they cannot be easily notarized because they do not have an [[Application Bundle]] and a standalone `Info.plist` [[macOS property list files\|property list file]]. You can relatively easily insert an `Info.plist` file in your command line tool executable.
187	201
188	202		### Inserting an Info.plist in a command line executable
189	203
190	204		Here is a template that you can customise for your command line utility. I extracted it from a command line utility executable written in C named "simplereach" which I built with Xcode 11.3.1 on Mojave after enabling the "Create Info.plist Section in Binary" under the "Packaging" options (I have omitted the unnecessary Xcode-related build info from it).
191	205
192	206		``` xml
193	207		<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
194	208		<plist version="1.0">
195	209		<dict>
196	210		<key>BuildMachineOSBuild</key>
197	211		<string>18G8022</string>
198	212		<key>CFBundleDevelopmentRegion</key>
199	213		<string>English</string>
200	214		<key>CFBundleDocumentTypes</key>
201	215		<array>
202	216		<dict>
203	217		<key>CFBundleTypeOSTypes</key>
204	218		<array>
205	219		<string>fold</string>
206	220		<string>disk</string>
207	221		<string>****</string>
208	222		</array>
209	223		</dict>
210	224		</array>
211	225		<key>CFBundleExecutable</key>
212	226		<string>simplereach</string>
213	227		<key>CFBundleIdentifier</key>
214	228		<string>com.mycompany.simplereach</string>
215	229		<key>CFBundleInfoDictionaryVersion</key>
216	230		<string>6.0</string>
217	231		<key>CFBundleName</key>
218	232		<string>simplereach</string>
219	233		<key>CFBundlePackageType</key>
220	234		<string>APPL</string>
221	235		<key>CFBundleShortVersionString</key>
222	236		<string>1.0</string>
223	237		<key>CFBundleSupportedPlatforms</key>
224	238		<array>
225	239		<string>MacOSX</string>
226	240		</array>
227	241		<key>CFBundleVersion</key>
228	242		<string>1</string>
229	243		<key>LSMinimumSystemVersion</key>
230	244		<string>10.14</string>
231	245		</dict>
232	246		</plist>
233	247		```
234	248
235	249		You will need to modify a few key strings in the above file. Substitute your own:
236	250
237	251		- BuildMachineOSBuild string can be obtained from a Terminal with the command `sw_vers`. The "18G8022" strong is for Mojave 10.14.6.
238	252		- CFBundleDevelopmentRegion string if it is not "English".
239	253		- CFBundleExecutable string with your utility name.
240	254		- CFBundleIdentifier string (conventionally your domain name in reverse followed by utility name; feel free use anything unique).
241	255		- CFBundleName string (use the same value as for CFBundleExecutable).
242	256		- CFBundleShortVersionString string with your version number.
243	257		- LSMinimumSystemVersion string with the minimum macOS version on which your utility will run.
244	258
245	259		You can then insert the `Info.plist` file into your application by telling the linker to add it as a __TEXT section named __info_plist:
246	260
247	261		`fpc -k"-sectcreate __TEXT __info_plist Info.plist" my_utility.pas`
248	262
249	263		To check whether it has been successfully inserted you can run the following command in a Terminal:
250	264
251	265		`otool -X -v -s __TEXT __info_plist my_utility`
252	266
253	267		### Signing a command line executable
254	268
255	269		Now that the `Info.plist` file has been inserted in the executable, you are ready to code sign it by executing the following commands in a Terminal:
256	270
257	271		`cd /path/to/my_utility`\
258	272		`mkdir bin`\
259	273		`mv my_utility bin/`\
260	274		`codesign -f --strict --timestamp --options=runtime -s "Developer ID Application: YOUR NAME (TEAM_ID)" bin/my_utility`
261	275
262	276		It is critical that you create the `bin` directory and move your utility to it before signing. Failure to do so will result in a `_CodeSignature directory` being created which is not appropriate for a command line utility and the notarisation process will fail.
263	277
264	278		To verify this was successful you can run the following command in a Terminal:
265	279
266	280		`codesign -vv bin/my_utility`
267	281
268	282		If code signing was successful, the output should be something similar to:
269	283
270	284		`my_utility: valid on disk`\
271	285		`my_utility: satisfies its Designated Requirement `
272	286
273	287		### Submitting a command line executable for notarization
274	288
275	289		As you cannot notarize a bare executable, you need to incorporate it into a container (.dmg - Disk Image, .pkg - Installer Package, or a ZIP archive file). A ZIP archive is the simplest so in a Terminal execute the following command:
276	290
277	291		`zip my_utility.zip bin/my_utility`
278	292
279	293		You are now ready to upload your command line utility to Apple's servers for notarization. In a terminal execute the following command:
280	294
281	295		`xcrun notarytool submit --apple-id "me@mysoftware.com" --password <app-specifc-password> --team-id <your 10 character team ID> my_utility.zip`
282	296
283	297		If you do not already have an app specific password, see above for how to generate one.
284	298
285	299		The response includes an id (session-ID) that we use later to keep track of this submission with the notarization service. It will be used again to check on the status.
286	300
287	301		If the upload is successful you should receive output similar to the following:
288	302
289	303		Conducting pre-submission checks for my_utility.zip and initiating connection to the Apple notary service...
290	304		Submission ID received
291	305		id: 43e04940-1601-4959-a40c-79b83172d22b
292	306		Upload progress: 100,00% (3,97 MB of 3,97 MB)
293	307		Successfully uploaded file
294	308		id: 43e04940-1601-4959-a40c-79b83172d22b
295	309		path: /Path/to/my_utility.zip
296	310
297	311		### Checking the notarization progress
298	312
299	313		The notarization process generally takes less than an hour, and usually just few minutes. They no longer issue emails, so you will need to check its progress from time to time by opening a Terminal and running the following command:
300	314
301	315		``` bash
302	316		xcrun notarytool info --apple-id "me@mysoftware.com" --password <app-specifc-password> --team-id <your 10 character team ID> session-ID
303	317		```
304	318
305	319		When the notarization process completes successfully the above command will return information similar to the following:
306	320
307	321		Looking up : 43e04940-1601-4959-a40c-79b83172d22b
308	322		Successfully received submission info
309	323		createdDate: 2024-05-06T10:16:46.448Z
310	324		id: 43e04940-1601-4959-a40c-79b83172d22b
311	325		name: MyApp.dmg
312	326		status: Accepted
313	327
314	328		The possible status results are: In process, Accepted or Failure. Accepted means success in this context. If the status is failure, then further details can be obtained with the "log" command:
315	329
316	330		``` bash
317	331		xcrun notarytool log --apple-id "me@mysoftware.com" --password <app-specifc-password> --team-id <your 10 character team ID> session-ID
318	332		```
319	333
320	334		In case of a notarization failure, consult Troubleshooting below for help.
321	335
322	336		### Verifying notarization of a command line executable
323	337
324	338		To verify the notarization of a command line tool, open a Terminal and run the following command:
325	339
326	340		`spctl -a -t open --context context:primary-signature -vv my_utility `
327	341
328	342		A successful verification of a properly notarized command line executable should produce output similar to the following:
329	343
330	344		`my_utility: accepted`\
331	345		`source=Notarized Developer ID`\
332	346		`origin=Developer ID Application: Your Name (Z9HBGNDZZ9)`
333	347
334	348		## Troubleshooting
335	349
336	350		### Notarization upload process
337	351
338	352		If the notarisation upload process does not go well, you should be able to find a compressed log file in your temporary directory which may shed some light on what happened. You can view it by opening a Terminal and running the following commands (substitute the name of your log file which includes your application bundle-id):
339	353
340	354		``` bash
341	355		cd ${TMPDIR}
342	356		gzcat c51ca05f-cf49-405f-be57-26873faab5f6_3073718126753816760org.sentry.myapp-20191231004646-273.itmsp6022059143057318377.log
343	357		```
344	358
345	359		which, for a successful notarization upload, should look similar to:
346	360
347	361		` [2019-12-31 19:46:46 AEDT] <main> INFO: Starting upload for packageName: org.sentry.myapp-20191231004646-273.itmsp`\
348	362		` [2019-12-31 19:46:46 AEDT] <main> INFO: Thread Pool Configuration: {processors=12, perCoreThreadMultiplier=1.65, coreThreads=6, maxThreads=14, minConnections=6, maxConnections=13, rateLimit=100000000000 KBs}`\
349	363		` [2019-12-31 19:46:46 AEDT] <main> INFO: Reservation CPUSource113/v4/93/41/ce/9341ce96-e7bc-2577-eaac-4528c888a70d/metadata.xml created for file: (metadata.xml), part count:(1), file size: (538)`\
350	364		` [2019-12-31 19:46:46 AEDT] <main> INFO: Reservation CPUSource113/v4/93/41/ce/9341ce96-e7bc-2577-eaac-4528c888a70d/MyApp_31122019.dmg created for file: (MyApp_31122019.dmg), part count:(1), file size: (1400933)`\
351	365		` [2019-12-31 19:46:46 AEDT] <RLT-002> INFO: Starting upload for reservation: (CPUSource113/v4/93/41/ce/9341ce96-e7bc-2577-eaac-4528c888a70d/metadata.xml) file: (metadata.xml/1) size: 538`\
352	366		` [2019-12-31 19:46:46 AEDT] <RLT-003> INFO: Starting upload for reservation: (CPUSource113/v4/93/41/ce/9341ce96-e7bc-2577-eaac-4528c888a70d/myapp_31122019.dmg) file: (MyApp_31122019.dmg/1) size: 1400933`\
353	367		` [2019-12-31 19:46:47 AEDT] <RLT-002> INFO: Finished part upload for: (metadata.xml/1) 2.91 KB/s in 0 seconds`\
354	368		` [2019-12-31 19:46:47 AEDT] <RLT-002> INFO: Finished upload for reservation: (CPUSource113/v4/93/41/ce/9341ce96-e7bc-2577-eaac-4528c888a70d/metadata.xml) file: (metadata.xml)`\
355	369		` [2019-12-31 19:46:47 AEDT] <pool-8-thread-1> INFO: Reservation committed: (CPUSource113/v4/93/41/ce/9341ce96-e7bc-2577-eaac-4528c888a70d/metadata.xml) file: (metadata.xml)`\
356	370		` [2019-12-31 19:46:49 AEDT] <RLT-003> INFO: Finished part upload for: (MyApp_31122019.dmg/1) 781.33 KB/s in 1 second`\
357	371		` [2019-12-31 19:46:49 AEDT] <RLT-003> INFO: Finished upload for reservation: (CPUSource113/v4/93/41/ce/9341ce96-e7bc-2577-eaac-4528c888a70d/MyApp_31122019.dmg) file: (MyApp_31122019.dmg)`\
358	372		` [2019-12-31 19:46:49 AEDT] <main> INFO: Waiting on reservation commit(s) to finish.`\
359	373		` [2019-12-31 19:46:49 AEDT] <pool-8-thread-1> INFO: Reservation committed: (CPUSource113/v4/93/41/ce/9341ce96-e7bc-2577-eaac-4528c888a70d/MyApp_31122019.dmg) file: (MyApp_31122019.dmg)`\
360	374		` [2019-12-31 19:46:49 AEDT] <pool-8-thread-1> INFO: All reservation commit(s) finished.`\
361	375		` [2019-12-31 19:46:49 AEDT] <main> INFO: 456.36 KB/s in 3 seconds`
362	376
363	377		### Notarization process failures
364	378
365	379		If the when you check you find that the notarization process has failed. For example:
366	380
367	381		Date RequestUUID Status Status Code Status Message
368	382		------------------------- ------------------------------------ ------- ----------- ----------------
369	383		2020-02-29 13:54:08 +0000 fa2e5d79-cba0-469d-bb27-859a8f081821 invalid 2 Package Invalid
370	384
371	385		You can retrieve the URL for the notarization log file with the command:
372	386
373	387		``` bash
374	388		xcrun notarytool log --apple-id "me@mysoftware.com" --password <app-specifc-password> --team-id <your 10 character team ID> session-ID
375	389		```
376	390
377	391		which should yield information similar to the following:
378	392
379	393		No errors getting notarization info.
380	394
381	395		Date: 2020-02-29 13:54:08 +0000
382	396		Hash: 1b08ea5cdf97eb6fed9b959a549d4b325eb5e90f16538139a29a83f75609d87b
383	397		LogFileURL: https://osxapps-ssl.itunes.apple.com/itunes-assets/[...]
384	398		RequestUUID: fa2e5d79-cba0-469d-bb27-859a8f081821
385	399		Status: invalid
386	400		Status Code: 2
387	401		Status Message: Package Invalid
388	402
389	403		You can then cut and paste the LogFileURL into your web browser and retrieve the notarization process log file which will look something like this:
390	404
391	405		{
392	406		"logFormatVersion": 1,
393	407		"jobId": "fa2e5d79-cba0-469d-bb27-859a8f081821",
394	408		"status": "Invalid",
395	409		"statusSummary": "Archive contains critical validation errors",
396	410		"statusCode": 4000,
397	411		"archiveFilename": "test.dmg",
398	412		"uploadDate": "2020-02-29T13:54:08Z",
399	413		"sha256": "1b08ea5cdf97eb6fed9b959a549d4b325eb5e90f16538139a29a83f75609d87b",
400	414		"ticketContents": null,
401	415		"issues": [
402	416		{
403	417		"severity": "error",
404	418		"code": null,
405	419		"path": "test.dmg/MyApp.app/Contents/MacOS/MyApp",
406	420		"message": "The executable does not have the hardened runtime enabled.",
407	421		"docUrl": null,
408	422		"architecture": "x86_64"
409	423		}
410	424		]
411	425		}
412	426
413	427		In the above failure case, it was because the executable had not been [[Hardened runtime for macOS\|hardened]].
414	428
415	429		It is also worthwhile mentioning that it is always worth retrieving the notarization log file to check for warnings which are not yet errors so that you can fix them before they do become errors which prevent successful notarization.
416	430
417	431		Here is an example of a notarization process log from a successful notarization:
418	432
419	433		{
420	434		"logFormatVersion": 1,
421	435		"jobId": "fa2e5d79-cba0-469d-bb27-859a8f081822",
422	436		"status": "Accepted",
423	437		"statusSummary": "Ready for distribution",
424	438		"statusCode": 0,
425	439		"archiveFilename": "test.dmg",
426	440		"uploadDate": "2020-03-01T01:50:55Z",
427	441		"sha256": "1945554c24da3bb1d587b7c9f968dcbb925b726f2f663b816301928c06593dd9",
428	442		"ticketContents": [
429	443		{
430	444		"path": "test.dmg",
431	445		"digestAlgorithm": "SHA-256",
432	446		"cdhash": "1d4d033edbecc2baf7ff8ce0fa16691be990595f"
433	447		},
434	448		{
435	449		"path": "test.dmg/MyApp.app",
436	450		"digestAlgorithm": "SHA-256",
437	451		"cdhash": "7f9d54e76f25807e2b425a09684aa8cb54dcd17f",
438	452		"arch": "x86_64"
439	453		},
440	454		{
441	455		"path": "test.dmg/MyApp.app/Contents/MacOS/MyApp",
442	456		"digestAlgorithm": "SHA-256",
443	457		"cdhash": "7f9d54e762c7907e2b425a09684aa8cb54dcd17f",
444	458		"arch": "x86_64"
445	459		},
446	460		{
447	461		"path": "test.dmg/MyApp.app/Contents/Resources/MyApp.help",
448	462		"digestAlgorithm": "SHA-256",
449	463		"cdhash": "b544a32a216578e7805ca93b968377cdd92f7ec6",
450	464		"arch": "i386"
451	465		},
452	466		{
453	467		"path": "test.dmg/MyApp.app/Contents/Resources/MyApp.help",
454	468		"digestAlgorithm": "SHA-256",
455	469		"cdhash": "b544a32a216578e7805ca93b968377cdd92f7ec6",
456	470		"arch": "x86_64"
457	471		},
458	472		{
459	473		"path": "test.dmg/MyApp.app/Contents/Resources/MyApp.help",
460	474		"digestAlgorithm": "SHA-256",
461	475		"cdhash": "b544a32a216578e7805ca93b968377cdd92f7ec6",
462	476		"arch": "x86_64h"
463	477		}
464	478		],
465	479		"issues": null
466	480		}
467	481
468	482		### Notarization check failures
469	483
470	484		If the notarization process succeeds, but when you check whether your application is properly notarized and it does not pass the notarization check successfully, you can use the `Console.app` to inspect the log files for information about the rejection (after trying to launch the blocked application). Be aware you should open the `Console.app` before trying to open your blocked application, otherwise not all messages may be logged. You should choose your device in the left sidebar of the `Console.app` and check for the process XprotectService in the logs.
471	485
472	486		## See also
473	487
474	488		- [[Apple Developer Certificates]]
475	489		- [[Code Signing for macOS]]
476	490		- [[Hardened runtime for macOS]]
477	491		- [[Signing and Notarization FAQ]]
478	492
479	493		## External links
480	494
481	495		- [Apple: Notarizing your app before distribution](https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution)
482	496		- [Apple: Notarizing macOS Software Before Distribution](https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution)
483	497		- [Apple: Customizing the Notarization Workflow](https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow)
484	498		- [Apple: Common notarization issues](https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolving_common_notarization_issues)
485	499		- [Apple: Using app-specific passwords](https://support.apple.com/en-us/HT204397)
486	500		- [Notarize FPC](https://github.com/neurolabusc/NotarizeFPC) A script to notarize a command line utility and package it in an installer .pkg file.
487	501
488	502		---
489	503		From the Free Pascal wiki, page "Notarization for macOS 10.14.5+", as it stood on 2024-05-06 after a change by Rossh lz, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).

Back to history