Recently we came across a situation where we wanted to see the debug info from the app which a user has on his device. So, what I am looking for is a way to find the log on the device, paste it as inline text on a mail and allow the user to send it..
Any ideas? Here are the questions again.. 1)Find a debug log on the device 2)open the file and attach the contents of the file as inline text in to the mail. 3)Allow the user to email it the next time app launches..
Thanks,
Thanks for all the inputs guys.. I clubbed your solutions into one that would solve my problem.. Here is what I made it to be.. Surely I did not compile the code, it is a half baked code.. but I will iron it soon once as I implement it in my code..
NSLog into file How to NSLog into a 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 the Crash and Log them too into a File
First, create a function that will handle the error and output it to the console (as well as whatever else you want to do with it):
void uncaughtExceptionHandler(NSException *exception) {
NSLog(@"CRASH: %@", exception);
NSLog(@"Stack Trace: %@", [exception callStackSymbols]);
// Internal error reporting
}
Next, add the exception handler to your app delegate:
-(BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:
(NSDictionary*)launchOptions
{
NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler); // Normal launch stuff
}
Set a variable in the info.plist called 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];
}
Once the app launches read the info.plist and prompt the user to submit the crash logs..
{
MFMailComposeViewController *mailComposer = [[MFMailComposeViewController alloc] init];
mailComposer.mailComposeDelegate = self;[mailComposer setSubject:@"Crash Log"];
// Set up recipients
NSArray *toRecipients = [NSArray arrayWithObject:@"first@example.com"];
[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];
}
For logging your own data, use Cocoalumberjack. It is much faster than NSLog and can be turned on/off dynamically. It also provides options to save the data into a file. NSLog will slow down your app and fills the console log. Also you don't want to log too much in general. You cannot safely do logging when the crash happens. So rather once you figured out where the problem area is, add some more logging there and try to reproduce it, e.g. by using automated testing frameworks like KIF.
For catching crash report you should nothing else than a solution based on the open source framework PLCrashReporter, which can safely catch crashes, also when you app is already in the app store! Exception catching as suggested by others is not recommended, check this article to see why!
iTunes Connect offers you to view some crash reports too, but it takes up to 2 weeks to see some, but by far not all as e.g. pointed out by the Camera+ developers. So you better use your own solution.
PLCrashReporter will send you standard apple formatted crash reports, ready for symbolication, so you know where the crash happens in your code, including line numbers.
Some solutions based on PLCrashReporter are:
The proposed solutions either allow sending the data automatically on the next startup or by asking the user if he/she agrees to send.
For logging & analytics under Swift you can use SwiftyBeaver, it is a full-featured logging platform including open-source Swift 2 & Objective-C Framework, encrypted cloud storage and Mac App.
Website: https://swiftybeaver.com
Framework (supporting): https://github.com/SwiftyBeaver/SwiftyBeaver
Disclaimer: I am a founder.
This is a solution that catches crashes as they happen, it will give more human readable code info than a crash log. It will lack some of the crash log, but as Till says, you should be able to access those anyway.
From another SO question about the Xcode 4.2 always returning to main upon crashing. The answer there uses this method and you can extend it to keep track of crashes.
implement your own exception handler in the AppDelegate
// on load
NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler);
void uncaughtExceptionHandler(NSException *exception) {
NSLog(@"CRASH: %@", exception);
NSLog(@"Stack Trace: %@", [exception callStackSymbols]);
// Internal error reporting
}
UPDATE I did some backtracking and this solution was offered by Zane Claes to the question Xcode 4.2 debug doesn't symbolicate stack call
He offers a general solution in his second comment. "I find it to be useful to write the crash log to a file and prompt the user to submit it on the next launch (in release mode only, to not get in the way of debugging). This lets me get great bug reports... and the users know that their problem is being addressed" I understand not everybody would like to ask this of the user, but there are super users out there that would be glad to help out.
You could of course include a never show me this prompt again button so that people are not frustrated by reporting mechanism.
Alternatively, You could reach out to a server with the info (not sure if it will work as it is crashing, but save it and occasionally try to POST to a server with the details)
I've been using Crittercism to automate this for me. Works for testing and in production too.
BugSense provides crash reporting services for iOS. Apart from providing a fully symbolicated stack trace, BugSense provides analytics for your crashes, across all your applications.
I think it's better than email, because when your app becomes popular you will need to manage all these emails manually, while BugSense does this automatically. However, BugSense is also open-source, so you can modify its internals any way you want and add any additional functionality.
In addition to that, you get us to work for you for free: If you have an idea about a cool new feature that you want us to have, we'll do it -provided we think it's cool, too.
Disclaimer: I write the code for BugSense-iOS.framework.
See Ryan's answer in How to view NSLog statement from iphone .app file for a free utility provided by Apple.
But this is still no convenient solution. If you can afford a new build, you should change your logging within the app. Jano has some very good ideas on this in How to NSLog into a file. Especially option 2 should do without too much effort.
In general I would recommend hiding native logging facilities behind a facade or similar design just at the beginning of the project regardless what programming language is used.
I have used below code to catch debug logs - Swift 4.1
var paths = NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true)
let documentsDirectory = paths[0]
let fileName = "Logfile.txt"
let logFilePath = (documentsDirectory as NSString).appendingPathComponent(fileName)
freopen(logFilePath.cString(using: String.Encoding.ascii)!, "a+", stderr)
If you use the TestFlight with their SDK this is automated. It's a really nice system. For test builds only, however.
