Our application has bitcode enabled, so we can't use dSYM files generated on our machines/CI but rather we should use dSYM generated during bitcode compilation. The problem here is that we don't have those files available to download on App Store Connect (no link is presented).
That's really weird. We suspected that maybe our 3rd party tool which we upgraded recently and that is used to obfuscate our binaries started to work incorrectly but all builds get "Validated" status and we can publish them in App Store without any issue.
I suppose that bitcode process runs correctly as we get smaller binaries available in App Store, but dSYM is somehow not produced.
I found a thread on Apple Developer Forums but nothing really uncovers the root of this issue: DSYMs No Longer Offered for Download?
Related
We are trying to address a critical crash in an iOS application that's using Fabric / Crashlytics. We don't have the contact details of the person that was last working on the application and uploaded the latest version to the App Store.
In the project dashboard I noticed the message "Found XXX unsymbolicated crashes from missing dSYMs in 1 version in the last 24 hours". Screenshot: https://i.imgur.com/YT9gggJ.jpg
I did the only sensible thing I could think of: I went to the App Store Connect dashboard. I downloaded the dSYM zip for the build in question as per the official instructions from Fabric: https://docs.fabric.io/apple/_images/download-dsym.png
I then went to the dSYM tool and uploaded the zip directly. Turns out only two of the four files required were in the zip (I also examined it myself): https://i.imgur.com/JqxZcaD.jpg
So... I'm in a black box situation here...
I'm not an iOS developer
I don't have access to the computer used to build the project or the person that produced the build
I'm assisting an iOS developer that has just joined the team
I have access to the project repository
I have access to the App Store Connect profile
I have admin access in Fabric
My questions are:
Why were the other two dSYM files not in the zip I downloaded form the App Store?
Why are some crashes associated with one dSYM and the rest to another? Is there any sort of categorization of the crashes that we currently have access to?
Can we do something to gain access to all the production crash reports without publishing a new app version to the App Store? We're trying to avoid this scenario ATM.
EDIT #1:
So this person that published the build was not exactly following best practices. I wanted to explore the possibility of them having the dSYM files committed to the server repo.
This is their gitignore:
.DS_Store
xcuserdata
<PROJECT NAME>.xcodeproj/project.xcworkspace/xcshareddata/
build/
Build/
I guess the build folder pretty much rules out this possibility. I also searched the file structure for files containing the text "com_apple_xcode_dsym_uuids ==" with no success...
EDIT #2:
I'm appending an exceprt of the answer Fabric support gave me:
If your application is using frameworks, the product folder will have
a separate dSYM file generated for each framework built. Eventually
all of them are needed if we want to cover our bases and be able to
symbolicate a crash in every possible location in our app. A dSYM file
generated while building a specific version of the application can
only be used to symbolicate crashes from that specific version only.
dSYM files are identified by a Unique ID (UUID), which changes every
time we modify and rebuild our code, and that ID is what is used to
match a symbol file to a specific crash. A dSYM may be associated with
more than one UUID, as it may contain debug information for more than
one architecture.
It looks to me that you may need to upload a new build, which is not too bad after all if it includes any bug fixes. Regarding your questions:
Why were the other two dSYM files not in the zip I downloaded form the App Store?
The option to download dSYMs from App Store connect is available only if the app was distributed using Bitcode. Bitcode is intermediary representation of the source which App Store uses to produce the final optimised machine code targeting specific architecture/device. When Bitcode is selected all linked frameworks/libs should also be delivered using bitcode, so it looks weird to have only some dSYMs. Although unlikely, is it possible that the missing dSYMs are from another build?
Why are some crashes associated with one dSYM and the rest to another? Is there any sort of categorization of the crashes that we currently have access to?
Each target/framework/lib generates its own dSYMs, so your app probably depends on one or more frameworks and some of the crashes originate from that frameworks.
Can we do something to gain access to all the production crash reports without publishing a new app version to the App Store?
I can't think of another solution so far.
yesterday I wanted to deploy some bugfixes for my app with Xcode 8.3, and ran while uploading into the error ITMS-90167: "No .app bundles found in the package".
This error is also shown already when trying to validate.
I did not change any code signing or mobile prov. files. Everything worked a month before.
I tested my code with ios 11 device support copied over from xcode-beta.
I read through all stackoverflow questions like this one, but I am not using Xcode 7 nor the application loader.
So I updated to Xcode 9.0, fixed some stuff due to the changes for swift 3.2, cleaned derived data etc., and tried again but still the same error.
Inside the ipa I can see the folder Payload/appname.app with its contents.
I am trying to deploy with fastlane, but also tried with Xcode, same results.
I have double checked code signing and recreated mobile provisioning profiles, revoked expired certificates and deleted duplicate/expired certs and keys in my keychain.
Xcode shows the profiles as eligible.
I also tried Automatically manage signing.
But nothing helped.
What does this strange error message really mean? And how can one debug/resolve this?
For me, the cause was a lack of space on my internal hard drive.
As far as I can gather, you need to have the same amount of space free that the unarchived xCode project takes up in order for the .ipa to be verified and uploaded to iTunes Connect - and that's through either xCode or ApplicationLoader.
After moving as much as possible over to a USB drive, the .ipa uploaded without issue.
I finally resolved the issue (after 2 days hard work),
it seems that it was a problem with a framework which I copied (with all sources) completely into my app-project and within this framework there was a info.plist (of that framework) which seems to confuse the validation step of the itsm transporter. Although the app was built and worked in simulator and on the device correctly.
The error message
ITMS-90167: "No .app bundles found in the package"
is very misleading - because there was an .app directory in the ipa and I first thought about signing issues. On the internet I didn’t find anything helpful with this error.
After I build the framework as separate project and included it correctly as a framework the validation was successful and I was able to upload my app.
If anyone knows more about this itms transporter and where to find some more documentation about possible errors, please leave a comment...
For the record I have not touched any of the files listed below, all I did was compile, attempt to pull my hair out by uploading and then I got this error message:
Invalid Swift Support - The files libswiftDarwin.dylib,
libswiftMetal.dylib, libswiftCoreAudio.dylib,
libswiftQuartzCore.dylib, libswiftos.dylib, libswiftObjectiveC.dylib,
libswiftDispatch.dylib, libswiftCoreGraphics.dylib,
libswiftCoreData.dylib, libswiftCoreFoundation.dylib,
libswiftUIKit.dylib, libswiftCoreMedia.dylib, libswiftCore.dylib,
libswiftFoundation.dylib, libswiftXCTest.dylib,
libswiftCoreImage.dylib aren’t at the expected location
/Payload/BeginerGuideDigFor.app/Frameworks. Move the file to the
expected location, rebuild your app using the current public (GM)
version of Xcode, and resubmit it.
Once these issues have been corrected, you can then redeliver the
corrected binary.
Honestly I wouldn't even know where to beign
So to answer one of the question, according to the part apple told me to go through my libraries are fine here is a pic of me running the code for that
here is what I ran and below that is the result
UPDATE:
SOOOOO at this point I have now confounded the app support store, they cannot figure out why I am getting this error, they have asked me the same questions over and over, what version of Xcode, what version of Mac OS... still no resolution.
You mention a hair-pulling upload experience. But unless you have a build system/build scripts involved, normally the process is just Product>Archive and uploading from Window>Organizer (or using the Application Loader on an exported ipa from there). Are you doing anything different that may be corrupting the .ipa?
You might Export it for App Store, rename the .ipa file to .zip and unzip it. Right click on your app in the Payload directory, select Show Package Contents and look in your Frameworks directory for a clue. All of those files should be there. Do you have any Build Phase scripts that do anything with Frameworks?
UPDATE:
I just came across this Apple response to this type of issue in the Apple Developer Forums. That's a great resource for these types of things, by the way:
It's likely you have a plain dylib outside of a framework somewhere,
which is only supported on macOS. Please review the Troubleshooting
section of Tech Note 2435 for more context. If having a bare dylib
is indeed the cause of the problem, please file a bug for an error
message that clearly explains this.
Link: https://forums.developer.apple.com/message/218019#218019
When I try to download the dSYM from the organizer, it gives me this error :
Missing App Version
An app record for “co.**” was found but a matching version for “1.0.3” build “10” was not.
I have enabled Bitcode. It's a swift app with Swift and Objective-C pods. Xcode Version 7.2 (7C68)
When I right click on the archive and look at it's package contents in Finder, I see a dSYMs folder. I zipped it and uplaoded it to Crashlytics, but it still shows dSYMs missing for all my builds. It even has App.dsym with some dsyms with UUIDs and others for my pods.
Is this an XCode bug?
I see somene has posted a similar question for tvOS on the apple developer forum but there are no answers there. I am not allowed to ask a question there for some reason :p
I haven't added a build to iTunesConnect yet, is that necessary to download dSYMs? Where does XCode download the dSYM from? Could it have something to do with the fact that my bundleId is of the form co.someString and not co.someString.someOtherString? I guess not, I'm just looking for anything.
Is disabling bitcode the only way to be able to get the dSYM for me?
Sounds like your dSYM file doesn't match the application binary, even if app version number and build number would be correct. Every time you build (archive) app, you get new and different dSYM file, too.
You cannot use just any dSYM file from any archived project, even if you made no code changes between archives. You must get the exactly correct archive and dSYM from within it.
Here's related info from HockeyApp, similar service to Crashlytics. Even if they are diff services, symbolicating crash reports is similar problem.
Several companies (Crittercism, Crashlytics, Hockeyapp and others) offer crash symbolication services for iOS. These require one to upload your apps dSYM file/folder but they don't ask you to upload the associated App file.
Symbolicatecrash, ATOS and related tools all seem to require both the APP and dSYM files to symbolicate a crash. How do they get around this requirement?
The app binary is not used or required for the actual symbolication process. The symbolicatecrash script from Xcode is requiring the app binary to be available but actually never uses it. It is not documented why the script requires the binary to be available though. You can verify this yourself by opening the script (it is written in Perl) in an editor.