I have an application which needs to run an external program.
I have included this program as an Embedded Framework. When archived, it appears at the location %AppRoot%/Contents/Frameworks/MyExternalApplication.
How can I run this program from my app's code without using an absolute path? I'd like to run in both release and debug.
Thank You!
You can run the executable by using an NSTask object or the posix_spawn() function.
You can use the NSBundle class to find the absolute path of the executable. See this article for details.
Notes:
That is not the correct place within the app bundle to place the executable; I believe it should be in Contents/MacOS, as documented here.
If the main app is sandboxed (a requirement if you want to put the app on the Mac App Store) then an entitlement is required that will be embedded into the external executable so that it inherits the app's sandbox. See this question for details.
Once you've done 2. you will notice that the executable will no longer run from the command line, but that's nothing to worry about, as it will run from within your app.
Related
I am a new guy in OC programming. Now I am involved in a framework development project.
I know the framework works as a library, which contains a group of methods. It's not an application that can run on devices.
Actually, our framework will work with customer's application. We want to investigate what happened inside our framework when customer's application crashed. So I want the 'DSYM' file of our framework, instead of an application.
As far as I know any iOS application does have corresponded 'DSYM', but I didn't find the 'DSYM' of our framework.
Does iOS framework project have 'DSYM'? If it does have, how can I obtain it?
By the way, I am using Xcode 8.1.
Thanks!
According to my observations, .dSYM files are generated for iOS dynamic framework built with Release configuration only.
After build succeeds, the debug symbols files can be found at these paths, for a device and simulator, respectively:
<Build_Root>/build/Release-iphoneos/<Product_Name>.framework.dSYM
<Build_Root>/build/Release-iphonesimulator/<Product_Name>.framework.dSYM
, where
<Build_Root> is usually a subdirectory within Derived Data directory;
<Product_Name>is the name of your framework.
Yes, you can generate dSYMs for dynamic frameworks. There are a few relevant build settings that control whether and where these files are generated:
DEBUG_INFORMATION_FORMAT = dwarf-with-dsym,
DWARF_DSYM_FOLDER_PATH = "$(CONFIGURATION_BUILD_DIR)",
DWARF_DSYM_FILE_NAME = "$(PRODUCT_NAME).dSYM"
Obviously, you can set these to whatever you want, either in your project's build settings in Xcode (the project.pbxproj file) or as arguments to xcodebuild (depending on how you generate your framework).
DSYM (Debugging SYMbols) files generally store the debugging symbols for your app. And if app crash any where symbols replaced with appropriate method name so that it could help developer in a readable form. And for that you can use the crash log and they can be find in the iPhone where the app is installed. Each app and device have their own crash log.
Also please check this link it might help you.
Read Crash Report
Upload Symbols for iOS Framework
Hopefully these might help you or guide in the right direction.
I'm building a small command-line utility (not an app) with xcode. All I want to do is the equivalent of a gcc -o name, and I'm completely stumped. I can compile just fine in xcode, and execute the result inside of xcode, but I can't for the life of me find the executable image anywhere on the disk. There's nothing at all executable in the .../DerivedData folder, for example. How do I tell Xcode to create a stand-alone executable image (that I can launch from a Terminal window) and put it in a known location?
Found the answer. When you select the Product for the application, make sure that the application is set to Unix Executable (it defaults to something else). The full path to the product is displayed further down in the dialog.
I have created a cocoa application primarily to run on OS 10.6.8. to convert certain types of proprietary legacy files. The app looks at the legacy files creator code and processes it accordingly if it is a known type. Once the file is identified, I call an external legacy app (which I have added to the project) using [NSWorkspace openFile: withApplication: ]to open the droplet and process the file conversion.
The application works just like it is supposed to until I archive it and try to run it from the application bundle. Actually, it will continue to work but it is using the converter app from the project. If I delete the converter in the project area, then the app in the app bundle can not open the external app in that location. One work around is to delete the external app from the bundle after its archived and replace it with a copy of the one in the project area.
I would appreciate any suggestions on resolving this. I'm not sure if the problem is in some Xcode build setting I can change to include an external apps resource fork when archiving, or if this is a launch services issue with apps hidden in packages, or , something I'm not even considering.
Thanks
Mike
Try setting the "Preserves HFS Data" (COPYING_PRESERVES_HFS_DATA) build setting.
I want to test deployment of my first mono mac app. (yay!)
But I need to create directories to save data in. But I would like to do it part of my install process on the mac. I have no clue how to make that part of the monomac packager???
You might have to forgo creating these folders as a part of your install process and instead modify your application to check for them, and create them if they do not exist, because AFAIK, the current mac-bundle plugin to mdtool doest support that level of customization
I have a Cocoa application which uses an installer. I want to be able to run code coverage over the code (after it has been installed).
This is not the usual unit-test scenario where a single binary will run a suite of tests. Rather, the tests in question will interact with the UI and the app back-end whilst it is running, so I ideally want to be able to start the application knowing that Gcov is profiling it and then run tests against it.
Any ideas?
Update
Thanks to mustISignUp. To clarify why I asked the question:
The mistake I made was thinking that the object, .gcno and .gcda files had to be installed alongside the binaries (thus making the installer difficult). As it happens, the original location of the files is hard-wired into the code along with the instrumentation code.
The solution I went with is zipping up the code on the build machine and putting it on disk on the test machine. lcov (or just gcov) can be run from there. Alternatively, the .gcda files will be created on disk and they must be copied back up to the machine containing the source code.
Either way, the source code doesn't have to be present at install and run time, but if you want to get your results back lcov-style, the coverage counter files produced must be reconciled with the source code.
The app needs to be compiled with the correct GCC flags which will insert the profiling instructions into the code. It isn't something you can turn on and off. ie your code is modified at compile time to output the coverage info.
So, if you compiled the app with the correct flags it will emit coverage data, if you didn't, it won't (and you certainly wouldn't want it to for an app you were going to distribute).