I have a MacOS app that I last notarized about a year ago with no issues. This time, however, when I created the initial Archive, the Organizer put it into a section called 'Other Items' instead of in the 'macOS Apps' section with all of the previous Archives. In addition, and more distressingly, when the Archive is selected, the button says 'Distribute Content' instead of the expected 'Distribute App', and pressing it simple exports the Archive or its contents, without running through the automatic notarizing process.
I suspect I have done something in the last year that somehow invalidates my app such that Xcode no longer recognizes that it is an app. I have followed the suggestions at https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues, but that did not provide any relevant clues.
I am using Xcode Version 13.4.1. How do I figure out what is preventing Xcode from offering to notarize the app?
To track this down, I created a new project, and then tried to notarize it. (I didn't actually notarize it, I just made sure that I could Archive it and it showed up in the correct section in the Organizer.) The new project archived as expected, so I knew that I could still notarize somethings; I was just having an issue with my app.
My plan was to copy items from my app into the new project in small chunks, and after each copy, attempt to Archive it. I figured that I would either find the item that was causing the failure (and fix it), or I would eventually copy the entire app without a failure. Either way, I would be able to notarize the app.
The first chunk I copied was all of the build settings. And right there, the new project would not notarize, so I removed and added build settings to binary search which setting was causing the failure. It came down to the RUN_DOCUMENTATION_COMPILER = YES build setting.
In the last year I have been more conscientious about documenting the code, and to actually see that documentation, I had added that build setting.
Comparing the archives created with and without running the documentation compiler, the MyApp.doccarchive file appears in the archive in the Application folder along side MyApp.app, so it appears that Xcode is confused by the "extra" file in the Application folder.
Related
I have an iPhone application that is compiled under Xcode. I have a file which I shall call 'manual.pdf'. The app has a manual page that shows manual.pdf using WKWebView. The 'manual.pdf' file is generated from OfficeLibre.
When the UI has changed, I go through the original 'manual.odt' replacing the screen shots with new ones, and correcting the text. I then export a new 'manual.pdf'. I then have to...
delete the old 'manual.pdf' entry.
drag the new file to the Resources directory.
fill in the form to get it added.
I don't need a build-time copy script. Those look complicated, and this is not particularly labour intensive, and I don't necessarily want to do it every time the manual changes. But this feels wrong. I would be happy if Xcode just substituted the new file for the old file if it had the same name. But it doesn't.
I am running Xcode 14.1 building for an iPhone 12 running iOS 16.0 FWIW.
I found the answer. I had just edited the file, and I went to Xcode to update the reference. The new version was already there. I guess when I dragged the file, it created a link rather than copying the file.
Nice, once you know it is there.
PS:
I have made another discovery. Xcode used the latest 'manual.pdf' when building the application, but it did not save it when I committed the changes. I had to separately update the PDF file in the git archive to get it to update. However, the builds released to the TestFlight site all had the right PDF.
My minimal solution is to copy the file to the archive...
cp ~/Documents/manual.pdf ~/XcodeProjects/MyApp/MyApp/Resources/
This then gets committed with the next Xcode commit.
With Xcode 10.2 I'm getting a Code Signing failure of
resource fork, Finder information, or similar detritus not allowed
Command CodeSign failed with a nonzero exit code
but I don't how to find which particular element of the massive project is causing the problem.
This, by the way, was not occurring with Xcode 10.1. Back then I did find that some of my .png images contained color profiles which were removed and stopped a code signing failure there.
The current failure occurred after bringing the code unchanged from under 10.1 where no failure happens. And it does not happen either when I take the code as modified under 10.2 back to 10.1. So this is making me crazy!
Now, I can't even find Apple documentation to help me find what to fix! Any suggestions will be gratefully processed. Thanks.
I examined (again) the dense paragraph above the code signing error message. The main thing it contained was a path to my app bundle. So I thought something extraneous might be within the bundle.
I went to the Products folder in the project navigator panel in Xcode and right-clicked my app, then selected Show in Finder, then in the Finder I right-clicked the app and selected Show Package Contents, then expanded the Contents directory and then the Resources directory which is the most likely place to find detritus.
Sure enough, there was a .png image file which I had rejected for use while experimenting with the app. I had commented out // the code lines referring to it, but had not deleted that image file from among the Supporting Files in the Xcode navigation panel.
I did delete it and re-built the app. Voila, no more code signing fault!
Thanks, guys, for your kind attention to this question, and all the questions people ask.
Is there a way to activate Xcode Source Editor option in System Preferences > Extensions? For some reason, it's not showing on my Mac (the last option).
If the Xcode Source Editor is missing from the left pane (see image above), try one of these solutions before resorting to a reinstallation:
In the Applications folder, rename Xcode and then change the name back to Xcode, or move Xcode.app out of the Applications folder, then back in, as described by this Stack Overflow answer.
Move the Xcode app to the Trash and re-install it from the AppStore.
I install the Xcode manually that's why not found on Extensions.
To fix quickly:
Quit Xcode
Rename Xcode in the applications folder temporarily with any name.
Launch renamed Xcode
Quit Xcode
Name it back to the old value ("Xcode")
Go back to Extention you will find the Xcode
The entry is shown if the system detects that both Xcode and at least one Xcode extension is installed. Yet the code to detect Xcode has a few issues.
If you install Xcode first and don't have an extension, the entry is not shown. If you then install an extension, the system re-checks if Xcode is still installed and if yes, it should add the entry. However, the check code will fail in some situations. E.g. if you renamed Xcode.app to something like Xcode_13.4.app (as you need to manage different versions of Xcode), the detection code may not find it. It also may not find it if you moved Xcode to a different location outside of /Applications. And even if not renamed and still in the default location, the detection code sometimes fails and the exact reason why that happens is unknown (it may have issues with certain ownership, certain file permissions, case-sensitive file systems, etc.)
In all these situations, renaming Xcode causes it to be re-detected by the system and then the system sees that Xcode and at least an extension is installed and the entry appears immediately. No need to reboot or start the renamed Xcode; you rename it, you rename it back, and the entry is there and will stay there (even after deleting all extensions, it stayed on my system).
If you first installed any app with an extension and then Xcode, the problem does never appear as in that case you immediately trigger the rename-fix above, because the moment you install Xcode, the system will always detect it correctly (regardless how the app is named or where it is located or any other issue the scan code might have) and detecting Xcode and knowing there is an extension, the menu entry appears at once. The code that detects Xcode extensions seems to always work correctly.
This is probably one of the issues where the Xcode detection code has not been tested very well by the Apple but since it seems to work for the vast majority of users, Apple sees no reason to further investigate why it would sometimes fail.
It will get activated by default if any plugin are added in Xcode.
You have to download XcodeClangFormat plugin from GitHub and follow the installation steps. Then Xcode Source Editor will be visible automatically.
Please refer this link
I am trying to build an update to my Mac app. As usual, I clicked Product>Archive then, in the Organiser, I clicked Distribute...>Export Developer ID-signed Application. Xcode finds my Developer ID, but it fails with the error "Code signing operation failed - Check that the identity you selected is valid."
This has never happened before, so I'm at a bit of a loss - I most recently exported a version of my App last week.
The only things that have changed are:
I have changed my Apple ID password
I added Cocoapods to my project and I'm now using the .xcworkspace file, rather than the .xcodeproj file.
I've tried refreshing the Teams list in the Xcode organiser, deleting all my Mac development and distribution certificates, restarting Xcode, and asking very nicely, but I'm still getting the same error.
You've done the right part in xcode, the only place that might be the problem is the Dev portal. Check your Dev certs in there if needs be you may have to remove those and request them again then sync them with xcode. That has worked for me before and might work out for you.
In case anyone ends up here, but still has the problem after checking everything in the dev center,
try removing extraneous files form the project. For me these were:
Gruntfile.js, karma-e2e.conf.js, karma.conf.js, and the entire node_modules directory.
see: How to build IPA for distribution with TestFlight with XCode 5?
I've made an update to my existing Mac app and went to archive it.
In Organizer it came up as a new entry and not under the previous releases I had. This new entry appears generic, ie. no app icon, no version or identifier info, just the name of the app came through. What happened? How do I troubleshoot?
In the update I added a UTI and also copied a plug-in into my bundle. Could those things have something to do with it?
Got it. My problem was related to dependency targets. Here's the solution:
http://www.weston-fl.com/blog/?p=2429
(Excerpt added 2012-12-18; see blog post for screenshots and background info)
… Select dependent project(s) in the Project Navigator
Find “Skip Install” and set to YES.
If you have more dependent project, repeat these steps for all of them (i.e. at static library projects).
The app is expected to be deployed so do not change the Skip Install’s No to YES there. Change at the dependent projects only.