Rev 2.7.4 standalone versions
Stgoldberg at aol.com
Stgoldberg at aol.com
Sun Oct 1 16:10:57 EDT 2006
Regarding which of the standalone versions to include in distributing one's
built applications, please correct me if my logic is wrong here:
a. I assume that very few Mac users have operating systems that are earlier
than OS X, so one does not have to be so concerned about distributing for OS 9
(or Classic).
b. Many people, though, may have OSX versions less than 3.9, so distributing
an application in Universal Binary would not help these users, if Universal
Binary requires OS X.3.9 or higher. One would then have to also include
PowerPC-only (for all versions of OSX) and Intel-only (for optimal performance on
Intel) versions to reach most users.
c. Perhaps the ideal way of distributing might be a combination of
PowerPC-only and Intel-only versions. That should cover all PowerPC versions as
well as Intel. It would not be necessary to include the Universal Binary
version.
Does this logic make sense?
Steve Goldberg
In a message dated 10/1/06 2:45:37 PM,
use-revolution-request at lists.runrev.com writes:
> > If the Universal version will work both on Intel Mac
> > computers as well as non-Intel Mac OS X computers, what would be
> > the advantage
> > of including the "Power PC only" or "Intel only" versions when
> > distributing
> > one's application, since the Universal version would seem to work
> > on both kinds
> > of computers?
>
> One reason might be filesize. Universal apps are twice as big. The
> other is, running universal apps requires Os X.3.9 or higher, so if
> you want to support X.2 or smaller you need a power PC only compile.
> I am happy to have all options, as "Universal Binary" is the buzzword
> du jour when releasing new Mac apps at the moment. Many people over
> here think, if it is no universal binary, it is not a good app.
> Therefore Intel only is out of the game for me for a while, but might
> be reasonable if I want to release an app. that is very resource
> hungry and requires a modern computer to work reliably.
>
>
More information about the use-livecode
mailing list