IOS crash log catch, debug info .. Catch and email Dev team

Question

Recently, we were faced with a situation where we wanted to see debugging information from the application that the user has on his device. So, I’m looking for a way to find the log on the device, insert it as embedded text in the mail and allow the user to send it.

Any ideas? Here are some more questions. 1) Locate the debug log on the device 2) open the file and attach the contents of the file as inline text to the mail. 3) Allow the user to send email the next time the application starts.

Thank,

Answer 1

Thanks for all the inputs guys .. I have included your solutions in one that would solve my problem. Here is what I did. Of course, I did not compile the code, this is half-baked code. but I will iron it soon as soon as I implement it in my code.

NSLog to file Like NSLog to file LOG2FILE

#if TARGET_IPHONE_SIMULATOR == 0 NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,NSUserDomainMask, YES); NSString *documentsDirectory = [paths objectAtIndex:0]; NSString *logPath = [documentsDirectory stringByAppendingPathComponent:@"console.log"]; freopen([logPath cStringUsingEncoding:NSASCIIStringEncoding],"a+",stderr); #endif 

Catch a crash and write them also to a file

First, create a function that will handle the error and print it to the console (as well as everything you want to do with it):

 void uncaughtExceptionHandler(NSException *exception) { NSLog(@"CRASH: %@", exception); NSLog(@"Stack Trace: %@", [exception callStackSymbols]); // Internal error reporting } 

Then add an exception handler to your application delegate:

 -(BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions: (NSDictionary*)launchOptions { NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler); // Normal launch stuff } 

Set the variable in info.plist named Crashed and then read / write it this way

 - (void)readPlist { NSString *localizedPath = [[NSBundle mainBundle] pathForResource:fileName ofType:@"plist"]; NSMutableDictionary* plistDict = [[NSMutableDictionary alloc] initWithContentsOfFile:localizedPath]; NSString *crashed; crashed = [plistDict objectForKey:@"Crashed"]; } - (void)writeToPlist { NSMutableDictionary* plistDict = [[NSMutableDictionary alloc] initWithContentsOfFile:filePath]; [plistDict setValue:@"YES" forKey:@"Crashed"]; [plistDict writeToFile:filePath atomically: YES]; } 

After starting the application, read info.plist and ask the user to send crash logs.

 { MFMailComposeViewController *mailComposer = [[MFMailComposeViewController alloc] init]; mailComposer.mailComposeDelegate = self;[mailComposer setSubject:@"Crash Log"]; // Set up recipients NSArray *toRecipients = [NSArray arrayWithObject:@"[e-mail]"]; [mailComposer setToRecipients:toRecipients]; // Attach the Crash Log.. NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES); NSString *documentsDirectory = [paths objectAtIndex:0]; NSString *logPath = [documentsDirectory stringByAppendingPathComponent:@"console.log"]; NSData *myData = [NSData dataWithContentsOfFile:logPath]; [mailComposer addAttachmentData:myData mimeType:@"Text/XML" fileName:@"Console.log"]; // Fill out the email body text NSString *emailBody = @"Crash Log"; [mailComposer setMessageBody:emailBody isHTML:NO]; [self presentModalViewController:mailComposer animated:YES]; } 

Answer 2

• To register your own data, use Cocoalumberjack . It is much faster than NSLog and can be turned on / off dynamically. It also provides options for saving data to a file. NSLog will slow down your application and populate the console log. Also, you do not want to register too much in general. You cannot safely register when a failure occurs. Therefore, as soon as you find out where the problem is, add a few more logs and try to reproduce them, for example. using automated testing systems such as KIF .

• To get a crash report, you should use nothing more than a solution based on the open source framework PLCrashReporter , which can safely break glitches even when the application is already in the application store! The exception exclusion suggested by others is not recommended; check this article to find out why!

  iTunes Connect also offers you to view some accident reports, but to view some of them requires up to 2 weeks, but not all, for example. pointed out Camera + developers . Therefore, you are better off using your own solution.

  PLCrashReporter will send you standardized accident reports with formatted apples, ready for symbolization, so you know where your code crashed, including line numbers.

  Some solutions based on PLCrashReporter:

  • QuincyKit : open source client + php server, basic breakdown, symbolization can be automated from your mac (I'm the developer of this)
  • HockeyApp : Paid service, uses the QuincyKit client, extended grouping of failures, symbolics fully executed on the server (I am on the developers)
  • Bugsense : free service, lack of symbolism
  • AppBlade : FREE maintenance if used with 25 devices or less, without symbols
  • Crashlytics : Private beta, unknown features, their solution seems to be based on PLCrashReporter

• The proposed solutions allow either automatically sending data at the next start, or asking the user if he / she agrees to send.

Answer 3

For logging and analytics in Swift, you can use SwiftyBeaver , a full-featured logging platform including the open-source Swift 2 and Objective-C Framework, encrypted cloud storage and Mac App.

Website: https://swiftybeaver.com

Frame (support): https://github.com/SwiftyBeaver/SwiftyBeaver

Disclaimer: I am the founder.

Answer 4

This solution, which detects failures when they occur, will provide more user-friendly code information than the failure log. It lacks a crash log, but, as Till says, you can still access them.

From another question about Xcode 4.2, always returning to the main one on failure. The answer there uses this method, and you can extend it to track failures.

implement your own exception handler in AppDelegate

 // on load NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler); void uncaughtExceptionHandler(NSException *exception) { NSLog(@"CRASH: %@", exception); NSLog(@"Stack Trace: %@", [exception callStackSymbols]); // Internal error reporting } 

UPDATE I did some digression, and this solution was proposed by Zane Claes to a question. Debugging Xcode 4.2 does not symbolize a stack call

He offers a general solution in his second comment. “I find it useful to write a crash log to a file and prompt the user to send it to the next run (only in release mode, so as not to interfere with debugging). This allows me to get excellent error reports ... and users know that their problem is being solved . " I understand that not everyone would like to ask a user about this, but there are superusers who would be happy to help.

Of course, you can enable the "Never show me this tip again" button so that people are not upset by the reporting mechanism.

Alternatively, you can contact the server with information (I'm not sure that it will work, because it is a failure, but save it, and sometimes try POST on the server with details)

Answer 5

I used Crittercism to automate this for me. Works for both testing and production.

Answer 6

BugSense provides crash reporting services for iOS. In addition to providing a fully symbolized stack trace, BugSense provides analytics for your crashes in all of your applications.

I think this is better than email, because when your application becomes popular, you will need to manage all these emails manually, while BugSense does it automatically. However, BugSense is also open source, so you can change its internals in any way and add additional features.

In addition to this, you make us work for you for free: if you have an idea about a new new feature that you want, we will do it - we also think that is cool.

Disclaimer: I am writing code for BugSense-iOS.framework.

Answer 7

If you use TestFlight with your SDK, this is automated. This is a really good system. However, for test collections.

https://testflightapp.com/sdk/

Answer 8

See Ryan's answer in How to View NSLog Instructions from ipapp.app for a Free Utility Provided by Apple.

But this is not a convenient solution. If you can afford a new build, you must change your registration in the application. Jano has some very good ideas about this in How to NSLog to File . Especially option 2 should do without much effort.

In general, I would recommend hiding your own logging facilities behind a facade or similar design only at the beginning of the project, regardless of what programming language is used.