Archived App not working. Run from XCODE successful - objective-c

I have made an app with swift which is working when I run it from XCODE. However, when i try to archive it and run the .app, it will not start.
How can I check why the app is crashing/not starting? What can be the reasons?
This is what the console output if I enter the packe and start it from the folder Contents/MACOs
Mislavs-MBP:~ proslav$ /Users/proslav/Desktop/trackingCore.app/Contents/MacOS
/trackingCore ; exit;
dyld: Library not loaded: #rpath/SQLite.framework/Versions/A/SQLite
Referenced from: /Users/proslav/Desktop/trackingCore.app/Contents/MacOS
/trackingCore
Reason: image not found
Trace/BPT trap: 5
logout
running it from the terminal gives the following output
LSOpenURLsWithRole() failed with error -10810 for the file /Users/proslav
/Desktop/trackingCore.app.
I have added a framework https://github.com/stephencelis/SQLite.swift to access a SQLite database. That is the library that is not loaded although it exists in the .app

I found the answer. In the copy files i was linking to resources instead of frameworks. It seemed to be no problem for run but it was for archving.

Anyone arriving here based on the title, note that Xcode OSx builds are broken now.
https://developer.apple.com/library/mac/qa/qa1884/_index.html
They recommend using command line tools;
$ productbuild --component Sample.app /Applications --sign “3rd Party Mac Developer Installer:" Sample.pkg
$ sudo installer -store -pkg Sample.pkg -target /

Related

Cocoa Sandbox App: Spawn FFMPEG

I have an application which uses FFMPEG and FFPROBE to perform some tasks on a video the user can open with my application.
For non-sandboxed applications everything works fine, but when my app is running in a sandbox FFPROBE doesn't seem to get started.
The Console says the following:
08.06.15 12:27:55,803 secinitd[281]: ffprobe[4049]: registration request failed: (0x11, 0x0) Container object initialization failed.
failed to get bundleid for app "/Users/Alex/.../ffprobe"
The path to ffprobe mentioned in this messages points to the MacOS directory within the app bundle (a Build Phase copies these two binaries into the executable directory).
I've searched a lot and found some hints regarding entitlements. Of course my sandboxed app has its entitlements and when building my application it gets signed (with --deep signing flag). It even passes the technical App Store check for entitlements.
Now I'm stuck and wonder why my application is not able to launch FFPROBE (and FFMPEG).
Does anybody have a clue?
It seems like I've found a solution. I don't know whether all of these steps are necessary, but here is what I've tried and what seems (!) to work:
I added an entitlements file which contains true for the keys com.apple.security.inheritand com.apple.security.app-sandbox
I added a plist file for each used binary and filled the keys CFBundleName and CFBundleIdentifier with suitable values (I don't know whether this step is necessary)
I added a Run Script build phase which executes codesign -f -s "your certificate" --entitlements ./ffmpeg.entitlements ./Build/Intermediates/ArchiveIntermediates/App\ Store/InstallationBuildProductsLocation/Applications/<my app>/Contents/MacOS/ffmpeg
for each binary used.
These steps result in suitable entitlements when trying to submit the app to the Mac App Store and it results in a correct usage of the embedded binaries (at least on my development Mac and the Mac of some colleagues).

XCode 6.3 Code Signing Issues after update

I've updated recently to XCode 6.3 and started having some strange code signing issues. Occasionally XCode will start complain about the code signing issues. And either will have issue like :
invalid or unsupported format for signature ... Command /usr/bin/codesign failed with exit code 1
or
... Command /usr/bin/codesign failed with exit code 11
Can not find pattern yet, but looks like issue with XCode code sign, as sometimes after cleanup and restart of XCode it will work.
I did not change any settings regarding code signing. Project structure is quite complicated, it has referenced projects and pods.
Any help appreciated.
** Update **
It did not help for me to remove derived data or restarting XCode.
But it did work if i removed the project and downloaded fresh from git. This removed XCode files which are not committed to git.
Again after clean it has stopped working. And in the console logs i've got something like this:
codesign[4111]: Internal error unloading bundle CFBundle 0x7fb44a40adc0 <(null)> (framework, not loaded)
** Another Update **
Found on twitter someone who has the same issue.
Looks like the issue is caused by --deep option in code signing.
https://github.com/atom/atom-shell/issues/1396
Solution is to not code sign app and frameworks inside with --deep. But rather code sign each framework separately.
http://furbo.org/2013/10/17/code-signing-and-mavericks/
Just had this happen to me as well after the latest X-Code update. But X-Code had been advising me to update my project settings for a while now, I just hadn't got round to it. The link you provide explains it well.
It actually shows up as an issue in the navigator, and X-Code will offer to fix it automatically for you when you select the issue. You just need to remove the --deep option from your Build Settings yourself.
This worked with my 2 3rd party frameworks, Sparkle and Syphon.
Problem was caused by --deep code signing option and entitlements.
To solve it i had to manually code sign the frameworks.
This required adding new run script build phase, and running script similar to this one:
IDENTITY="HEX_IDENTITY"
export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate"
FRAMEWORKS_LOCATION="${BUILT_PRODUCTS_DIR}"/"${FRAMEWORKS_FOLDER_PATH}"
EXECUTABLES_LOCATION="${BUILT_PRODUCTS_DIR}"/"${EXECUTABLE_FOLDER_PATH}"
codesign --verbose --force --deep --verify --sign "$IDENTITY" "$EXECUTABLES_LOCATION/MY_HELPER_APP.app"
codesign --verbose --force --deep --verify --sign "$IDENTITY" "$FRAMEWORKS_LOCATION/MY_FRAMEWORK/Versions/A"
HEX_IDENTITY can be obtained by using shell command:
security find-identity
This will display list of signing identities with their hex numbers.
After exporting application as the app I verified the code signing with command:
codesign --verify --verbose --deep MyApp.app
spctl --verbose --assess --type execute MyApp.app
References:
http://furbo.org/2013/10/17/code-signing-and-mavericks/
https://developer.apple.com/library/mac/technotes/tn2206/_index.html

iOS: XCode 4.4.1: xcodebuild error - Unable to read diagnostics from file

So I would like to use xcodebuild in Terminal to create a build from a test application (called RunTeszt1). The app is an iOS single view application with nothing in it, just created and closed.
When I this from the Terminal, the build fails.
xcodebuild -target "RunTeszt1" -sdk "$iphoneos5" -configuration Debug
The error is:
Unable to read diagnostics from file "/var/folders/6s/cjw35hhs5lb6wpnx9m8lr2km0000gn/C/com.apple.Xcode.501/SharedPrecompiledHeaders/RunTeszt1-Prefix-eqntxoxxhhlzvieuipqbxfumbpxb/RunTeszt1-Prefix.pch.dia" (Invalid File): Bad header in diagnostics file
Please file a bug at http://bugreport.apple.com with this warning message and any useful information you can provide.
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1
When I run the app from XCode (4.4.1), the build completes and everything is ok. However, If I run the Console app and inspect the results after hitting build button in XCode, I see the same error message in the console. Nevertheless the build succeeds and opens the simulator.
Is this really a bug in xcodebuild which should be sent to apple? If it is I imagine a bunch of people already sent it.
How can I either make the error go away, or stop it from cancelling the building process, so circumvent it like XCode does?
Turns out the problem was code signing. Even though I put Don't code sign in the build settings, it still hanged up on it. Also it seems "-sdk xxx" was also at fault (no matter what sdk I specified).
Running this command resulted in a successful build:
xcodebuild clean build CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO -target RunTeszt2

How do I symbolicate a crash report of a Mac OS X app that a user emailed to me?

I am working on an app that I have sent to a few beta testers. Within just a few minutes of launching the app a user got a crash. When the window poped up saying the app had crashed he copied all of the text in the details section and emailed it to me. I have saved the text into a plain text file and given it the .crash extension which causes it to be opened by console like a regular crash report so I think I have the extension right (but maybe not).
The version I sent out was built by Xcode with the Archive option so Xcode knows where the app and .dSYM are.
I know that with iPhone apps you can drag a crash report to the organizer and Xcode will symbolicate it for you. I can not find anywhere that will take a Mac crash report.
I have looked at atos but it talks about memory locations including the location the app was running at and I don't see that information listed in the report I have. Looking at the raw crash report it looks like a view controller was released early but I can't really tell if that was the cause or a symptom.
My real question is; is there a way to have Xcode symbolicate the report or a tool that I can just hand over the .dSYM file, app, and report and get back a symbolicated report?
I've looked all over Google but everything I find (other than the previously mentioned man pages for atos) is about symbolicating iPhone reports, not Mac OS X ones.
Or as in answer https://stackoverflow.com/a/18354072/317461
Put your release build and your .dSYM file in the same directory and open terminal
$cd directory
$lldb MyApp.app
(lldb) image lookup -v --address 0x00085f3c
We had the same problem with our app and I was symbolicating the crash reports manually line by line with atos.
I now tweaked Apple's symbolicate script such that it works with Mac apps and crash reports from PLCrashReporter.
https://github.com/lksnmnn/Symbolicate-CrashReports
How to use it:
Make sure you have all of the following files on your computer:
The crash report: report.crash
The dSYM file of your app: MyApp.dSYM
The executable / app folder of your app: MyApp.app
The improved symbolicate script: symbolicatecrash
Now go in the command line (Terminal) and do the following:
# set the developer directory
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"
# Now run the script
/Path/To/symbolicatecrash /Path/To/report.crash > /Path/To/readable_report.crash
# Use -v for verbose logging.
The script will find your dSYM and your executable and symbolicates as much as it cans. You will now find your symbolicated report in the stated output file readable_report.crash
Build settings:
For proper reports and symbols, set your build settings to this:
Strip Debug Symbols During Copy: Yes
Strip Style: All Symbols
Strip Linked Product: Yes
Edit: Improved the answer such that it aligns with the Stack Overflow answer policy.
You can use GDB for Symbolication, Put your release build and your .dSYM file in the same directory
open terminal
$ cd directory
$ gdb MyApp.app
(gdb) info line *0x00085f3c

xcodebuild + iPhone fail under ssh with Couldn't load plug-in 'com.apple.Xcode.iPhoneSupport'

I'm triying to compile my iPhone app from ssh. This is for my build tool that run in another machine.
The base sdk is iPhone Device 3.0.
The error is : "Couldn't load plug-in 'com.apple.Xcode.iPhoneSupport'"
However, executing from the regular terminal run ok. Also directly from xcode.
This is the log:
[trtrrtrtr#mac-pro-de-trtrr-trtr ~/mamcx/projects/JhonSell/iPhone]$ xcodebuild -target BestSeller -configuration Debug=== BUILDING NATIVE TARGET Three20 OF PROJECT Three20 WITH CONFIGURATION Debug ===
Checking Dependencies...
No architectures to compile for (ONLY_ACTIVE_ARCH=YES, active arch=armv6, VALID_ARCHS=i386).
2010-04-27 16:16:50.369 xcodebuild[1168:4b1b] Error loading /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/MacOS/iPhoneRemoteDevice: dlopen(/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/MacOS/iPhoneRemoteDevice, 265): no suitable image found. Did find:
/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/MacOS/iPhoneRemoteDevice: GC capability mismatch
2010-04-27 16:16:50.371 xcodebuild[1168:4b1b] Exception caught: Couldn't load plug-in 'com.apple.Xcode.iPhoneSupport'
2010-04-27 16:16:50.373 xcodebuild[1168:4b1b] Error loading /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/MacOS/iPhoneRemoteDevice: dlopen(/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/MacOS/iPhoneRemoteDevice, 265): no suitable image found. Did find:
/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/MacOS/iPhoneRemoteDevice: GC capability mismatch
2010-04-27 16:16:50.373 xcodebuild[1168:4b1b] Exception caught: Couldn't load plug-in 'com.apple.Xcode.iPhoneSupport'
** BUILD FAILED **
If it runs fine under Xcode and terminal on the same machine then it is probably a permissions problem with the user in ssh.
It seems to be a problem in the XCode project. See the following line:
No architectures to compile for (ONLY_ACTIVE_ARCH=YES, active arch=armv6, VALID_ARCHS=i386).
It indicates that:
You enabled the "Build Active Architecture Only" checkbox in the "BestSeller" target.
You only have "armv6" as active architecture, whereas the only valid architectures are "i386".
I suggest you to check that these options are correctly defined under XCode. Then, you can go these ways:
perform a build under the XCode GUI.
perform a build on the command line.
on the local machine, use ssh to connect and perform a build on the command line.
on the remote machine, use ssh to connect and perform a build on the command line.
For each attempt, save the output and compare them. Maybe the architecture problem is not the only one, but by doing it by steps it will be easier to spot the problem.