Xcode Archive

[Dallas Querry]

Runningarchive in my project in Xcode 11.3 (and 11.2.1 as well) on a fresh installation of Mac OS Catalina results in "Build Successful" but it does not appear in the organizer. My scheme is correctly configured with "Reveal Archive in Organizer" checked - and the build output produces no errors. It just finishes with build successful and thats it, and a grep of my system cannot find any existence of an xcarchive on my machine.

After searching I found others with this issue from past versions of Xcode who solved it by restarting Xcode/Cleaning/Removing Derived Data - this is not working for me. I have also verified my Installation Path is accurately showing /Applications.

I am currently having the same problem with M1 machine macOS Monterey, Xcode 13.1.Archived was succeed, but organizer window didn't appear, when I try to open archived file inside finder, I can find only BCSymbolMaps, Products, and dSYMs. Any ideas to solve this ?

i have a serious issue with uploading archives - using xcode 13. Preparing for distribution completes. during the uploading the task bar moves to the end prematurely while negotiating connection, the uploading package begins and then the internet connection corrupts and my mac needs to be restarted. Has anyone seen this type of issue

I work with XCode 12.5 and Swift 5. I am a member of a development Team.I finished my first App and I want to start with Beta Testing using Testflight. I already tested the app on my mobile device and everything works fine.Furthermore I followed every step of this article: -your-app-for-distribution

In this article it seems like the solution is to change the "skip install" value. I have the "Skip Install" once in the "Projects" and "Targets" section. I already tried each combination of ticking yes and no, but the result stays the same.

No, if I do this i can distribute it as an app. So there must be something wrong with the settings I guess? Can you archive the project from this post: _and_media_capture/streaming_depth_data_from_the_truedepth_camera

And even with all of that set properly, I still get only Distribute Contents on a product archive. Again, this is a fork of the TrueDepthStreamer. Are we sure there aren't any other settings that could be causing this problem?

I was able to resolve this problem in my flutter based app. where VS Code formatter the info.plist file to different style and that's what broke my build and started showing Distribute content option. :D Unbelievable

I had copied a target and got this behaviour too. I was because the scheme still had the target from the copied target so it was really building two apps into one I guess. I could see this in the archive by using "Show package contents" in Finder. Within there is Products > Applications folder where there was two apps :(

I'm trying to document my application "Not a library" but the X-code file size for archiving it is really big and unacceptable it's around 200MB! Do you guys have any idea how can I reduce the file size?

App documentation is going to be notably larger than library documentation, because it defaults to documenting internal and public symbols, where a library defaults to only documenting public symbols. The majority of the space in that archive is likely its "data" directory, where there's a JSON file for every symbols that's included in the archive. The "documentation" directory can be large as well - it has a placeholder "index.html" file for every JSON file that represents a symbol.

To give you an example with numbers, the App is public at GitHub - heckj/SPISearch: A utility application to capture and review search results from Swift Package Index., and the docarchive I created (through the Xcode app : Product > Build Documentation, then exported) has the following pattern of space consumption (I used du -sh in the terminal to get these numbers):

I meant to bring this up in the Doc WG at some point to see if there's something that could be done to trim this back a bit perhaps. Given that we're going to be keeping historic versions, the impact could be significant!

For projects that contain structs that conform to SwiftUI.View, I expect the large size of documentation catalogs to be due to the fact that each struct gets a copy of the protocol extensions (mainly view modifiers) of SwiftUI.View, which I believe are in the order of hundreds, due to how SwiftUI is designed.

For example, see the symbols in PhotoCamera vs. DocumentCamera. Each of these APIs get their own individual page, because from the language perspective, these are distinct symbols (synthesized by the compiler).

While the documentation here is indeed correct because these symbols do exist, I'd be in favor of a way to configure DocC to not generate pages for synthesized symbols because their documentation is accessible on Apple's documentation website. Ideally, as part of this, you'd still be able to browse the synthesized view modifier symbols of the page by making the SwiftUI.View text in the "Conforms To" section of the page link to Apple's SwiftUI documentation, but that can be left as future work:

Thanks, I learn something new every day. I've never seen the du command before. It's much more important than what I asked for here. I used to work with some applications to find out the size of directories.

I think the issue here is more about DocC's page-per-symbol generation model than it is about the particular format it currently emits. Each symbol in the project is going to produce a page, each page is going to have a JSON document, and SwiftUI View conformance leads to many more symbols than might be expected.

In your example, the bulk of the size is in the data directory which is a flat JSON file generation (one JSON document per page) very similar to what a flat HTML file generation would produce, just in a different format.

Imagine I create documentation with DocC for a large-scale application with tons of methods, classes, and structs. I believe it goes beyond the numbers that I wrote here. Thanks for creating such a powerful tool, but there is a really big obstacle here that prevents me to plan for publishing on Github-Pages.

I expect the large size of documentation catalogs to be due to the fact that each struct gets a copy of the protocol extensions (mainly view modifiers) of SwiftUI.View, which I believe are in the order of hundreds, due to how SwiftUI is designed.

And for the most part they are just clutter, IMO. Associated types can be worth mentioning (because that is a way in which different types can differ in their conformance), but other than that, all conformances to a protocol have the same members. The pages for these members are barebones - just "inherited from X". That's all.

On a related note, I really hate that Xcode now shows the "Inherited from..." line rather than the actual documentation, with no link to the actual documentation either. Really all of these inherited or synthesized documentation points should essentially alias the underlying documentation, not duplicate it. Not sure how to accomplish that. But this "Inherited from..." behavior should definitely be reversed.

The Swift compiler already has a -skip-synthesized-members argument which will remove these symbols. It should be possible to pass this flag in the OTHER_SWIFT_FLAGS build setting in Xcode. I filed Support for skipping synthesized symbols Issue #27 apple/swift-docc-plugin GitHub to support this via the SwiftPM plugin.

I want the synthesized API to be visible in some way (as well as inherited API), I just don't want it to block the inherited documentation. Ideally it would somehow alias the original docs into the type's documentation, with perhaps a note saying it's inherited. If that can't be done I'd rather the whole documentation was duplicated inline than blocked.

To me, the right approach here regarding how these synthesized symbols are treated is to not duplicate documentation, and instead have DocC automatically link to the original API the symbol is synthesized from. This would fit in nicely with the work @ronnqvist proposes here: Use cases for combined documentation of multiple targets in Swift-DocC. And until this is implemented, we should allow users to turn off synthesized symbols via a command-line flag to unblock them.

Came across all of this while trying to figure out how to get rid of these symbols. From what I can tell -skip-synthesized-members doesn't seem to work in the OTHER_SWIFT_FLAGS build setting. Curious if maybe I am doing something wrong or if this just isn't supported through Xcode directly.

However, now I am submitting the app to the App Store and I don't know how to get Xcode to create an archive that doesn't compile for both Apple Silicon and Intel. The option in the target build settings is simply (Standard Architectures (Apple Silicon, Intel)).

I am encountering the same issue and changing the build setting called "Build Active Architectures Only" to "Yes" fixes the issue BUT I am now faced with an Xcode Archive that is a "Generic Xcode Archive" instead of a MacOS archive that I can have notarized by Apple or submitted to the App Store. Any ideas on how to work through that? Were you able to get your app into the App Store after making these changes?

Hold on, take a breath and do what I did after struggling all day with the problemopen xcode -> Pods ->Target Support Files -> Pods-Runnder-frameworks. Open this file and search for "readlink"(cmd + f) .It should be like this

So I am trying to update my app and I changed my version number from 1.0 to 1.1 and updated my build number to match. Even though the version number appears different in the xCode screen, I archive the app, and it shows that my version number is still 1.0. Then if I try to upload the app to the app store it says that it can't be uploaded because it has the same version and build as the existing app. Has anyone had this problem or does anyone know any possible fixes to this problem? thanks

So it appears I was updating the wrong part of settings. On the top bar on the left hand side where it says "General Capabilities etc." where it has your app name. I was updating the target with the round E instead of the one with the App Store symbol. Don't really know what the difference is but as soon as I changed the target my archive reflected the new version number.

3a8082e126