But it clearly does not fail on my system. The Verification test in XCode during the submission should (I assume) test this. And running codesign on the command line of the archived app results in:
/Users/iac/Library/Application Support/Developer/Shared/Archived Applications/272860A0-961E-47E7-B62F-0F7D373D938A.apparchive/Kiwi.app: valid on disk
/Users/iac/Library/Application Support/Developer/Shared/Archived Applications/272860A0-961E-47E7-B62F-0F7D373D938A.apparchive/Kiwi.app: satisfies its Designated Requirement
Anyone run into something like this before?
Thanks,
Isaiah
After a bit of back and forth the app was placed back "In Review" (without any change to the binary). It was then rejected again for another odd reason (No non-apple installers allowed) after which it was again placed back "In Review," (again without any changes to the binary).
After a few more emails it finally received a rejection that made sense: a few files in my resource folder had overly restrictive permissions.
So the answer is: double-check your file permissions or be doomed to weeks of confusion.
Isaiah
Related
We are developing a document-based Objective-C project, using NSPersistentDocument and NSPersistentStore to save a unique binary file on disk. No autosave.
One customer has a recurring saving issue
The document "something.extension" could not be saved
that we cannot reproduce in our development setup. They can load their saved file without issue, but after a few changes the error pops up when trying to save. In our own setup, using the same build, the file opens and saves without issue.
The error is too vague for us to pinpoint the exact reason why their document would not save, but based on the very basic error message, we have realised the error raised is NSFileWriteUnknownError = 512.
In which situation would that error be raised? In which situation wouldn't the other, more specific error codes be applicable?
We build using SDK 10.14 and both us and the customer run on macOS Monterey 12.3.1
EDITED ON 09/08/22 - Added details based on Willeke's comments.
EDITED ON 17/08/22 - Underlying error
The error's userInfo comes with an underlying error message, which our customer could display. It states "No known persistent store for URL"
I'm trying to troubleshoot an issue on watchOS.
I'm not sure how to reproduce the problem I'm seeing, but I do encounter it occasionally during testing on a real device in the wild, so I'm trying to use os_log in order to diagnose the problem after the fact.
As a first step, to make sure I understand how how to write to the log and access it later, I've attempted to log an event any time the app first loads.
In the ExtensionDelegate.swift file for my app, I added this:
import os.log
extension OSLog {
private static var subsystem = Bundle.main.bundleIdentifier!
static let health = OSLog(subsystem: subsystem,
category: "health")
}
Then, I updated the applicationDidBecomeActive delegate function with this:
func applicationDidBecomeActive() {
os_log("App Started",
log: OSLog.health,
type: .error)
}
I know it's not really an error message, but from what I've read, messages that are not .error are not written to saved to the log for later. I want to make sure it gets written to the log like a real error would.
I installed the sysdiagnose profile, then installed the the most recent version of my app.
After testing the app for the day, I attempted to export the file. Following the instructions I've found elsewhere, I produced a sysdiagnose on Apple Watch by holding the Digital Crown and Side button for two seconds (and felt the haptic feedback when I released).
Then, I put the watch on the charger for a few minutes per the instructions here, which recommended 15 minutes.
I opened the Watch app on my paired iPhone, then went to General > Diagnostic Logs and downloaded the sysdiagnose from Apple Watch, and sent it to my computer with AirDrop.
This gave me a tarball file (for example, sysdiagnose_2021.03.05_17-01-57-0700_Watch-OS_Watch_18S801.tar.gz). Once I decompressed that, I had a folder of lots of files and subfolders.
After poking around in this folder, I figured my best bet was to look in the system_logs.logarchive file. I opened that in the macOS Console app, set the Showing dropdown to All Messages, and looked around the time I opened the app. I didn't see any log output from my app.
I also filtered for "App Started" (the log message from my app) and didn't find anything.
Then, I filtered by category for "health" and didn't find the event I had logged.
Is system_logs.logarchive the correct place to be looking for the log output from my app?
If not, where should I be looking? Or what am I doing wrong?
I really want a better understanding of how I can log messages on Apple Watch so I can view them later so I can make my Apple Watch apps more robust, but I'm at a dead end.
Am I looking in the wrong place? Or am I setting up the logging wrong? Or is it something else? I would appreciate any guidance about this!
According to the Apple Dev Forms, sysdiagnose allows you to view the logs on your apple watch.
I want to be able to read a crash log and send it to my server. I've seen libraries that do this, and I'm actually basing my code on them -- except many of them seem out of date, which is why I believe I'm currently having a problem with OSX sandboxing.
There seem to be 2 parts to any generated crash log. In /Users/zane/Library/Containers/**[BUNDLE_ID]**/Data/Library/Application Support/CrashReporter there is a .plist with not much information. One thing it does contain, though, is a Path to ~/Library/Logs/DiagnosticReports/**FULL_CRASH_FILE**.crash
However, when I try to open this full path via [NSString stringWithContentsOfFile...] I get a read access error:
Error Domain=NSCocoaErrorDomain Code=257 "The file “Aftermath_2014-02-12-210934_inZania.crash” couldn’t be opened because you don’t have permission to view it." UserInfo=0x600000264700 {NSFilePath=/Users/zane/Library/Logs/DiagnosticReports/Aftermath_2014-02-12-210934_inZania.crash, NSUnderlyingError=0x600000246900 "The operation couldn’t be completed. Operation not permitted"}
I take it that this is a problem with entitlements/sandboxing. Is there any way I can gain access to this file, or otherwise get a full stack trace to send to my crash reporter?
You can check the permissions of the log file!! It may need root permissions to access!
This question already has answers here:
How to obtain codesigned application certificate info
(2 answers)
Closed 8 years ago.
I have app signed. I created an identity and used codesign to sign my app as per Apple's Code Signing Guide.
Now, how do I check the signature from within my application?
I need to verify this on Cocoa apps (Objective-C) and apps written in C.
You could use NSTask and run "codesign --verify" and check the exit status. Of corse if the program was altered it could be altered to remove the check, so I'm not sure what that buys you.
If you are not worried about directed tampering (like the kind that might remove your check of the signature) you can use the codesign "kill" option, if you do merely executing means the signature is valid (at least for all pages that have been executed so far...but if a not-yet-resident page has been tampered with you will get killed when that one is read in anyway).
Maybe if you could explain a little more about why you want to verify the signature a better answer could be formed.
Note: Currently MacOS X does not verify signed code prior to execution. This may be different for sandboxed code, and it would seem sensible that it is otherwise anybody could edit the entitlements.
To check an applications signature from within the application itself you use the Code Signing Services. In particular look at SecCodeCheckValidity. The code to do the checking is not long, but there is quite a bit to understand so I won't give a code sample - you need to read and understand the documentation.
Checking the signature allows your application to detect changes to its code & resources and report it is "damaged" (it may well be, not all changes are malicious) and refuse to run. Adding such code does not of course guarantee your code is not damaged, but certainly it does raise the barrier higher against intentional damage (and if MacOS X starts doing the check itself then there will be a big win).
The way signiture verification is implemented on iOS is that when an application is being launched, the launchd daemon decrypts the binary using that device's specific private key (this is why you can't just decompile apps or copy-paste them from one device to another), if the decryption fails, the application fails to launch.
The native tools that do this are not available within applications due to the iOS sandboxing.
If you're simply attempting to track if someone has modified your binary, you can perform an MD5 or SHA1 hash of it, store it in NSUserDefaults and compare it at each app start. If the hash changes between executions you know it has been modified (possibly by a legitimate application update or possibly nefariously.)
Here's an example on how to get the hash of an NSData.
The binary file you're looking for is: AppName.app/AppName
A user has just submitted a bug report to me, saying that my app crashed. The user also attached a throw call stack.
The part which seems to have caused the problem is:
3 My App 0x000000010d005483 My App + 17539
Is there a way to translate that address and/or the + 17539 to a line number in my code?
Keep in mind, I wasn't able to reproduce the bug on my machine, so I can't just build it in debug mode.
Check out this Tech note from Apple.
... This trace is similar to what you would see when stopping execution in the debugger, except that you are not given the method or function names, known as symbols. Instead, you have hexadecimal addresses and executable code - your application or system frameworks - to which they refer. You need to map these addresses to symbols. Unlike crash logs from Mac OS X, iPhone OS logs do not contain symbol information when they're written out. You have to symbolicate iPhone OS logs before you can analyze them.
I've been using GDB to do manual symbolication. It'd be too cumbersome if you were doing it a lot, but the typical crash log doesn't have very many symbols, and I only need to symbolicate a crash log once in a while.
The procedure is as follows:
Put the .dSYM file for your app in the same folder as the .app.*
Open Terminal and cd to the folder from step 1.
Start your app up in GDB:
$ gdb YourApp.app/Contents/MacOS/YourApp
Set the print asm-demangle and print symbol-file options:
set print asm-demangle on
set print symbol-filename on
Use the p/a command to find the line numbers for each address in your stack trace:
p/a 0x000000010d005483
These instructions are from this page (apparently no longer online).
*Note that the .dSYM has a UDID tying it to the particular build it was created with. So, if you don't have the original .dSYM file, you're in trouble. Theoretically, you can't even just pull the same revision from source control and rebuild because this UDID will be different.