I've received a crash log in iTunes for:
Dyld Message: Library not loaded: #rpath/Foo.framework/Foo
There are several of these, each for a different framework that is included in the app, although there isn't one for every framework.
I understand what a "library not loaded" crash means, and how to fix one that is happening on every run of the app - it's just "add the framework to copy files, because you forgot to before". My impression is an app should either crash with this error every time it is run, or none of the times it is run - either the framework is included in the bundle, or it isn't.
A few more details:
I can't reproduce this, and the vast majority of users seem to be getting along fine.
There are crash reports for both workspace (normal "Copy Files") and Carthage (carthage copy-frameworks) frameworks.
What should I do to investigate and fix these crashes?
This appears to happen when the device itself runs too low on memory. It's an iOS bug that should be fixed in iOS 9.3.2 (released May 16, 2016). The users that experience have many apps crashing for them during launch. The only way they can solve it is by restarting their device.
The issue is caused by apps using too many (third party) Frameworks. So you can either remove Frameworks (by for example copying third party code into your project) or wait for users to get the iOS update with the fix.
Related
I just implemented Fabric Crashlytics tool to my Xcode project via Swift Package Dependencies.
All works good if I enable Google Analytic on a step when I create an app, without this step I did not received crash reports, so I switched to the app with Google Analytic enabled.
I've tested crash button from the link:
One comment that I don't like from there
"After your app crashes, run it again from Xcode so that your app can
send the crash report to Firebase."
Does it mean that user has to reopen app to send crash report? For example if a user download an app from the App Store and then somehow the app is crashed. Does mean that reopening app required for sending that crash? And if the user will not open the app it means I lost this crash report? I understand that on live store there is no option to re run it form Xcode, but reopening seems a require step.
I suppose the crash report should work different a bit by sending issue details right after a crash, I may be wrong here.
Also when I set everything via Swift Package Dependencies looks like I don't have an option to upload dSYM via this option
/path/to/pods/directory/FirebaseCrashlytics/upload-symbols -gsp /path/to/GoogleService-Info.plist -p ios /path/to/dSYMs
Does this mean I need to pull Fabric and Crashlytics from CocoaPods?
I've switched off bitcode at the moment and looks like all is works automatically but not sure it is good idea for long perspective.
Yes, crashes will be uploaded when restarting the app after it crashes. As far as I know, this is because the SDK may not have enough time to actually send the report when the crash happens.
If you are using Swift Package Manager, you still have that option.
This is the command:
"${BUILD_DIR%/Build/*}/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run"
If the app has bitcode enabled, then you'll need to download the dSYMs from the App Store and upload them manually.
Lastly, Fabric is now deprecated so don't download it. You don't need to use Cocoapods if you are already integrated Crashlytics with SPM.
I develop an IOS SDK, which developers can implement it to their apps as a framework.
I’m currently using Sentry as crash analysis tool, and the related DSYM file (produced from my SDK project) is automatically uploaded to Sentry on every build.
But the problem is when someone’s app crashes due to an error on the SDK I’m developing, Sentry returns partially symbolicated crash logs that I can barely understand what has happened and where the crash has occurred.
Is there a way that I can get the fully symbolicated crash logs, without changing the app’s project settings and without uploading anything (app’s DSYM etc.) from the original app. (Since I don’t have the app, I’m only producing the SDK)
My project has the following build settings:
Strip Debug Symbols During Copy: No
Strip Style: Debugging Symbols
Strip Linked Product: No
I was sending the DSYM's to a wrong project. I set 'export SENTRY_PROJECT=proper_project_name' then the issue has resolved.
Here is the link of the issue;
https://github.com/getsentry/sentry-cocoa/issues/277
When submitting our app to the app store the validation process for the build keeps getting rejected with the following error.
Invalid Bundle - One or more dynamic libraries that are referenced by your app are not present in the dylib search path.
Has anyone else had issues with this error? I feel like I've tried just about everything. I'd done the suggested otool -L on the main app as well as the watch app. The only library that it shows linked for is the Mixpanel library. The only other two libraries we are using is Fabric and Crashlytics. From my understanding those are not actual real frameworks? I've also tried to set ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES to YES as many posts online suggest. The project builds and runs fine so I'm completely lost as to how to resolve this issue.
This is a React Native iOS app if that has anything to do with it. I'm not the most experience when it comes to iOS stuff but I can find my way around xcode. Anyone have any suggestions? Maybe the best solution is to just create a new xcode project and set everything up again and copy/paste in the code from the previous project?
I am facing a strange issue in my currently working app. App is crashing when we install app through diawi or directly install using .ipa . But I am not able to regenerate the issue through debugging. I am totally confused and how can I solve the issue?
I am using Xcode 8.2.1
You can try building the app in Xcode in the Release configuration instead of the Debug configuration.
You do this by
clicking on your app name at the top left (near where you press to run the app)
choosing 'Edit Scheme' from the drop down
clicking on the disclosure indicator by 'Run'
choosing 'Run' from the three choices which appear
there is a drop down called 'Build Configuration'. This will almost certainly be set to Debug. Set this to Release.
Now when you run your app you will be building a far more optimised version - this is the version you build when you are submitting to Apple. It's just the same app optimised for speed/memory instead of debugability.
Hopefully, you should be able to reproduce your crash in Xcode now. However, you'll notice that you get far less debugging information when you hit your crash - this is because Debug builds have lots of extra information in (and are much less optimised by the compiler) specifically to make debugging easier. Being able to reproduce the crash in Xcode should give you a few more clues as to what's going on. At the least you should be able to see the chunk of code causing you issues.
Let us know how you get on.
Use crash tracking tool to track crash here is the detail about installing crashlytics
We're using TestFlight to send out pilots of our app.
There's a part of the app that is crashing, and we had a lot of trouble reproducing the crash. The code their is fairly simple.
It turns out that the users who got the App via TestFlight get the crash, while if you build the app and install it using the IDE it doesn't crash!
Anyone have ideas about what might be causing this?
Any ideas for workarounds? We don't want to stop using TestFlight.
Make sure to build your app in Release Mode not in Debug. The app may only crash when in Release.
The first thing I'd try is to map the crash stack trace to function names in your application. This may yield useful insight into the nature of the crash:
As soon as a crash is reported request the crash log. This can be obtained through Xcode's organizer or if that's not an option it can be screen-captured from the iPhone's Settings -> General -> About -> Diagnostics & Usage -> Diagnostic & Usage Data. Scroll to the app name or the section LatestCrash-AppName.plist.
Although you can in theory symbolicate a crash, I find the procedure described below a foolproof way to get symbols from the stack. Convert all stack addresses for the crashing thread into method names.
Optionally request the iDevice syslog. This may include assertion failure messages which are also invaluable. Note that this should be done as quickly as possible as the syslog only holds so many entries before they get dropped. You can use the Organizer or the cmd line idevicesyslog to obtain this.
Manual symbolication:
This will work as long as your builds have debug information.
Obtain the _exact_same_ .ipa that crashed. If you didn't save it you can download it from the device by using iFunBox or the cmd line ideviceinstaller utility.
Unzip the .ipa
Run the following command on the executable file (Payload/AppName.app/AppName):
otool -tv AppName.app | c++filt > listing.asm
Wait while the previous step completes (may take a while). The generated listing.asm file will be several megabytes long.
Using an editor that can handle large files search listing.asm for the addresses listed in the stack trace. Note that the addresses may be a few bytes off (usually pointing 3 or so bytes ahead). Also, addresses that aren't found in listing.asm indicate addresses in iOS libraries. Ignore those for now.
Of course, if you're able to symbolicate, you can skip this procedure.
Good luck debugging!
We had a similar problem. The issue with us was static libraries. When we built the app from scratch and went to testflight, it was crashing but from the IDE it wasn't. The crash was because the static libraries did not get included when doing a build, but was getting included if I connected the iPad direct and used XCode to install.
A simple test will prove this:-
1.) Instead of building from IDE, create a .app file and then load it via iTunes and check if you are getting the crash.
We worked around this by creating the .iPA manually, that is creating the .app then making a Payload folder and putting the .app in it along with the info.plist.
Then things began to work in Testflight as well.