I'm searching for how to create a "Welcome... Walkthrough.. " to show after a person has installed a program, like the thing dropbox shows after you finished installing. I can't find any info on how it can be done. What langugage is used? Does anyone know of any tutorials on this or what to search for?
Whatever I search for I simple keep getting installation guides of all sorts.
Somthing like this:
Installing programs for OSX is usually done in one of 3 ways: -
1) Copying an app bundle to the applications folder
2) Running the OSX installer by double-clicking a pkg or mkpg file
3) Installing from the OSX App store.
When you download dropbox it provides you with just an app bundle and if you look inside you'll see there are only two binaries; dropbox and python.
Therefore, the installation welcome / walkthrough appears to be nothing more than part of the dropbox binary and not an actual separate installer.
You can create the same in any language you're comfortable with, by creating the various GUI windows that you want to display to the user in your application, having checked that it's the first time that the user has run your program.
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'm trying to use "wine" on MAC osX Sierra version 10.12, wine is version 1.9.19
In the terminal I can launch Windows applications, however its a pain to have to keep typing in:
/Applications/Wine\ Staging.app/Contents/MacOS/wine ~/.wine/drive_c/Program\ Files/HeidiSQL/heidisql.exe
I've searched around for a post on how to create shortcuts/applications to add to the launchpad, but so far none of the information has led me to a working end result. Either the locations of wine is different or it just doesn't work.
I've tried creating an application script:
do shell script "/Applications/Wine Staging.app/Contents/MacOS/wine ~/.wine/drive_c/Program Files/HeidiSQL/heidisql.exe"
But this won't run either.
For anyone having the same problem, in the end I created scripts which reside in my home folder:
Launch vi, create a file called HeidiSQL, insert:
wine ~/.wine/drive_c/Program\ Files/HeidiSQL/heidisql.exe
Save and exit file, grant file execute permissions:
chmod +x HeidiSQL
Launch wine terminal and type in ./HeidiSQL to launch, I then did the same for PSPad.exe:
wine ~/.wine/drive_c/Program\ Files\ \(x86\)/PSPad\ editor/PSPad.exe
I know this thread is a little old but I was just looking for something like this to launch HeidiSQL and I came up with these three solutions which I have tried and all of them work. I am putting my findings down here for it may help someone:
Wineskin (http://wineskin.urgesoftware.com), Playonmac (https://www.playonmac.com/en) and Winebottler
(http://winebottler.kronenberg.org)
Wineskin is a mac app that download and install (and manages, updates, etc) "wine" for you. It then creates a HeidiSQL.app (any name you want with any icon you want - but you need to configure it) around the windows.exe that includes the wine version selected and is completely self contained (does not need wine installed separately). Personally this is the neatest solution and my preferred even though there its a little more technical than Playonmac and similar to Winebottler. You need to read the instructions (which are very good) and you have choices to make as to the wine version to use and to configure the app. Noteworthy is that you need to change the windows version to XP rather than 7 or some buttons won't work.
Playonmac on the other hand is very user friendly. It has HeidiSQL listed on its website as compatible and its almost a single click install. You just select HeidiSQL from the list of programs and it will download everything you need for you. The only reason I prefer Wineskin is that it does not create a true self contained HeidiSQL.app. You can create a shortcut for it in your Applications folder but this will launch Playonmac and the app needs to be installed inside Playonmac. On the plus side, Playonmac will chose all the right settings for you to run the app correctly, the correct windows and wine version etc which is something you need to fiddle with with with Wineskin.
Winebottler again makes an app like Wineskin. The only real difference I could see is that with Wineskin the configuration app is actually part of the package whereas in Winebottler you have to recreate the package each time you make a change. I stuck with Wineskin. YMMV.
I have a product that I would like to distribute on the Mac App Store. For context, this is a Qt (5.3) app written in C++ on OSX 10.9 with Xcode 5.1.1. I have two questions:
1) When I use productbuild like such:
productbuild --component /path/to/my/Program.app /Applications Product-Installer.pkg
I get the Product-Installer.pkg as expected (this took some effort since the man pages made no mention that the bundle has to be signed before this will work) but when I run the installer, I do not see my app in /Applications. Even though the installer says it installed successfully, I am unable to find any evidence that Program.app was installed anywhere on my system. I am wondering if there is something I'm missing, similar to how not signing the bundle caused productbuild to give me a "The component [component] is not a bundle error?
2) My program has configuration files and I'm not sure what the best way is to handle these on install. For example, in the Windows-world, I would just install a config.ini file (for example) into the user's data folder during install. However, the way the docs read regarding Mac Store Apps, my take is that that's really not done...? I'm wondering then if the best way to handle this is to just generate the config.ini upon the first run of the app? How is this typically handled with App Store apps?
Thank you!
2) you would install them in the Application Support directory in your sandbox container.
Typically the configuration is called User Defaults and implemented with CFPreferences in plain old C or NSUserDefaults with Objective C. You would ship your UserDefaults.plist inside your package/bundle and register it on each launch of the app with registerDefaults:.
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.
As a service to my users I would like to provide an uninstall script to completely remove all traces of my application on Mac OS X. The application is installed using a package rather than just being dragged into the Applications folder because it is a daemon-type app that also requires to run a script at installation to be launched.
My thinking is to include a file called uninstall.sh and place it into /Library/Application Support/com.<mycompany>.<myapplication>/ and refer to this from the application documentation. The purpose is basically to stop the daemon if running, unload and delete the corresponding plist as well as remove any application files. Does this sound reasonable or are there better methods to accomplish this?
Also I am wondering if it is good practice to also remove traces of the package using pkgutil --forget - if I don't do this, the next time the package is installed it shows up as being upgraded instead of installed. Any recommendations or pointers to best-practice information?
Is there no standard way of doing this on OS X?
There is no standard way of doing this on OS X. Yes, shocking, I know. Apple consistently warns everyone away from package installers (among other things by providing insufficient documentation for them). They then exclusively use package installers for their own standalone apps.... go figure.
Yes, you should include pkgutil --forget.
If your customers are comfortable with this kind of script, then your approach sounds fine. If they want a "double-click-on-it" then you should probably put the uninstaller in /Applications, but avoid that if you can.
If you have a GUI, Status Item, or Preference Panel, then it's nice to put a "Uninstall" button or menu item there rather than requiring them to go mess around with Terminal.
BTW, if you go looking for the Software Delivery Guide, it's been moved for a year or so now, while they "update" it.
the inability to remove packages has bugged me for years, so i've written a tool to uninstall packages:
http://www.corecode.at/uninstallpkg/index.html
its a bit better than the shell scripts to do it floating around because it makes sure never to remove any files that are used by any other installed packages
The way I solved this was to use Automator, create an application document and then add dialog and script actions. Finally save your Automator application document and you end up with a simple GUI application to run the uninstall.
Often the uninstall action requires administrator privileges - I solved this in Automator by running a shell script action that generates another shell script that can then by run in an applescript action as follows:
on run {input, parameters}
do shell script "/tmp/uninstaller.sh" with administrator privileges
return input
end run
I have a similar application and came across the same issue. The approach I took was one that I have seen other applications use. Rather than simply distributing the .pkg installer, wrap it up in a .dmg file. The uninstall script can be included with the .pkg in the .dmg.
The uninstall script is then renamed to "uninstall.tool". The .tool extension allows users to run the script by double clicking, rather than having to run it from the command line.
Slightly unconventional, but aren't these all. I have Homebrew and cask installed. I was able to uninstall a .pkg with the following:
brew cask uninstall --force <pkg_name>
ex. brew cask uninstall --force dockertools