dsym file

I tried Enable Debug Dylib Support = NO. At the beginning I saw that the message was gone and I was really happy, but then I tried to make some crashes but no dsym files were uploaded in Firebase. I switched again in Yes and I saw the message again, but after that when I made some crashes, I saw the logs in Firebase. I cannot say that I have a clear answer or I realised exactly what happened, but now it's working. In all these tries I run my app from Xcode of course, but sometimes I just run my app directly from the phone. I don't know if this helped the situation for this thing to unstuck. I hope that maybe someone will get some help from all these and make it work

Any idea how to download it when the build done from Xcode cloud? @kassa11, you should download the final archive from Xcode Cloud. See Download and archive build artifacts. We used a no-code platform to build our app. How would we download it without access to Xcode? @FeelGoodMealsNC, that is between you and the vendor of your no-code tool, as they should provide you with the complete set of build artifacts, including all available dSYM files. However, I suspect the reason you're inquiring about this information here is that you're receiving a warning when uploading your app to the App Store. If that's the case, then you'll want to see this other thread. Note that Firebase is a very common library in the iOS developer community, but if it has any closed source components (I do not know since it's from a vendor and not from Apple), then a dSYM may not exist if the author of the library does not wish to make such symbol information available to its clients. —Ed Ford,  DTS Engineer

Well in my case, just now, I was using one of my own frameworks (built through Carthage). When I stopped having Carthage build it, and just dropped the framework project into my project's workspace, I got past this error.Note that I was still using other Carthage built frameworks, just my own was freaking out for some reason?Additionally, once I had my Framework Project in my Workspace, I adjusted it's framework search paths to point to an absolute filesystem location of the Projects Carthage's Build/iOS (recursive) folder.--- Later ---nevermind, I had to re-archive the app and now the error is back again, but for a different framework I don't control. =(---- Later Still ----Ok, I got it! For me anyway, I needed to remove the dSYM files that Carthage generated from the Apps Resource Bundle.

-David, so long as you have the correct .ipa and .dSYM files that match the crash log:drop them all into one folder for simplicity,attach your device to your macbook,remove your app from your device,install the app via the .ipa device directly through itunes (this may take a bit of searching but is fairly easy)once that is done, and you are assured your app matches the one that caused the crash log: in Xcode, fire up the WIndow | Devices viewselect your device,click on View Device Logsdrag your crash log into the log window (left-hand pane, under the headers: Process / Dev / etc..that should be it, Xcode should automatically symbolicate the crash log for you.I hope this helps, as i know just how totally frustrating this experience can be.drew..

We use cmake, so it was a bit more difficult -- and CircleCI, so I had to make sure the dsym files got archived. Did that. Re-confirmed it's this code: guard let flowData = self.flowSets[id] else { os_log(.error, log: Self.log, Could not find flow %{public}@, id.uuidString); completion(RedirectorError.flowNotFound) return } id is a UUID; self.flowSets is private var flowSets : [UUID : FlowData] = [:] (where FlowData is a simple class wrapping some flow-related information). This particular method is invoked via XPC from a daemon, with a signature of func handleTCPData(_ id: UUID, data: Data?, completion: @escaping (_: Error?) -> Void). The daemon code is in ObjC++, and it checks to ensure that the UUID is non-nil. So I have no idea why it is segfaulting!

I'm having this problem as well.I found this post helpful in symbolicating my crash logs manually:http://stackoverflow.com/questions/25855389/how-to-symbolicate-crash-log-xcodein particular the post by 'Sea Coast of Tibet'.In the Xcode Crashes Organizer, cmd-click/right click on the app's name (above # devices) and choose 'Show in Finder' to find the 'xxx.xccrashpoint' bundle containing the raw crash logs. Cmd-click/right-click on this and select 'Show Package Contents' to open the bundle.Copy the raw crash logs to a folder with your app's binary and its dSYM file (you did save these after submitting your app, right?) and follow the directions in Sea Coast of Tibet's post with some/all of the crash logs to see the symbolicated stack trace of each crash.

there is no Download Debug Symbols button You shouldn’t need to download debug symbols. Consider this quote from the Download debug symbols page in Xcode help: If you include bitcode when you upload your app to App Store Connect Downloading debug symbols is only relevant if you use bitcode, and there’s no point using bitcode in a Mac App Store app [1]. So: Make sure you’re not using bitcode. Symbolicate using the .dSYM files created by your local build. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] As of WWWDC this year, bitcode is effectively deprecated for all our platforms, but it’s never been relevant to Mac App Store apps.

I'm having the same problem, the archive contains a dSYMs folder with dSYM packages for the binary and each framework, with the line number information of the files.

I'm not that familiar with Swift, I mostly do Objective-C programming, but my understanding is that Swift apps bundle a Swift runtime to be able to run the specific version of Swift that the app was compiled for.This runtime will obviously increase the size of the app.Looking at the contents of the .app file created by a debug build (using a default project in Xcode 7.1.1) there are the following files of intrest:Objective-CContents/MacOS/<app> 61 KBContents/Resources/Base.lproj/MainMenu.nib 36 KBSwiftContents/MacOS/<app> 37 KBContents/Resources/Base.lproj/MainMenu.nib 36 KBContents/Frameworks/libswift*.dylib 6 MB (the Swift runtime files)So a Swift app appears to get about 6MB of extra Swift related frameworks added to it, which isn't really that much.I'm not sure why the archive builds differ by 99.2MB rather than 6MB - although some of this could be due to dSYM files and other meta data bundled with the app archive. The Swift build may perhaps need to bundle

[quote='809905022, gpg, /thread/766290?answerId=809905022#809905022, /profile/gpg'] I use Xcode Command Line tools (clang 16.1) to compile the source and generate the dSYM files. [/quote] OK. From Xcode’s perspective, that’s still an external build system. [quote='809905022, gpg, /thread/766290?answerId=809905022#809905022, /profile/gpg'] Can a sandboxed process (python exec) access to a URL from another sandboxed process (app)? [/quote] Yes, but I don’t think it needs to in this case. My understanding is that you’re running this Python executable as a child process, using posix_spawn or something layered on top of that (like NSTask or Process). Please confirm. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com