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.
Related
How can I create a single installer package for an OS X binary as well as a few configuration and script files?
Final folders should look like this:
Any help would be appreciated. Thanks.
Installers are great if you want various things to be placed in different spots – app here, documentation there, support files over here, etc. They're also great for providing configurability of the installation experience (optional extras), or hand-holding for an unusual type of installation that the user might not otherwise understand, or extra work (configuration scripts, permissions modifications, authentication, compatibility checking, etc.) that need to run during the installation process. There is nothing wrong with installers, contrary to the answer from #d00dle, although there is also nothing wrong with distributing your app through the App Store, or as a dmg.
For setting up your own installers, I highly recommend a program called Packages (http://s.sudre.free.fr/Software/Packages/about.html). I am in no way connected to it, but I use it to build the installer for an app that I work on. It greatly smoothes the process of making a complex installer, and has an excellent GUI interface.
There's also macOS Installer Builder, which is a CLI you can use to create an installer wizard for your .pkg: https://github.com/KosalaHerath/macos-installer-builder
macOS does not normally use installers. Applications are packaged in app containers with the extension .app. This container is "executable" but you're also able to dig in and see what is inside. This is also the format distributed through App Store.
You can create .pkg or .dmg "installers" if necessary, however this is clearly not something apple aims to be standard. I would advise to use the .app pattern and any scripts needed should be self contained and executed on first run.
You can use .dmg to distribute your application outside of App Store (this is still fairly normal).
macOS also includes a terminal program called productbuild that builds a product archive for the macOS Installer or the Mac App Store. Enter man productbuild into the Terminal on a Mac for the manual page.
I have standard instalations of some programs, and althou they are freeware and i can download them and install on any machine, things are not that easy always. When system crash and i dont have working machine or working internet connection or lan card or drivers for lan card i always struggle to find them and make them work if some dependency file is not on that version of windows.
What i need is to know is how can i make applications portable so i can run them from my usb or just copy them from my usb on pc and run, what dependency files application require, and what files and where specific application install?
It's a complicated story but let's try to summarize. Starts from the part "why?"
I'm an obsessive guy who seriously "hates" installers. I love to have a clean system without bloated in files reg entries and DLL's. Thats why I make nearly all (at least 97%) of programs that I use portable. I made more than 600 up to today and what I can say is;
You need:
1- A program to watch file system (what included after installation)
I use this. Simple and straight (sorry not freeware, but you can find tons of alternates)
http://www.samsunsegman.com/um/
2- A program to watch registry (what changed or included after installation)
I use this in HTML mode. Free fast and simple. And portable in nature.
http://sourceforge.net/projects/regshot/
Now scan the system with these 2, and than run the installer. After open the installed program and make your settings as you want. And than use this 2 program to find the added files and registry entries.
For files, delete them to trash can and take them back from trash in batch (easy to do like that) to the folder of application.
Registry, open the related branches in registry, delete any entries containing addressings like (plugins folder = c:\prog.... etc) After right click on main branch and select export. This is your reg settings...
3- Download this program http://ctuser.net/?reg2exe
This will convert your reg file to an exe file.
4- Download this application http://download.cnet.com/FilePacker/3000-2216_4-10414081.html
Note: Click on "Direct Download Link" if not you'll cnet will welcome you with their installer :)
And with this program (I use this because have no interference with any application) pack the program that you want to make portable. In wizard, first choose your reg-exe file after main programs file. Launcher will execute them with this order. And in setting choose "delete after terminate" will delete the extracted files on exit.
You can discover the further details. This helps you to portabilitize nearly 75% of simple applications.
5- For complicated programs or complicated needs you even can make home made loaders like
Before executing the app, put the user files under appdata folder (that I hate)
Put settings in registry (even with dynamically modified "path" addresses)
Choose which to execute (x86 or x64)
Execute in admin mode if needed
Execute the app... And when application is terminated...
Delete the settings from registry
Take the user files from appdata folder and put under programs folder (usb etc) back.
Delete left-over files under the system...
I just wrote these last ones to make you understand how far you can go. And for all these extra tricks, I use just and just bat files. And I convert them to exe also with this software. http://www.f2ko.de/programs.php?lang=en&pid=b2e (also free)
All the softwares that I use except "uninstall manager" are free. And with this technique, amazing but some of programs are running even faster.
Actually you can just use JauntePE or portable apps packer things but... Jaunte and similar sandbox making programs are so slow and not compatible with all. Even causing crashes. Portable apps approach is a bit bloated regarding to my strict spped and size standards. That's why I do it myself about for 10 years (yes even people was not talking about portability)
Note: I'm not a programmer, and you also don't need to be to do these.
I never released my portables, and you also shouldn't (read EULA's) for respect to authors.
But never forget to demand portable version from all authors. Force them to quit installers ;)
Best regards
inovasyon did a great job!
If you want to make some portable app that will work on every computer you move it to, then 99.9% of apps can be made portable.
If you also expect the app to not leave any files, folders or registry entries behind and not change or break things on the host PC's setup, then that limits things a bit further.
Apps requiring admin privileges to write to protected areas of the registry or file system will break when used on PCs with locked-down privileges.
Apps requiring services to be installed on the host PC will often leave them behind.
You must to know there are apps that are locked to specific PCs - Microsoft's recent versions of Office are a great example of this. They simply will not run when moved to another PC.
Also, you'll need some tools for making portable app: cameyo, thinapp, boxedapp, portableapps, spoon, app-v and other.
Portable applications will run from a flash drive, and from the computer.
Good Luck!
Here is a primer for setting up a portable app using the PortableApps.com tools. They have a page for developers that is quite helpful for some specifics, but the overall process is not well summarized. Here is the general outline for creating a portable application:
1. Investigate your application's footprints
Find all the files, registry locations and settings of the application you want to make portable (make use of point (1) and (2) in inovasyon's answer, and maybe take a look at Zsoft). It is usally a good idea to fire-up a virtual machine and track the application's changes without much clutter.
2. The PortableApp generator
Download, extract, and open the PortableApps.com Platform, and follow [The system tray icon] →[Apps] →[Get More Apps] →[By Category] to install the PortableApps.com Launcher, and NSIS (Unicode) needed to Portabilize your app. Alternatively, but with some added hassle, download both the PortableApps.com Launcher and NSIS Portable (Unicode version) as standalones.
You can now compile a project by running the PortableApps.com Launcher and pointing it to your project.
3. PortableApp layout and structure
Download the PortableApp.com Application Template (search for it here) to structure the data and files obtained in (1.) according to the specifications. Also, download some apps from portableapps.com for some practical examples of how they are structured, and to learn more about the struggles of portability (such as the substitution of drive letters in settings files to correspond to the movement of a portable drive).
As a "Hello World" example, try portability this simple program: helloworld.bat, with content:
#echo off
echo Hello World > log.txt
It writes all local environmental variables to the log file log.txt. You can play around a bit by trying to writing files to an %APPDATA% subdirectory and see if you can make your project redirect it to a portable directory.
4. Additional usage
If you need to do some additional coding that is not achievable with the default .ini capabilities (such as forcing only one instance of an app), add a NSIS script with file location App\AppInfo\Launcher\Custom.nsh to your project. Note that PortableApps.com's custom code guide incorrectly states the file location as Other\Source\Custom.nsh. It is also quite unhelpful regarding the layout of this script. Rather look at examples from other Apps and learn the NSIS syntax by Google-ing a bit.
I am working on a VB6 application which has many executable and an Active X dlls.
And there are to be updated in c;lient machines to lates version once in a while which i am asking the user to update manually.
Can you please suggest me a way using which i can update it automatically from the files that can be available online.
Thanks.
Windows Installer has features supporting Patching and Upgrades. Using those techniques you can create various levels of "upgrade" packages.
Your application would need a separate "update" utility that is spawned when the user approves updating, perhaps in response to a prompt your program raises after checking for new versions.
This updater would check the current version and the remote site's catalog of updates to pick the appropriate package, download it to a temporary location, start Windows Installer to process the package (or packages, sometimes you might need to run several Installer runs), and clean up the temp location. Then you might offer to restrt the updated application or on some occasions need to reboot.
This updater would be a fancy form of the common "installation bootstrapper." As you can tell it needs some "smarts" in order to tell what package or packages to download and install in what sequence, when it needs to request rebooting, etc. This would probably be based on a downloaded "rules script" it obtains as part of selecting a valid update option.
After all, sometimes you can just apply a minor upgrade or patch upgrade, sometimes you need a more complete install or entire reinstall.
If your needs are extremely simple (just an EXE and maybe a few DLLs and OCXs - preferably using reg-free COM) you may not need to go to these lengths. However when you start adding in other considerations like multiple programs, data directory creation and security settings, possibly running a settings file conversion or even database conversion, DCOM, firewall, etc. configuration, database drivers or providers, etc. things get complicated quickly. Too complicated for simple snatch and grab updating.
And admin rights/UAC issues are a factor so you'll probably have to deal with privilege elevation.
None of this is trivial stuff. There are people who do little more than construct and test such deployment systems as their entire job.
If you use soemthing like Inno setup to install the application then an update is simple a matter of running that periodically.
You can either detect there is a new version available by checking a web site/local server, or just prompt to run the update after X days.
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.
I have an old legacy application around for which I only have the installer. it doesn't do anything more than uncompress and register itself and his library's.
As i don't have the source-code it gives me a lot of headaches in maintenance problems. In some particular computers (Acer Aspire One with Windows) just do not run.
I would like to extract the files and re-create this installer with NSIS. Is this possible or I'm nuts?
The original installer has been created with Ghost Installer Studio.
One option is to find a machine that it does run on, and then install some "install guard" software (often called things like Acme Uninstaller). Use this to track what actually gets installed and then copy the relevant files and write your own.
It looks like a lot of hassle to me, and you may be on thin ice with regards to the licence.
You could try using a program that monitors new files being installed and then get the files that were installed from their respective paths.
For instance, I found this in about 10 seconds with Google, there are more programs like it, but I am inexperienced with those available for Windows.
If it uses a MSI file, you can use Orca or SuperOrca to get at the stuff packed inside.
This is typically the job of Repackaging Software. There are a few ways such tools work but typically it is by taking a look at a system before and after you install it on a clean system and building a custom installer from the detected changes. This is normally done to generate a customized installation and/or one that can be automated in its deployment. I'm not aware of one that generates an NSIS package, the standard format today is MSI (Windows Installer).
If you have the original installer any repackager will do, but even without the original setup program you can do as some of the others here suggest and monitor the use of the application for its requirements. The two most popular repackaging tools are InstallShield AdminStudio and Wise Package Studio. The feature may also be part of a setup authoring solution, so check with your in-house developers if you can.
A full list of repackaging tools can be found here at AppDeploy.com
One free repackaging tool available for creating Windows Installer setups from another [legacy] setup tool (with which I must divulge I'm involved) is the AppDeploy Repackager. Another free repackager is WinINSTALL LE.