Can one get access to the application source files on mac? In Applications folder any .app file can be explored and there get access to the header files, is it all or can the class files be accessed too?
Unless a Mac application includes private frameworks (in the application bundle), which includes their headers (rare), no.
Most of the time, a Mac application will just contain the application's binary, as well as resources (icons, images, L10N, etc.).
You may disassemble the binary, if you know how to deal with assembly language.
If the application was built with Objective-C, you can use specific tools to produce a header file from the binary, with all the Objective-C interfaces.
Take a look at ClassDump, for instance.
You may also use the nm command, on the application's binary, to get a list of the symbols it contains.
Related
I have a Qt app that uses Assistant to display help.
On Mac, I am packaging he Assistant inside the bundle. The only way I can include all its libraries is by placing the Assistant executable inside the same MacOS folder as the app executable, and properly link all the library dependencies.
Is there a way to place information about both executables in the Info.plist ?
No, you can't put info about multiple executables inside the same Info.plist. (Well, you an always puts custom keys into the Info.plist and store whatever property list data you like there, but the system won't pay any attention to those keys.)
Why not bundle the Assistant into its own bundle and put that bundle inside the main app's bundle? The Assistant bundle would have its own Info.plist file. Also, if you create a question about whatever linking or dynamic loading problems made you think you had to put it all into the main bundle, you might find there's a better solution.
placing the Assistant executable inside the same MacOS folder
I recommend not to do this. The Assistant is a resource to the main application and so it should reside in the resources folder. If you want to launch the Assistant app from the main app, you can then locate it by name.
You can only define one application in the Info.plist. If you were to add more, there would be a conflict in keys.
For example, CFBundleIdentifier is a unique URI that names the bundle (e.g. com.apple.calculator). The OS uses the URI to register the application with the OS when an application is, for example, copied to the /Applications folder. The OS expects the key to be a child of the root dictionary and its value must be unique. If there were multiple keys named CFBundleIdentifier, it would not know which is valid.
Although you can throw almost any junk into a Mac application bundle, much good will not come to you.
If I understand right, you have both a Mac Application (bundled normally) and a side-application you call the "Assistant" you want embedded in the same application bundle.
You also mention libraries (.dylib's I guess) that must reside in the same directory as the assistant.
Now - if these libraries are only used by the Assistant side-application, I would recommend that you bundle the assistant as a Code-bundle (Apple provides lots of information about these, and you have easy to use templates from Xcode). You can then use Xcode to copy it into the right place within the main application's bundle (I'd choose "Plugins") and use NSBundle APIs to launch it.
However, if those .dylibs are shared between the main app and the assistant - then I'd say go ahead, stick your assistant, .dylibs and main app's binary files in the same "MacOS-X" directory, and use posix APIs, or shell command to launch the assistant. Of course it will share (if possible) every resource of the main application, because they are located at the same place. However, the main app's bundle can only have ONE CFBundleExecutable entry, and that should point to your main application's binary.
I have an OSX application, and in the bundle's MacOS directory, I have an executable and a bunch of dylibs. The executable is, of course, pointed to by the Info.plist's CFBundleExecutable entry. When I try to sign it, codesign complains (as of 10.9) that my dylibs aren't signed, which makes sense. So I sign all of the dylibs, which I would think would let me sign the main executable now.
The problem is that I actually have a couple of data files in my MacOS dir, as well. The application is a cross-platform Qt application and the data files are localizations files that are found with respect to the main executable. codesign complains that it doesn't want to sign my main executable until the data files are signed.
Is this just a fundamentally wrong thing to be doing - putting anything that isn't mach-o into MacOS? Is signing those data files even a reasonable thing to do - ie like a .cat file on Windows? Clearly I wouldn't want codesign haphazardly slapping a digest hash on to the end of my data files.
Yes those data files should go into the Resources folder.
From the Bundle Programming Guide
MacOS (Required)
Contains the application’s standalone executable code. Typically, this directory contains only one binary file with
your application’s main entry point and statically linked code.
However, you may put other standalone executables (such as
command-line tools) in this directory as well.
Resources
Contains all of the application’s resource files. This contents of this directory are further organized to distinguish
between localized and nonlocalized resources. For more information
about the structure of this directory, see “The Resources Directory”
Codesigning the data files won't change them; they are simply recorded in the _CodeSignature/CodeResources file.
I'm building an iOS project that includes a sub-project whose symbols I would like exclude from the product's .dSYM DWARF file.
The situation is that the sub-project (a static library) contains valuable proprietary code that I would not want an attacker to be able to symbolicate, even if they had the dSYM files used for resymbolicate crash reports for the whole app. The subproject covers a very specific domain and is well tested independently, so I'm not worried about being unable to resymbolicate stack traces in that code. However, I do need to be able to resymbolicate crash reports for the rest of the app, so I need a dSYM (as distributing symbols with the app is not an option).
I've already managed to make sure that all of the relevant symbols are stripped from the binary, and setting GCC_GENERATE_DEBUGGING_SYMBOLS=NO removed a lot from the dSYM, but I'm still seeing class-private C++ method names inside the dSYM file. For reference, I'm using clang.
How could I produce a dSYM for my app without compromising the symbols of this sub-project?
With a bog-standard Xcode workflow, this might be difficult. You could probably do something with a shell script phase which moves the static library to a different filename ("hides" it) and then runs dsymutil on your main app binary to create a dSYM. Because dsymutil can't find the static library, it won't be able to include any debug information for those functions. Alternatively, you can create a no-debug-info version of the static library although this will take a little bit more scripting. A static library is really a zip file of object (.o) files -- you need to create a directory, extract the .o files (ar x mylib.a), strip the .o files, then create a new static library (ar q mylib-nodebuginfo.a *.o I think) and put that in place before running dsymutil.
I know no on way to selectively remove debug information from a dSYM once it has been created, though. It's possible to do but I don't think anyone has written a tool like that.
This may sound like I'm just looking for a .exe file, but I'm not all that familiar with windows. I have been using pyinstaller to turn my apps into binaries. My app relies on a lot data directories and third party binaries that I package within the same directory as the executable binary. For Mac, this makes things easy because the user only has to click on MyApp.app inside the applications directory which is like a link to MyApp.app/Contents/MacOs/MyApp. This way MyApp never has to be touched and is all bundled together with the data directories (also loaded inside of MyApp.app/Contents/MacOs/).
However, I can't really find a windows equivalent. While Pyinstaller can create a directory with my data directories and executable inside of it, if the user ever moves the .exe file inside the directory, the app will never work (because it loses its relative location to the data directories). Is there such a thing that can package this directory like on MacOS so the user just has to click on a single .exe file that links to the .exe inside the directory packaged within it? That way we can just pass around one directory. Like a Mac.app?
Win32 apps store data within the executable file as resources, which allows the single file solution, but they can't be accessed using normal file APIs, there are a separate set of functions for resource handling. (This implies that resources aren't so useful for things that absolutely have to be files, like images of helper executables.)
Win32 also has alternate data streams, which are more similar to what you're used to with .app packages, separating a local identifier from the actual filename by $DATA:. But those only work on NTFS, get lost by many file management applications, never have been very popular, and are now effectively deprecated by Microsoft (by preventing access from Windows Store apps).
i have an executable for my cocoa application as xyz.app file. But when i copy this on windows, it is showing this as a directory with all the resource files and stuff. Is there any way to create a single file executable on mac also (like .exe file on windows) so as to disable the user from seeing the resource files and other files?
Thanks
You talking about a Bundle, which is a folder that is given an extension and the OS treats it as if it is a single file, while in reality it is a folder with resources in it. The NIB files are stored in this bundle as well as your executable and the info.plist file. This is just the way apps work in Cocoa.
The only way around it would be to write your app in a different language, but i'm not sure which, if any, will give you a single file executable.
What are you storing in your app directory that you don't want people to have access to?
There are ridiculously complicated ways to do that, sure. For example, you could gzip all your resource files and decompress them at runtime. But there's no good reason to do so — all it does is make more work for you, introduce additional complexity and make your app slow. Adobe doesn't do this, Microsoft doesn't do this, micro-ISVs don't do this — it's just not advisable.