6

How can I build a native Mac OS X installer for my application, on a non-Mac platform?

For example, I have a windows pc and a Java application. I want the windows pc to build an installer (possibly inside a .dmg archive) that works with Apple installer.

michelemarcon
  • 23,277
  • 17
  • 52
  • 68
  • 1
    You *do* know that Mac users can simply double-click on a .jar file to run it, right? :-) – Sherm Pendley Nov 14 '08 at 22:39
  • 1
    See my answer in this question: http://stackoverflow.com/questions/2323818/packagemaker-for-creating-mac-packages-on-windows-linux/8016507, which is a duplicate of this one. – jcoffland Nov 04 '11 at 22:43

7 Answers7

4

It is now possible to create a native Mac OS X installer on a non-Mac platform. As Louis Gerbarg, the tricky bit is the BOM (bill-of-materials) file. However an open source version of mkbom (based on the osxbom code by Joseph Coffland) is now available at:

http://hogliux.github.io/bomutils

The website also has an easy to follow step-by-step tutorial on creating a Mac OS X installer on Linux ( http://hogliux.github.io/bomutils/tutorial.html ).

My company regularly build Mac OS X installers on linux with this method and so far we haven't had any major problems.

hogliux
  • 231
  • 1
  • 4
  • 18
  • Initial tests of this method and the tutorial is working brilliantly! Hat off to you @hogliux. I'm in a situation where a Mac installer makes sense because I need to add files to an already installed application, not just install my own. I also run automated CI builds and provisioning a whole Mac server just for building one tiny installer is way overkill. – Staffan E Jun 05 '14 at 09:35
2

As others have already pointed out, you are really taking the hard solution to this problem, and your users will curse your name for it, unless you have a really good reason to do so. It is true, that certain types of applications will require installers for Mac OSX. These generally include:

  • Applications which install custom drivers (ie, kernel extensions)
  • Applications which need to install frameworks or other resources which for some reason could not be packaged within the application bundle
  • Applications which need to run as a system service and therefore must run some post-install scripts to launch the app during bootup
  • Poorly written programs which require making some type of changes to the user's system (ie, setting permissions on a folder or something), and the developer's hands are tied by marketing department weenies to distribute the application in the most painful way possible

Ok, so that last point is a bit sarcastic, but do you get my drift here? :) Basically, if you are writing a normal, end-user application, you should distribute it in the normal way that Mac users would expect, which is a DMG file containing your application's bundle. Or if you want to be really fancy, stick an alias to the "Applications" folder inside of the DMG to help the user drag the program in there. Unless you are writing something which must install itself into the system, rather than simply be run by the system, there's no reason to use an installer here. Also, keep in mind that this is OSX, which already contains a fully-functioning Java JRE, so you don't need to worry about packaging the JRE in an installer or anything like that.

Now that you've been properly scolded for asking this question, I'll answer it with the assumption that your software falls in one of the categories above. Really, your best bet would be to go with a commercial solution such as VISE installer (which, again, I can state confidently that a vast majority of Mac users will recoil in terror when installing a product made with this tool), which allows you to do exactly what you are looking for here -- basically, to make a cross-platform installer which builds for the various platforms you want to support from a single installer file.

Again, though, your best bet here is to do what users of that platform are most comfortable with (which is why all the responses to your question urge you not to make an installer). That means, however, if you really must make an installer, you should use a non-cross-platform framework; windows users will feel most at home when presented with a standard MSI installer, and Mac users will feel most at home with an Apple Installer pkg. The PackageMaker program is notoriously limited, though, so if you must, you should use iceberg instead. This will mean a bit more maintainance for you, since you'll need to tend after two (or more) separate installers, but if your software is really so complex as to demand this, you should be willing to make the sacrifice for the comfort of your users.

Nik Reiman
  • 39,067
  • 29
  • 104
  • 160
2

It is difficult to create a .dmg on Windows, but it is certainly possible to create a .app file structure that you can then zip, as others commented have mentioned. There are times when a regular .pkg will not cut it and you want to provide dialogs, pre-Installation checks, etc. You can do that with BitRock installbuilder, you can build installers for mac, Linux, Windows, Solaris from each of the other platforms.

Daniel Lopez
  • 3,297
  • 2
  • 30
  • 29
1

So, a couple of quick questions.

First, why do you want an installer? Most Mac users prefer apps that are just drag installed. If you are not writing Mac OS X specific code it is hard to imagine you need to place bits in special places, like Application Support or LaunchDaemons. Assuming everything you have just goes in one folder why bother with an installer at all?

Second, why would it be a problem to build the Mac installer on a Mac? Surely you have a macintosh around to test the app (you are not just blindly shipping it for Mac without testing it on a Mac, right?).

Okay, having said that, assuming you still have a good reason to actually build this on a PC, there are some bits that are not going to be easy. Basically a .pkg is a bunch of text scripts, localizations, an archive file (Archive.pax.gz), and a bill of materials (Archive.bom).

Assuming not much changes between builds, you can make the installer on a Mac, and then just rebuild the bom and the pax.gz, replace them into the existing .pkg, and batch a few pieces of metadata. The pax should be easy enough to deal with (pax is a standard archive format), but the bom file may prove a bit trickier, since I do not believe it is publicly documented, and I doubt the tools for creating them (mkbom) are part of darwin (not opensource). So you are going to need to figure that out and write a custom tool to create the bom file.

In other words, this is likely to be a large amount of work.

Kounavi
  • 1,090
  • 1
  • 12
  • 24
Louis Gerbarg
  • 43,356
  • 8
  • 80
  • 90
  • 21
    I really hate it when people respond with "Why would you want to do that?" It's such a waste of everyone's time. – jcoffland Nov 04 '11 at 22:41
  • 2
    Instead of trying to devaluate a valid question, try solving it instead of discouraging anyone to find an answer for it. – Timothy Groote Jun 05 '12 at 14:23
  • 2
    I disagree, there is a lot to be learned from these kind of "devil's advocate" answers. As long as the answer is insightful into the kind of problem being solved it is perfectly valid. Often when asking a question we do not know what alternatives are available to us. – Mike Aug 23 '13 at 00:50
0

The usual way to install a app on a Mac is to drag the app to the application folder. Most programs come as a DMG containing the app and a symbolic link to the application folder. Why would you want it any other way? You need to think Mac to build a great Mac application! Look and feel is very important, especially for Mac users.

Svante Svenson
  • 12,315
  • 4
  • 41
  • 45
0

Check out this code for reading BOM files: https://cauldrondevelopment.com/svn/osxbom/trunk

jcoffland
  • 5,238
  • 38
  • 43
-1

Put everything into one JAR file, add it to a ZIP. Done.

But seriously, you're wanting to distribute your application to Macintosh users without testing it first? What planet are you on!?

saschabeaumont
  • 22,080
  • 4
  • 63
  • 85
  • 2
    Why do you assume he is not testing the package? You can have a Linux build server which creates the packages. Nothing is stopping you from testing on OSX later or having your OSX testing team do it for you. – jcoffland Jul 29 '13 at 22:19