I'm coming at this from the Windows world... On Windows, we have Windows Installer packages (MSI files) that are processed by a system component (Windows Installer) to install applications (the idea being that this system component tracks references to libraries and implements transactional installation, theoretically avoiding botched installations)...
Could someone explain the architecture and process of how an application gets installed on OSX? Is there a corresponding component to Windows Installer? And if so, how would I go about using it for my applications?
This might be overkill, but check this out:
Software Delivery Guide: Introduction (Apple)
Discusses various software delivery procedures on the Mac and how it all works.
Applications are normally packaged into "bundles" with the .app extension. These bundles contain the binary (usually Mach-O) and any other resources the application needs to run; these usually include:
Resources for the application - such items as icons/images, NIB files (used to define the user interface)
Property list files defining such parameters as application name, bundle format etc
Localized files and strings which can be loaded by OS X for different locales set by the user
These bundles are normally kept in the /Applications/ folder, although they can be moved around and placed anywhere on the filesystem (the bundle format makes moving these applications around easier).
The common method to install an application is to download an Apple Disk Image file (extension .dmg) which is mounted as a disk drive on the user's OS; the application is then actually installed in two main ways:
Through the Installer app; this uses an Installation Package (extension .pkg) which provides a "Wizard" installation procedure, and is used when the installation is configurable (where the user can choose which extra dependencies to install etc). The free Apple tool PackageMaker can be used to create these packages.
By simply dragging the application icon into the Applications folder; this is for applications that do not require custom installation settings; normally a window displaying the application's icon and an icon for the Applications folder is shown, and the user drags the application's icon onto the Applications folder icon (for an example, see here)
you drag the icon into your Applications folder.
It is really a folder with a name ending in .app . The OS treats that as a single unit. Inside of the "folder" is the application distribution and metadata to tell the OS how to run it. Normally, systemwide components are installed on first-run.
You sometimes find package (.pkg) bundles that work exactly the same was as a .msi.
OS X apps are usually "xcopy deployed" and are self contained in so called bundles.
Related
How to know where are files coped in Mac OS X filesystem?
And which files?
UPD: I ask this questions because I found some files from the applications in other directories, not just in /Applications (i.e. ~/Library). So are these files created after I run the application ? (not in copying ?) Lots of people told that copying application is like installation in Mac OS X, so I think application can put some files, preferences in other directories when it's "installing".
The application folder on Mac OS X is /Applications.
Applications in OS X (files that end in .app) are actually directories. Everything in the .app directory gets copied to to /Applications. When you put an app in your app folder, you're just copying a directory that ends in .app to the /Applications directory.
You can do ls -l /Applications/Preview.app on the command line to confirm this.
Applications on the Macintosh are permitted to write to some specific directories for their own purposes. Most of these directories are in the Library, either the system library
/Library/...
or the user’s library
/Users/...username.../Library/....
which is conventionally written ~/Library/...
Inside these folders, you might find Preferences (where applications store their preference settings), Application Support (where applications store things like templates and customizable resources), Logs (where applications might write a crash log if things go wrong), Caches (for storing information like web pages), and Services (for things that are launched from the Services menu).
In general, applications shouldn't install LARGE things in these folders without asking. So there’s not much reason to worry about the files that applications install here.
It appears that apps can use the following to copy those files even before the app has ran:
Applications can contain a helper application as a full application bundle,
stored inside the main application bundle in the Contents/Library/LoginItems directory.
Set either the LSUIElement or LSBackgroundOnly key in the Info.plist file of the helper
application’s bundle.
See more here: https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLoginItems.html
You can see this functionality by copying the latest version of Docker for Mac OS X to the Applications folder but not running it.
when deploying software on Windows, it is relatively easy to update files in a program folder by running a setup program (e.g. generated with NSIS) with admin rights. Is there an analogous way on Mac? Is it possible to exchange files in an installed app bundle and how is it done?
Thanks!
If it's an app distributed via the App Store or signed (or both), you can not replace files within an application bundle without breaking it (where it won't launch on subsequent attempts).
You didn't provide enough information in your question to explain what you are trying to do. Is this for an application you are writing or is this for applications with site licenses or apps you don't control at all?
If this is for an application you are writing, Apple recommends installing resources in ~/Library/Application Support/ or ~/Library/Cache/ or other directories, and then -- in most cases -- you'd have to create some mechanism within your app to fetch and save updated resources. There may be some stuff that the MacOS provides, like NSCache.
Our .app download includes a tool (another, smaller, app) with it that we'd like to allow users to run from the "Applications" folder, but we don't want them to have to download more than one file.
Is there a way to include one .app inside another that will result in the OS automatically adding both of them to the Applications folder when the user drags and drops it in there from the dmg file we distribute? Or would we have to use a package that extracts two separate applications?
Thanks for your help.
I don't think that apps bundled inside other apps (i.e. helper apps) would show up in Mac OS X's (Lion) Launch Pad. Much less from the Finder for end-users.
Apple distributes Xcode through the Mac App Store and it has many apps : Xcode, Intruments, Quartz Composer, etc. Perhaps downloading an installer from the Store (as is done with Xcode) would be an option for you.
I realize it's an extra step for the user but I don't see how you can bundle multiple distinct apps in the App Store.
Aside from that, perhaps offer each software as a seperate download. Or revisite if the apps actually do need to be their own islands. Good luck!
I know on windows there are a bunch of installer tools you can use to create an installer, but on Mac OS I've seen two ways to install apps:
A DMG file which you download, double-click, then run an application inside - the application typically has you drag an icon to another icon (representing the Applications folder) to install the app
Another type of file which launches an apparently standard installer, which sometimes brings up a warning like "This installer may run a program to determine if you can go ahead with the install"
What's the "standard" way of packaging an app for install on Mac OS? Is one of the above the Apple-recommended way?
Thanks.
Apple is very clearly making the "standard" to be downloading a program from the App Store. This has the benefit of making application installation transparent to the normal user. And, believe it or not, normal people have a lot of trouble with the concept of installing a program. Of course that benefit comes with some costs, but this isn't the place for that debate–there are plenty of other places for that.
Assuming you don't want to or can't go the App Store route, both PKG and DMG are common ways to distribute a program. Use a PKG if you need to install files aside from your application bundle (which should not be a common use case). In all other cases use a DMG that prompts the user to copy the application into the Applications folder. But a lot of your users will not understand that they need to do that (unless your target audience is solely knowledgeable computer users). They will run your application from the disk image. Ideally in this case, your program will detect that it is running from a disk image and offer to copy itself into the Applications folder.
Packages works well. If your deployment process must be kept simple, it is great.
The Quick build consists of dragging your .app onto Package and it is done.
For advanced packaging, you can also provide a certificate.
http://s.sudre.free.fr/Software/Packages/about.html
We're discussing two things:
first and most importantly, the standard method by which the bits of an executable get laid on the disk in a way that's accessible and properly registered by the system
second, the mechanism for preparing the .app, as recommended by Apple
An older marketing page on Apple's site says it's recommended to create packages (so the Installer application can move the bits in place) with the PackageMaker application.
Its usage is described here: mactech.com/articles/mactech/Vol.25/25.03/2503MacEnterprise-PackagingforSystemAdministrators/index.html.
But as others have mentioned, the elephant in the room is the MacAppStore(MAS for short). Until it's debut, what was standard for large companies was their own custom scripts rolled into an older-style 'bundle' package or using an executable like the VISE installer. Smaller developers usually tried to make their app installable via drag-drop, distributed in zip archives or disk images(for simplicity's sake).
The MAS is different: as of 10.7 it uses a package format (which debuted in 10.5) referred to as a flat package (really a xar archive, explanation here)
which is transferred over http to a hidden folder, installs directly to Applications(after which the temporary folder it is downloaded to is deleted). It drops its receipt and a bill or materials file into /private/var/db, and is therefore audit-able by the built-in command line pkgutil tool, described here: mactech.com/articles/mactech/Vol.25/25.12/2512MacEnterprise-PackagesReceiptsandSnow/index.html
A benefit of using the flat package format is you can pull things over the network more safely and efficiently, but it isn't as easy to work with as bundle packages if you are testing and modifying the package regularly, or iterating to ensure scripts that perform actions or checks work well. Even when flat, putting the pkg in a archive or disk image is recommended for flexibility. More distribution tools expect DMG's than zip's, so there's that as well.
Besides what Apple recommends and what is standard, common practice, there's this article: https://www.afp548.com/2010/06/03/the-commandments-of-packaging-in-os-x/ which discusses the why's and hows (although mainly for system administrators) of packaging for wider distribution. It is greatly recommended to get more of a feel of how and why things go wrong, and what to avoid.
Try Iceberg!
Another one package creator.
In OS X, many applications are just created as a Relocatable
application bundles that the user just need to copy to the
/Application folder (or any other location). In other cases, when you
need to perform some operations over the machine (such as adding users
or changing permissions) you can use a PKG installer (for example built using PackageMaker), which allows
executing some pre and post install scripts and support some basic
installation configuration, like selecting the installation drive.
Sometimes, as with complex server software, you need more flexibility, for example to show custom pages to
the end user requesting information required to install your
application, like the MySQL port and password or proxy information to
download requirements on the fly (or simply to make it look fancier
:)). For this cases there are other installer solutions like our BitRock
InstallBuilder (disclaimer, I'm one of the developers).
InstallBuilder also has the advantage of generating multiplatform
installers using the same project with very little customization per
platform.
To provide application updates in Windows, we can simply download the installer and run it. Applications are installed in %PROGRAMFILES% and shortcuts are placed in various places. Keys and values are added to the registry to provide an entry in the system's Programs list.
To provide application updates in Linux, we can use the system's package manager.
How do you provide application updates in Mac OS X? I think in general you simply drag .app bundles to /Applications? Does the system provide any sort of registry other than "look in /Applications folder"? Should the general flow of updating simply involve downloading an opening a DMG file, prompting the user to drag the new application bundle into /Applications? Will copying an app bundle to a folder delete the existing bundle before copying, or does it act like a normal folder (e.g. add and replace existing files)? I'd just like some general information on how I know go about implementing a 'check for updates' feature consistent with what's expected for a Mac OS X application.
It sounds like you should look into Sparkle.
In my experience as a Mac user (not a Cocoa dev), it's become the de facto standard for self-updating apps, save for a few monoliths like Microsoft Office and Adobe CS.