I am writing a MailStatistics app that need to go to the file ~/Library/Mail/Envelop Index to get the mail information. My app does not write anything into the file system but when I submitted it to the Apple Store, the app gets rejected because: "Apps that do not comply with the Mac OS X File System documentation will be rejected"
Does anyone know all possible reasons that can lead to this specific rejection
I think I know the problem, it may be because I set the mode to become READWRITE instead of READONLY. I changed it back and hope that Apple will accept it this time
Related
I used to be able to use mach_override to hook any exported function on Mac OS including Catalina. However, now the target app crashed every time and I check the Console and find the following error:
CODE SIGNING: 30911[app] vm_map_protect can't have both write and exec at the same time
What's going on and is that possible I can bypass it without touching the target app's signature?
The hardened runtime is designed specifically to prevent that sort of hooking. The target app's entitlements would have to opt-in to allowing it. If you find a way around it, Apple would consider that a security hole bug and patch it in a future OS release.
It should work if you disable System Integrity Protection, but I don't know if that suits your purpose.
I'm developing an application on MacOSX (using Qt) and my users starts to use it.
It writes a log to ~/Library/Logs/MyOrganization/MyProgram.log
I would like to be able to get the log and the crash information from the user in the easiest way possible for him.
Is there a way to handle application crash default dialog from Macos?
I found the killer module to perform what I want to do: https://github.com/tcurdt/feedbackreporter
I sent my first desktop OSX app out to a small circle of testers today. One user cannot get past the splash screen.
I am wondering how one might debug something like this? Would I somehow write NSLogs to a file? Or does OS X have some sort of utility? I assume I need some sort of logging capability, right?
You can write your logs to file quite easily (not via NSLog, but just plain writing NSString to disk via writeToFile if you want to). You can also have your logs automatically uploaded to your server if you have one using NSURLConnection with a POST.
I prefer the latter because it requires little intervention from the testers, and happens automatically.
Distribution builds are not ment to be debugged or else it would have been development build.
You can how ever sync your device with itunes and then get the crash report(if you want to know the source of crash).from appdata.
reffer to this link. if you want to debug make a debug build with development provisoning. in your case ask the tester to send you the crash report and you keep the ipa or app file safe you will need it to read the crash report.
I have a cocoa app which uses core data. Everything seems to be working fine.
However, in a very specific scenario the app was behaving very strangely for our client.
In particular the logs shows this appearing in the output many times (which I've never seen in my testing):
Core Data: annotation: -executeRequest: encountered exception = Updating max pk failed: with userInfo = {
NSSQLiteErrorDomain = 14;
}
Has anyone ever seen this message and do you know what it means? I've tried googling it but found no information other than a few message boards regarding the Growl app having similar problems, with no solution yet available.
Sorry that I can't be more specific regarding what causes this as I'm not even sure myself. I know how to reproduce this on the client's machine but this message seems very random.
I was hoping someone could give me some more information as to what this error means exactly so that I can maybe narrow it down some more. Right now I'm pretty clueless.
Note: This appears on a macbook pro running 10.7.2 (if that matters).
Thanks for any kind of help you can provide, even something vague would help me at this point.
Update:
The managed context "save" method also fails with the following error:
The operation couldn’t be completed. (Cocoa error 134030.)
This is not really a Core Data problem as such, but more an issue of you process running out of file descriptors.
Each process has a limited number of file descriptors. If you run out, Core Data (and many other things) will stop working, because they can no longer open files -- any they'll fail.
First of all, make sure you're not leaking file descriptors, i.e. make sure you close files when you no longer need them.
I'm not sure what kind of changes you're trying to track. Take a look at Tracking File-System Changes.
If you're on 10.7, take a look at dispatch sources and DISPATCH_SOURCE_TYPE_VNODE for a very powerful tool to track file system changes (corresponds to kqueue, but is easier to use).
Core Data also gives this error in a Sandboxed app when it tries to save DB to a location where it doesn't have full read/write access to (if a user opens file for example, Core Data will be able to read/write this file, but not anything else to the same folder).
Core Data fails to write the temporary _journal file to this folder and reports this error.
I'd like to know if there is any way how to set default OS X Crash reporter email address to my email address (for my cocoa application).
I'd like to get my Crash reports to my email, not Apple's. ;)
Thank you.
As mipadi stated, crash reports arent sent by email, but are uploaded to some Apple server. To intercept this and/or send it to your own server there are already several classes and frameworks to handle this, here are a few:
More sophisticated (catch the event):
Breakpad (by Google, catches the event, generates its own crash dump (minidump) and simulates the Apple crash reporter interface with your company name in it)
PLCrashReporter (Similar to Breakpad, catches the event, generates its own crash dump, but no default UI is provided. The library is best suited for iOS -- it was written to operate within the AppStore's constraints, and x86-64 support on Mac OS X remains experimental).
Simple (read the crash dumps):
UKCrashReporter
SFBCrashReporter
ILCrashReporter
No, crash reports always go to Apple. If you want to automatically receive copies of your application's crash reports, you'll have to write your own solution. One way would be to check ~/Library/Logs/DiagnosticReports for .crash files containing your app's name, and automatically email them to you, although that'll add overhead to your program so you'll have to decide if it's worth it.