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.
Related
I am packing my macOS application into an application bundle. I need to codesign it and pass notarisation. It is possible to put the frameworks in the "Resources" directory?
I have two frameworks. Normally, I used to put such frameworks into the "Frameworks" directory of the bundle. However, for (stupid) designing reason I need to have some more libraries in the same directory of my frameworks. Since such libraries will prevent code signing if placed in the directory "Frameworks", I want to move frameworks + extra libraries into the "Resources" directory.
Reading Apple documentation it seems that frameworks should - of course - belong to the "Frameworks" directory, however I could not find any reference to what should NOT be included into the "Resources" directory. Is this bad practice? Would my .app structure not pass gatekeeper?
Any suggestion would be very much appreciated
You've probably already tried putting a frameworks in Resources by now. As you said, even if it works today, this is not a good idea.
You might be able to work around whatever issue caused you to want to do this by using the install_name_tool to change one of the paths built into your frameworks. Adding symbolic links are another handy device for issues like this. This kind of stuff can be done automatically in a Run Script Build Phase or a Build Phase Post Action.
I need to create symlinks in frameworks inside an app on OSX (vers 10.10.1). I am outside of XCode as the app is developed in Qt. It provides the frameworks, but they need some retouches to work on the new codesigning rules.
I call "ln -s path_origin path_target_link" and apparently it works, the links are created and they resolve to the right place.
But when I codesign the app, I get an error "unsealed contents present in the root directory of an embedded framework"
(In order to verify my procedure, I copied a framework from another package downloaded that validates codesigning and I could sign it successfully, when I create a symlink my way codesign starts to give the error so I'm assuming the problem is my symlink creation)
I tried other methods with the same result so I must be missing something. Any ideas?
For the case it's useful to anyone. In my case the problem was that I was creating the links with absoulte paths. Obviously they should be relative: You move to the directory where the link should go and create the link relative to the current location.
Version 1 code sign recorded only files in the Resources directory and ignored the rest. But version 2 records substantially all files by default. So we have to sign each and every frameworks bundle's versions and app binaries.
Ensure your framework bundle structure is meet the requirement of apple.
According to Apple's documentation, framework bundles don't have a 'Contents' folder. Instead, each version folder gets a 'Resources' folder which contains the Info.plist file, and which is also symbolic linked at the top-level framework folder. Qt5 frameworks have incorrect layout after SDK build, so this isn't just a problem with macdeployqt, but whole framework assembly part.
so confirm, there is no faulty layout in your app bundle.
If you have a *.prl in your Qt framework bundle (i.e.QtCore.framework/QtCore.prl). *.prl file may cause trouble for you as codesign just bails out with "unsealed content presents in the root directory of an embedded framework" without telling exactly what's going on. Strip if you have any prl files.
It is necessary for the Info.plist to have the correct CFBundleExecutable field. At the moment it doesn't. The debug version of Info.plist would overwrite the release version, and it also happens to contain invalid data. In particular, CFBundleExecutable would contain the _debug suffixed library name, which it shouldn't. If you have this problem then modify the incorrect info.plist.
The last step is you have to codesign all the frameworks before you sign the entire app bundle.
For anyone confused about this issue, you can refer to Apple's documentation https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle
It contains all the details for macOS/iOS/MacCatalyst/watchOS/tvOS...
I have a set of applications that work together. It should be possible to start each of these applications individually by the user (i.e. one application provides a monitoring feature, another a configuration feature etc), therefore I would like them to show up in the Applications folder as different applications (possibly within a directory).
The applications are based on Qt5, so I would like to package Qt along with the applications privately to ensure that Qt is present and available. On the other hand I would like to make sure that I only include a single copy of Qt to avoid bloating the system.
I am using a package installer, due to the inclusion of a LaunchDaemon as well.
How do I place the Qt frameworks needed in order to avoid having multiple copies?
Here's the naive way:
/Applications/
MyCompany/
Foo.app/
Contents/
Info.plist (must use its own plist to specify some properties)
MacOS/
foo
Frameworks/
Qt-Goes-Here??
Bar.app/
Contents/
Info.plist
MacOS/
bar
Frameworks/
Qt-Goes-Here?? - Or can this be a link to the other location?
Since I am not a Mac-guru, any input (including informing me that I am trying something stupid) is very welcome!
There are two possibilities here, the first is
/Library
and the second
/Library/Application Support
If you look there, you'll find folders with contents for various applications. You should be able to create a folder there and add the Qt Framework, then update your applications to point to that using install_name_tool
The docs state the following for /Library: -
The Library directory is the top-level directory for storing private
app-related data and preferences. There are several Library
directories scattered throughout the system but you should always use
the one located inside the current home directory. Do not store files
directly at the top-level of the Library directory. Instead, store
them in one of the specific subdirectories described in this table. In
OS X v10.7 and later, the Finder hides the Library directory in the
user’s home folder by default. Therefore, you should never store files
in this directory that you want the user to access. To get the path to
this directory use the NSLibraryDirectory search path key with the
NSUserDomainMask domain.
For /Library/Application Support: -
The Application Support directory is where your app stores any type of
file that supports the app but is not required for the app to run,
such as document templates or configuration files. The files should be
app-specific but should never store user data. This directory is
located inside the Library directory. Never store files at the top
level of this directory: Always put them in a subdirectory named for
your app or company. If the resources apply to all users on the
system, such as document templates, place them in /Library/Application
Support. To get the path to this directory use the
NSApplicationSupportDirectory search path key with the
NSLocalDomainMask domain. If the resources are user-specific, such as
workspace configuration files, place them in the current user’s
~/Library/Application Support directory. To get the path to this
directory use the NSApplicationSupportDirectory search path key with
the NSUserDomainMask domain.
The full documentation can be found here.
I involved with the development of an application that is intended to deploy on multiple desktop system including the Macintosh.
Our team decided we would like to a drag and drop installation for the Macintosh. However, the application is intended to ship with other content besides the application itself such as example files.
Originally these files were placed in the application bundle, however this was discovered to be problematic as the cross platform libraries used for the user interface will not allow someone to access the contents in the bundle. Also force users to have to dive into a bundle to find content does not offer a great user experience.
To that end, we decided to pull these examples file and what not out of the bundle and place them in a separated folder that lived along side the application bundle. To make sure everything including the examples and the application were copied together during the drag and drop installation, a new top level folder was created that contained everything to be copied.
The problem that now exists is that whereby when originally just the application bundle was copied over to the system, the copying of this top level folder does not cause file associations for the application to occur automatically.
What can be done to associate an application with certain files when someone installs by dragging a folder contain the application bundle?
I suggest you to deliver it separately in one dmg. So your dmg structure will look like next:
MyApp -> Applications
MyApp Examples -> Application Support
Simple, user-friendly, no problems with association.
Actually it looks like the file association is working after all. Someone reported a defect against the installation not making the associations. However, I just tested the installation on a clean system and copying over the folder does seem to make the associations.
Is it possible to have two executables each with its own plist to share the same bundle. Then depends on the way app is executed (parameters) to load the appropriate executable.
Imagine the case where we have a main application (executable with UI) and the mini application (shorter version of the main app also with its own UI) and then depend on the parameters user used for starting the application execute the appropriate executable in the same bundle.
Cheers
Not exactly, but you could achieve something similar.
You could have a master Application bundle, which figures out which version of the code to run, and then have multiple plug-in bundles (as resources of the application) which actually implement the different versions. Each plug-in bundle would have its own Info.plist / nib files / etc.
See the documentation for NSBundle for details of how to load bundles and run their code.
I think I understand you. You want to share a plist between two executables. Just refer to the same plist in each case: tutorial for single executable plist.
Don't know if it's possible. Honestly I doubt it because the plist information is also used to define the icon and so on, so you would confuse the Finder if this would be possible (which icon should it display?). However, I am not an expert in Bundles, at all.
I give you a workaround. Create a demultiplexing script that runs the proper executable according to your parameters, and then associate the script with the plist information.