We successfully use TestFlightLive as our crash reporter, but I think some features are missing. These missing features are in another crash reporter: Crashlytics, but as of now I'm not willig to switch crash reporters completely. So I wonder if it's possible to use these both crash reporters together in one app (which is meant to be in the app store in the future).
I run both TestFlight and Crashlytics together and they both report errors fine. Like Jens Kohl says above, it must be included after the TestFlight SDK is initialized. Here's my code:
#ifdef DEBUG
// setup testflight if in debug (ie dev) mode
[TestFlight takeOff:kTestFlightAPIKey];
#endif
[Crashlytics startWithAPIKey:kCrashlyticsAPIKey];
You can only use 1 crash reporting framework. The framework catching the crash lets the other framework either not catch it or get wrong data since there is already new code executed on the thread.
Related
I've just integrated Crashlytics with iOS and it's quite easy integration steps. I started session of crashlytics in didFinishLaunchingWithOptions with code [Fabric with:#[[Crashlytics class]]]; and its start tracking.
At some point in App I want to stop tracking of Crashlytics so how Can I do this? Is there any code for this? There is a way to stop tracking from online Dashboard in Crashlytics but I want to do from Code.
Looking for suggestions and help.
Thanks.
Xcode debugger does NOT allow Crashlytics to process crash reports.
if you have your device connected to your Mac, XCode's debugger will step in as well. So just disconnect the device before testing.
To make sure a crash is reported during your simulator testing:
Launch simulator
Press stop
Launch your app and force a crash
Relaunch the app from simulator
See the crash report in the web dashboard
Reference
Mike from Fabric here. I believe you're looking to kill an active Fabric session once it's been started with the same launch/session of the app.
In that case, there is not a way to kill the SDK session. I'd recommend wrapping the Fabric init in a conditional call or boolean check to see if Fabric should be initialized or not.
I am getting the following error messages when our production iOS app initializes:
[Crashlytics] Version 3.8.4 (121)
[Crashlytics] Running on iOS Simulator (iPhone), 10.3.0 (16E195)
[Crashlytics:Crash] Reporting is disabled
[Crashlytics] Crash reporting could not be initialized
[Answers] Initialized
[Fabric] Initialized with kit versions: {
"com.twitter.answers.ios" = "1.3.4";
"com.twitter.crashlytics.ios" = "3.8.4";
"io.fabric.sdk.ios" = "1.6.11";
}
Every subsequent call to log an event gets the following error:
[Crashlytics:Crash] WARNING: CLSLog has been used before (or concurrently with)
Crashlytics initialization and cannot be recorded. The message was: ...
The non-production versions of the app work fine running the exact same code but with different bundleIDs. Normally when the app initializes for the first time, then I see the app populate in the Fabric dashboard, but in this case the app is not showing up.
We have an Android and an iOS version of the app, and they both use the same bundleID, so I am wondering if there is a conflict because of that? I see the Android version of the app in the dashboard, and it seems to be working properly. This is an app that originally was a Xamarin app that compiled to both platforms, neither of which incorporated Fabric/Crashlytics. We have now written native apps on each platform, and both are using Fabric/Crashlytics.
Since this is a pre-existing app in both stores, we do not have the option of changing either app’s bundleID.
Make sure you initialize Crashlytics with Fabric before calling any Crashlytics methods:
Fabric.with([Crashlytics.self])
One step I routinely miss is to make sure you've added the build phase on your target:
"${PODS_ROOT}/Fabric/run" ${FABRIC_API_KEY} ${FABRIC_BUILD_SECRET}
and either replace ${FABRIC_API_KEY} and ${FABRIC_BUILD_SECRET} with your key and secret or add custom build settings for each.
There are apparently cases where Crashlytics does not auto-activate new apps so that they show up under your list of apps, even though everything is coded correctly and data is going to their servers. In this case, send an email to Crashlytics support (support#fabric.io) that contains a copy of the info.plist entries for the app in question and they will activate it for you. I have had to do this several times, especially with app extensions.
When I finally traced it down in my situation, the error was entirely correct, but not obvious.
I saw these errors in various testing targets where the code we tested was using a custom logging wrapper which called CLSNSLogv(), but the test didn't actually go through the AppDelegate and therefore did NOT initialize Crashlytics. After trying a few things I was convinced that it worked when executed as an app, but in our configuration it was not working under the unit test configuration.
I'll likely alter our custom wrapper to bypass CLSNSLogv() during testing anyway. The biggest benefit of using that is when crashes occur on devices, so we won't be missing anything.
I got this warning when running my application with HockeyApp integration:
[HockeySDK] WARNING: Detecting crashes is NOT enabled due to running the app with a debugger attached.
Crash reports are not sent and no alert is displayed when opening the app again.
Any one have any idea how to resolve this issue?
This has very simple reasons:
If you are running the app with Xcode attached, your app is connected to lldb, Xcode's debugger. When lldb is attached, it will of course do its job as a debugger and catch any exception or crash that occurs. This means that the crash can never reach the HockeyApp SDK or any other crash reporting SDK while lldb is attached at the same time.
The solution is also pretty simple. If you just want to make sure the SDK is integrated properly and will catch crashes, do the following:
Do a quick "Build & Run" to install the current version of the app on the simulator or device.
Click the "Stop" button in Xcode to stop the debugging session.
Manually start the app on the device or simulator by tapping or clicking the app icon.
Cause a crash.
Restart the app. Now the HockeySDK should process the crash report and show a dialog to approve crash log sending.
One thing to keep in mind: Make sure to not make the app crash immediately after app start as this would not give the SDK enough time to process and send the crash report before crashing again.
Hockey app sdk by default does not send report when a debugger is attached. There is nothing wrong with this.
It will send report when a archive build that release to ur tester cause a crash. I personally think this should and remain as this because you are trying to track crashes from your tester not when you are developing.
I'm trying to setup Parse crash reporting on iOS, using this guide, but unfortunatly, even after several crashes, there is nothing on my dashboard.
Here is my code (i'm using sdk 1.6.3) :
- (void)crash {
[NSException raise:NSGenericException format:#"Everything is ok. This is just a test crash."];
}
...
[ParseCrashReporting enable];
[Parse setApplicationId:#"********"
clientKey:#"********"];
[self performSelector:#selector(crash) withObject:nil afterDelay:10.0];
I followed the troubleshooting guide:
Make sure you've enabled Crash Reporting in your App Delegate before you initialize Parse. DONE
If you're testing, make sure Xcode isn't catching the crash with the debugger. DONE
Build, run, stop the app, and then run it from the home screen.
Crashes are sent on the next run of the app. Make sure the app isn't crashing again before it has a chance to send the crash information. If you're testing, you can ensure this by adding a delay. DONE
Crashes may take up to a minute to show up on the dashboard.DONE
Make sure you don't have any other crash reporting solutions linked to your application, as they might interfere with each other. DONE, (disable Flurry)
I tried on both simulator and device, as recommanded here.
Finally, i've this message in my console:
+[PFAnalytics trackEventually:params:]: unrecognized selector sent to class 0x10f08ac20
Any help is highly appreciated.
Parse must have a bug in v1.6.3 because I have downloaded v1.6.0 and it works all fine.
You can download it here:
https://parse.com/downloads/ios/parse-library/1.6.0
And this is the order for enabling:
[ParseCrashReporting enable];
[Parse setApplicationId:kParse_AppID clientKey:kParse_ClientKey];
This probably doesn't count as any answer but I don't have enough rep to comment.
Have you tried enabling the crash report AFTER setting up parse with your keys? I know this was an issue for me when I was trying to enable the local datastore.
I know it goes against the guide but weirder things have happened when I use Parse...
Parse 1.7.3 is also busted... upgrade to 1.7.4!! !
EDIT: DONT UPDATE TO 1.7.5 -- that seems to be busted too !!
Latest version Parse SDK 1.6.4 fixes this problem!
https://www.parse.com/docs/downloads
We have application released on iOS app store. And as per the guidelines the crashlytics SDK is integrated and also calling [Crashlytics startWithAPIKey:#"API_KEY"] as well. What could be the different reasons that the crashes are not getting updated on the Crashlytics Dashboard.
How we can verify or debug, the app which having the Crashlytics sdk integrated and initialised appropriately or not?
Before you launched, did you verify that crashes were getting reported? If not, then you may have a conflicting Exception/Signal Handler preventing Crashlytics from doing it's job.
Here's how you can throw a signal:
-(void) throwSignal {
int i = 12345;
NSLog(#"%#", i);
}
To throw an uncaught exception simply do the following:
[NSException raise:#"test version 3.3.2 crashy" format:#"awesomeness"];
If you were able to get crash reports before launch, then there may be something happening with Crashlytics ingest of the reports and I would contact their support team.
We are getting now crash reports for app store build. We had a provided .dSym file to the crashlytics team, they have uploaded the same in their db.