PDA

View Full Version : Why is my app still not 32-bit compatible.




ArtOfWarfare
Apr 5, 2012, 09:30 PM
Backstory
When I started my project, I had it set to use ARC because that was the greatest thing in the world.

Then I released my app and I got an email asking why the app didn't work on their computer. After a few back and forth emails and some googling, I came up with the answer:

Because I was using ARC, my app was not 32-bit compatible. Their computer had an Intel Core Duo, which meant it wasn't 64-bit compatible, thus my app didn't run on their computer.

Verify the issue
I found this terminal command to check if an app is 32 bit compatible or not...
cd to the app bundle, then into its contents, then into MacOS. Then use

file <the name of whatever is at this directory... should be the executable file>

For apps that work on both 32 bit and 64 bit machines, it returns something like this:

iCal: Mach-O universal binary with 2 architectures
iCal (for architecture x86_64): Mach-O 64-bit executable x86_64
iCal (for architecture i386): Mach-O executable i386

For apps that don't work on 32 bit machines, like mine, it returns something like this:

Battery Status: Mach-O 64-bit executable x86_64

What I tried
So, I went into Xcode and changed both my target and project setting "Architectures" to "Standard (32/64-bit Intel)".

And... nope, it's still not 32 bit compatible.

"Valid Architectures" for both my project and target are "i386 x86_64", so I don't think that's an issue either.

So... any suggestions for what I need to check that I haven't already?



firewood
Apr 5, 2012, 10:35 PM
Remove x86_64 from valid targets?

chown33
Apr 6, 2012, 12:30 AM
Because I was using ARC, my app was not 32-bit compatible.

Does your app still use ARC? Because if it does, you can't make it 32-bit compatible (http://stackoverflow.com/questions/7919227/arc-error-fobjc-arc-is-not-supported-with-fragile-abi).

If your app doesn't use ARC, then maybe one of the project settings that initially blocked the compilation of a 32-bit version is still active, and still blocking the 32-bit version from being compiled. I don't know what that might be, and I don't know if we'd be able to guess what it is. You might want to start with the compiler options for ARC (see Section 2 here (http://clang.llvm.org/docs/AutomaticReferenceCounting.html)).

It can be painful, but one sure way to build non-ARC for 32-bit is to create a new project that's non-ARC, put all your source files and settings in that project, then build that project. Obviously, your source files must be non-ARC; either retain/release or garbage-collected.

gnasher729
Apr 6, 2012, 08:37 AM
I have one MacBook with a 32 bit processor. Built May 2006. I don't expect newer software to run on it.

People will complain, and then you just have to say: Tough. If Apple stops supporting it with Lion, why would you support it?

If you want to please people, you should please the huge majority. You get hundred times more mileage out of every hour of work invested by improving your software for the majority, and not by trying to please one guy who hasn't bought a new Mac for six years.

As a rule, the louder they complain, the less willing they are to pay you money. If someone complains that your software doesn't run on a 32 bit computer, then your answer should be "absolutely, it doesn't run on a 32 bit computer".

ArtOfWarfare
Apr 19, 2012, 11:47 AM
I've already taken $3 from them.

What kind of person would I be to say "Thanks for paying! Sorry the app doesn't work! Now F Off!"

No, Apple still offers some support for their computers because they made the Mac App Store work on their computers. Thus I need to make sure my app works for them.

Now, I still have the issue. I've started a new project in Xcode 4, it doesn't have ARC, and yet when I archive it and check it in Terminal, I still get just:
Battery Status: Mach-O 64-bit executable x86_64

So... how do I make it also list i386?

Edit: Okay. I finally got this to work. Here are the things I had to do to make an app in Xcode 4 that runs on any computer that also runs the Mac App Store:

1 - DON'T USE ARC! When setting up the project, do not check off automatic reference counting.
2 - Set to 10.6.6 In your target summary, set the Deployment Target to 10.6.6. (First version the MAS is on.)
3 - Architectures - Standard (32/64-bit Intel) This should be the setting in your Target's Build Settings.

Also... I was getting an odd error regarding the code from the template that synthesizes the window... my personal solution was just deleting that line, given my app is a menu-bar app.

Terminal finally prints this:
Battery Status: Mach-O universal binary with 2 architectures
Battery Status (for architecture x86_64): Mach-O 64-bit executable x86_64
Battery Status (for architecture i386): Mach-O executable i386

gnasher729
Apr 20, 2012, 02:44 AM
I've already taken $3 from them.

What kind of person would I be to say "Thanks for paying! Sorry the app doesn't work! Now F Off!"

Anyone who values their sanity. They paid $3. In my book, that doesn't entitle them to more than three minutes of my attention, and that is being generous. Seriously. You might consider saying "Now go away" instead. :D

ArtOfWarfare
Apr 20, 2012, 08:47 AM
Anyone who values their sanity. They paid $3. In my book, that doesn't entitle them to more than three minutes of my attention, and that is being generous. Seriously. You might consider saying "Now go away" instead. :D

I like to value my time similar to that. I also pride myself on customer service. Where one customer has issues and thought to email me, who knows how many others are out there severely annoyed but don't realize the contact button is there?

gnasher729
Apr 20, 2012, 10:27 AM
I like to value my time similar to that. I also pride myself on customer service. Where one customer has issues and thought to email me, who knows how many others are out there severely annoyed but don't realize the contact button is there?

Well, it does say "OS X 10.6.8 or later, 64-bit processor" in the App Store, and the "64-bit processor" text is a link to an Apple website that shows users how to check what processor they have. Anybody with a five year old computer should know that they have to watch out when they buy. And since App Store apps can be run on multiple computers without extra payment, it is quite possible that this customer _is_ actually using the app as intended. That's what would happen if I bought it; it would run on my newer MacBook, but not on the older one.

Mac_Max
Apr 20, 2012, 04:39 PM
Just to throw my 2 cents in there. I think if you weigh the cost/benefit ratio, where learning and gaining customer confidence/loyalty is a tangible benefit, I think AOW made a good choice. It's not like he had to start over from scratch for Mac OS 10.4 & PPC support.

Are you maintaining two separate projects or are you ifdefing your releases? I.e. http://www.learn-cocos2d.com/2011/11/everything-know-about-arc/#experts-detect-ARC

ArtOfWarfare
Apr 22, 2012, 01:40 PM
Just to throw my 2 cents in there. I think if you weigh the cost/benefit ratio, where learning and gaining customer confidence/loyalty is a tangible benefit, I think AOW made a good choice. It's not like he had to start over from scratch for Mac OS 10.4 & PPC support.

Are you maintaining two separate projects or are you ifdefing your releases? I.e. http://www.learn-cocos2d.com/2011/11/everything-know-about-arc/#experts-detect-ARC

Just one project designed to run on all Intel machines... No ifdefs.

Although I am starting over. My original code was mess and difficult to maintain (it had started life as a "proof of concept" and then became a full app, oops.) User interface was copied and pasted but everything behind the scenes is brand new (and hopefully much easier to maintain.)

Mac_Max
Apr 23, 2012, 06:42 PM
Just one project designed to run on all Intel machines... No ifdefs.

Although I am starting over. My original code was mess and difficult to maintain (it had started life as a "proof of concept" and then became a full app, oops.) User interface was copied and pasted but everything behind the scenes is brand new (and hopefully much easier to maintain.)

Haha, believe me, I've had that happen at work more often than I'd like to admit to. I learned to stop showing off my proof of concepts :D.