Is there a way to retrieve logs after a crash with codename one? I have a process that does a large data conversion and my app crashes/closes while trying to complete it, only on iPhone.
I do have premium/crash protection on, but I don't get an email from this. I'm wondering if I can look at the logs and not have them wiped by closing/re-opening the app?
Opening the app appends to the logs, you can add a "Send Logs to developer" button or hidden feature and invoke Log.sendLogAsync() to email the log to you.
If this doesn't include what you need I would also suggest including the native logging cn1lib since it might include information about the crash.
Looking at the changes introduced in 2016 to logging in iOS, I am wanting to locate the .logarchive file and attach it to an email programmatically in swift.
The following lead me to believe that this is not possible, but I was hoping someone out there has had some success.
Obtaining app logging
Release build debugging strategies
Unified Logging and Activity Tracing
These articles seem to suggest that the user needs to explicitly connect their device to a computer to access the logs. I am wanting to have the user simply tap a button in the app and be able to send us their console logs.
From iOS 15 OSLog can be read programmatically using OSLogStore. Unfortunately there is no system provided function to write it to a logarchive. For now you need to build the body with formatting of the file yourself.
I need to read the console logs from inside of the app, the idea is to use it in internal environment to help users report bugs to us with an internal library that comes bundled inside of the app.
How can I get the log in swift?
CLARIFICATION: I dont want to see the iOS logs from device in my computer, I need to get them programatically from inside of the app.
Maybe check out logging libraries like CocoaLumberjack[1]? It provides file logger (which you can configure to fit your needs: file limit, size limit, rolling, etc), then you can send such file to the server if needed.
[1] - https://github.com/CocoaLumberjack/CocoaLumberjack
I’m building Cocoa Touch Framework. I want to send my SDK logs to remote server. The approach I have applied is using below:
freopen([logFilePath cStringUsingEncoding:NSASCIIStringEncoding],"a+”,stderr);
The above code writing console logs in file, but the problem is this also writing system logs and will write app logs which is not useful for me. I need only my SDK logs and using this I’m not able to filter logs while writing in file.
Second way is wherever i have NSLog in my code, write into file. But in this scenario I want to understand, how I will get exception messages if app crashes due to my SDK or will this continuous write and read operation makes app performance low.
So what is the best way to collect SDK logs and send it to server.
Let's say you have a app which uses passwords. During development, you want to troubleshoot some things, and use NSLog() to print out the password to see if it is working properly.
At a certain moment you are happy and everything is working.
You send your app to Apple and finally the app is accepted and submitted to the App store.
You forgot to remove the NSLog() which output the password....
Is there any way this can be bad? Or is there any way a hacker can listen to those NSLogs()?
Yes, this could be very bad, if your app crashes. Once users sync their device, the crash logs will make their way to their computer, along with the content of NSLog. This makes plaintext passwords available to anyone with a binary file reader.
For example, if Alice gives her phone to Bob, then Bob enters his password, completes his task, logs off, and gives Alice her phone back. Then your app crashes. Once Alice syncs her phone, she gains access to Bob's password.
Yes, this is bad. I have seen discussions in which attackers quickly asked about device console logs. Using the strings from those logs, they can quickly search the executable binary for similar strings, like the format string used for part of the log entry. Example:
NSLog(#"user entered password '%#'", passwordString)
Finding the format string, they can quickly find the part of code that actually uses that string, and thus they have found the part of code that processes passwords. They can then analyze the relevant code to bypass the password altogether or do whatever they want.
Even if the device does not hold a lot of console data for long, all an attacker might need to do is connect a stolen device to a computer, start the app and enter a random password. If the app logs the password (correct or incorrect), then the needed strings are still captured and the attack begins.
Of course, if the log line is still in the device console data, an attacker also gets the actual password for an actual user. And if that user reuses user names and passwords (as many people do) the attacker may now have the credentials to a user's other accounts on the internet, which may be more sensitive.
Many programming discussions advise against using NSLog directly and recommend using a macro like DEBUGLOG which will compile out of release builds. If that is used for debugging, then the app will not leave such clues for an attacker to use.
I guess . device log would contain that password !! this can be seen at xcode-window-device/device logs .
It depends on what kind of passwords your storing.
I believe that log files are stored on your iPhone. But I'm quite sure that reading these files without connecting the actual device to a computer is impossible.
Extra note: If I have to be honest, I wouldn't reject my app for reviewing at this moment. It's a good idea to prepare a patch and when your app is reviewed you should upload the new version as soon as possible. However if your saving passwords that connects the app to some sort of database, I would reject it.