macOS Deploying 32 bit or 64 bit or Universal Binaries?

[kamy]

Hey guys

We have a C++ / Objective C based app.
We use LLVM-GVC compiler to compile our code.

Currently we build 32-bit binaries and deploy them on our customer's machines.
We support SnowLeopard, Lion, Mountain Lion and Mavericks.
I'm aware that all these are 64 bit OS. They can run 32 bit binaries fine.

But i want to know, going forward , is it a better idea to deploy 64bit binaries of my app?
I can compile our code base and build 64 bit binaries, but i will have to link against 3rd party 64bit libraries etc.
I think its do-able.

My question is what are the advantages of deploying 64 bit binaries, provided that 32binaries still work on these OS's?

Also what bout Universal Binary? Do you guys think building a Universal Binary would be a better option? If yes, why?

I'd appreciate any thoughts/suggestions.

 

[gnasher729]

Hey guys

We have a C++ / Objective C based app.
We use LLVM-GVC compiler to compile our code.

Currently we build 32-bit binaries and deploy them on our customer's machines.
We support SnowLeopard, Lion, Mountain Lion and Mavericks.
I'm aware that all these are 64 bit OS. They can run 32 bit binaries fine.

But i want to know, going forward , is it a better idea to deploy 64bit binaries of my app?
I can compile our code base and build 64 bit binaries, but i will have to link against 3rd party 64bit libraries etc.
I think its do-able.

My question is what are the advantages of deploying 64 bit binaries, provided that 32binaries still work on these OS's?

Also what bout Universal Binary? Do you guys think building a Universal Binary would be a better option? If yes, why?

I'd appreciate any thoughts/suggestions.

Snow Leopard is the last OS version that runs on 32 bits. And you might assume that Snow Leopard users _do_ have 32 bit machines, or they would have upgraded. So either drop Snow Leopard, or keep it and keep supporting 32 bit. Snow Leopard + 64 bit isn't that useful.

Advantages: You don't stand out as being the only 32 bit app around. And the OS saves quite a bit of RAM if _all_ apps are the same bitness - and today that means all apps 64 bit (or universal). It runs faster at no cost to you.

If you switch to 64-bit only, Objective-C code can take advantage of the modern runtime and ARC, which will save you a lot of development time in the future. (ARC on 10.6 doesn't support nulling weak pointers, so you'll have to live without that until you drop 10.6. But you lived without that before, so it's not urgent).

 

[robvas]

Apple hasn't made a 32-bit only Mac in a long time. What do you gain by supporting them in the future?

 

[Madd the Sane]

x86-64 has more registers than i386; 64-bit apps can address more RAM; 64-bit apps use more RAM due to larger pointers.

Going forward, I'd recommend you use Clang: Apple has more or less dedicated themselves to use it for development. Also, the Objective-C runtime on x86-64 is more recent. Also, ARC is really handy, but isn't available on OS X i386.

 

[kamy]

Snow Leopard is the last OS version that runs on 32 bits. And you might assume that Snow Leopard users _do_ have 32 bit machines, or they would have upgraded. So either drop Snow Leopard, or keep it and keep supporting 32 bit. Snow Leopard + 64 bit isn't that useful.

Advantages: You don't stand out as being the only 32 bit app around. And the OS saves quite a bit of RAM if _all_ apps are the same bitness - and today that means all apps 64 bit (or universal). It runs faster at no cost to you.

If you switch to 64-bit only, Objective-C code can take advantage of the modern runtime and ARC, which will save you a lot of development time in the future. (ARC on 10.6 doesn't support nulling weak pointers, so you'll have to live without that until you drop 10.6. But you lived without that before, so it's not urgent).

Hmm, so if i package and distribute 64 bit binaries i will not have a problem
with users running Mountain Lion, Maverics, Lion and Snow Leopard (64 bit systems).
But i will have an issue with users running Snow Leopard (32 bit systems).

Is that assumption correct?

----------

x86-64 has more registers than i386; 64-bit apps can address more RAM; 64-bit apps use more RAM due to larger pointers.

Going forward, I'd recommend you use Clang: Apple has more or less dedicated themselves to use it for development. Also, the Objective-C runtime on x86-64 is more recent. Also, ARC is really handy, but isn't available on OS X i386.

Thanx. I agree we are working on it to use CLang to compile our code.
LLVM-GCC wont be around for long.

 

[gnasher729]

Hmm, so if i package and distribute 64 bit binaries i will not have a problem
with users running Mountain Lion, Maverics, Lion and Snow Leopard (64 bit systems).
But i will have an issue with users running Snow Leopard (32 bit systems).

Is that assumption correct?

Exactly right. It's your decision how many customers you will lose (considering that these are people who are using the same Mac for six years, they might not be into spending money on new software), and how much money and development time you will save by being able to use the modern Objective-C runtime, ARC and so on. Or how much you can improve the software because you get more done in the same development time, benefitting your paying customers.

 

[Madd the Sane]

You can distribute a universal binary of your app that has both 32- and 64-bit versions.

 

[gnasher729]

You can distribute a universal binary of your app that has both 32- and 64-bit versions.

You can. It means you should test both versions, but mostly it means that you can't use modern Objective-C features because they are not present in 32 bit. That's why you have to consider the cost and advantages of dropping 32 bit support.