dsym file

This EXC_BREAKPOINT crash is something that Swift uses when it wants to crash your app deliberately. The last method name is clearly a mangled name, but it's a pretty good guess that it's a result of your app calling 'fatalError' to crash itself. (It could have been library code, though, rather than a fatalError call you wrote.)Since you're not getting line numbers, that suggests this is a release build of your app, without built-in debug information. In a release build, fatalError doesn't display its error message before crashing.So you have a couple of choices. One is to find the dSYM (debug information) file that Xcode produced when you built the release build for distribution, and symbolicate the crash to find out the last line of your code that executed. Or, investigate the crash using a debug build (reproduce the problem in Xcode, or give a debug build to your tester if you can't reproduce the problem.), and you'll get additional information.

Thanks for solution, @Svantulden. Using your approach, I was able to generate XCFramework. Unfortunately, there are issues with archiving project which uses such XCFramework. Archiving itself does not fail, but it produces corrupted XCArchive, which is not possible to open in Xcode or export via command-line (it fails with archive at path is malformed message). This is my solution based on approach used by PSPDFKit. Hope it can help somebody. #!/bin/bash WORKSPACE=MY_WORKSPACE.xcworkspace SCHEME=MY_SCHEME FRAMEWORK_NAME=MY_FRAMEWORK_NAME IPHONEOS_ARCHIVE_PATH=./build/${FRAMEWORK_NAME}-iphoneos.xcarchive IPHONESIMULATOR_ARCHIVE_PATH=./build/${FRAMEWORK_NAME}-iphonesimulator.xcarchive OUTPUT_PATH=./build/${FRAMEWORK_NAME}.xcframework rm -rf ${OUTPUT_PATH} set -o pipefail Device slice. xcodebuild clean archive workspace ${WORKSPACE} scheme ${SCHEME} configuration Release sdk iphoneos destination 'generic/platform=iOS' archivePath ${IPHONEOS_ARCHIVE_PATH} SKIP_INSTALL=NO BUILD_LIBRARIES_FOR_DISTRIBUTION=YE

Hello all, We had a similar issue, not sure, whether it caused the same as here. Apple changed the build folder structure For example for dsym in Xcode 16: DerivedData/-cepomayyloydxxdkdabvlloqozfn/Build/Intermediates.noindex/ArchiveIntermediates//BuildProductsPath/ReleaseLite-iphoneos/.app.dSYM In Xcode 15: DerivedData/*-cepomayyloydxxdkdabvlloqozfn/Build/Products/Debug-iphonesimulator/*****.app.dSYM They modified the build settings as well and now for example build_dir is pointing to the app build folder and not to the derived data. Hope that helps

Hi,I saw reply from KMT yesterday on this and then I replied back as well to KIM, why that conversation is deleted??As we have our customers Apple developer account and they receive an email every time from App Store Connect for this UIWebView deprecation warning which has been already escalated. This time I would like to make sure we are not going to receive the same warning and which is why I just need confirmation from your side.Have also tried creating a separate fresh(without using 3rd party tools/SDK’s/API’s/Pods) sample app which is using WKWebView inside and named it TestWKWebView then archived it, I can still find UIWebView matches in TestWKWebView 07-05-20, 7.18PM.xarchive file post running grep -r UIWebView . command as mentioned below:Binary file ./dSYMs/TestWKWebView.app.dSYM/Contents/Resources/DWARF/TestWKWebView matchesAnd if I go to above path and open TestWKWebView file in TextEdit and search for UIWebView, I could only find strings containing UIWEView like