macOS Installers for Cocoa Applications

[vnraju]

hi.....can anyone help.......how we can create installers for our cocoa apps.......
any suggetions will be appreciated......
thanx in advance.......

 

[MongoTheGeek]

hi.....can anyone help.......how we can create installers for our cocoa apps.......
any suggetions will be appreciated......
thanx in advance.......

Most cocoa apps shouldn't need installers. Just create a disk image for the users to drag and drop. Installers always make me edgy.

If you really want to build an installer take a look at PackageMaker. It is in the developer tools, under utilities.

 

[valiar]

hi.....can anyone help.......how we can create installers for our cocoa apps.......
any suggetions will be appreciated......
thanx in advance.......

Best (and properly written) Cocoa apps should *not* need an installer.
Avoid using one if you can at all...

 

[MongoTheGeek]

Best (and properly written) Cocoa apps should *not* need an installer.
Avoid using one if you can at all...

Only reason I can think that you would want one is to install a shared framework that is used by a bunch(5+) applications, or fonts perhaps.

 

[Krevnik]

Only reason I can think that you would want one is to install a shared framework that is used by a bunch(5+) applications, or fonts perhaps.

In which case, this is still a bad idea, IMO.

Shared frameworks that aren't externally maintained are a recipie for trouble if you try to install them yourself. This is why most devs will just ship a copy of a library with each product to know that Product A can use v1 of the framework, and Product B can use v2, and won't accidentally cause problems with Product A.

 

[MongoTheGeek]

In which case, this is still a bad idea, IMO.

Shared frameworks that aren't externally maintained are a recipie for trouble if you try to install them yourself. This is why most devs will just ship a copy of a library with each product to know that Product A can use v1 of the framework, and Product B can use v2, and won't accidentally cause problems with Product A.

I was thinking of a company like PlayFirst with a number of different games built on the same engine, or the old infocom games.

Yes, every game would ship with the engine, but the installer would check to see if the version of the engine installed is at least X.

Its less important now-adays because the media attached to the games outbulks the games themselves.

 

[Krevnik]

I was thinking of a company like PlayFirst with a number of different games built on the same engine, or the old infocom games.

Yes, every game would ship with the engine, but the installer would check to see if the version of the engine installed is at least X.

Its less important now-adays because the media attached to the games outbulks the games themselves.

Wasn't even important in the Infocom games where the app itself was the interpreter with a resource in the resource fork for the interpreted game data.

And since you can store frameworks in the app bundle, installers should be avoided, even if you have libraries.

 

[kainjow]

Shared frameworks that aren't externally maintained are a recipie for trouble if you try to install them yourself. This is why most devs will just ship a copy of a library with each product to know that Product A can use v1 of the framework, and Product B can use v2, and won't accidentally cause problems with Product A.

This is what Apple does with iWork. Keynote, Numbers, and Pages all have the same frameworks within their app bundles.