macOS Can Xcode build and intel-only app?

[tuartboy]

I'm running PPC and have no access to an intel mac as of now. I know the standard is universal binaries and I thought that it was possible to build PPC only or universal, but not just for intel (using Xcode as I know you can just use GCC). Other than 1 sentence in wikipedia, google has failed me and I know somebody knows so:

Is it possible to build an app in Xcode for just x86?

 

[MGLXP]

There are applications that are Intel-only, such as Parallels Workstation and the experimental builds of VLC. So I think it is possible for Apple Xcode to compile for Intel processors only.

 

[gekko513]

Short answer: yes.

 

[Benjamindaines]

Yes, open info on the project, double click Architecture and just check the Intel box.

 

[tuartboy]

did it used to not allow it?

Now I'm wondering why I thought this?

 

[Benjamindaines]

did it used to not allow it?

Now I'm wondering why I thought this?

Ever since Xcode 2 you have been able to build Intel only apps. You probably thought that you couldn't because Apple just advertised that you can do universal binaries.

 

[tuartboy]

Ever since Xcode 2 you have been able to build Intel only apps. You probably thought that you couldn't because Apple just advertised that you can do universal binaries.

I just swear it used to be either PPC or PPC/Intel.

Either way, I stand corrected.

Thanks for the info!

 

[kainjow]

A real world example of Intel-only .apps made from Xcode: Apple's firmware updates for their Intel Macs.

 

[Kormet]

You can also strip universal apps of their x86 or PPC code. (Useful if your running low on disk space, or do not want an application running on a certain architecture)

To get rid of x86 code, type the following into the terminal:

ditto --rsrc --arch ppc Safari.app Safari_PPC.app

To get grid of PPC code, type:

ditto --rsrc --arch x86 Safari.app Safari_x86.app

 

[electronboy]

I Hope NOT!

Apple should have made compiling Universal Binaries for PowerPC mandatory until the last PowerPC ships and for at least two years after that. Anyone who only compiles for Intel, when Xcode can compile for both will not get my money--ever.

 

[caveman_uk]

Why should it be mandatory? There are perfectly good reasons why, on occasions, one would not want a PPC binary as it would be irrelevant (the Parallels VM was given as an example earlier). Developers are not stupid and if there is still a commercially worthwhile market in making a universal binary most will continue to do so.

 

[milo]

Apple should have made compiling Universal Binaries for PowerPC mandatory until the last PowerPC ships and for at least two years after that. Anyone who only compiles for Intel, when Xcode can compile for both will not get my money--ever.

It would be impossible and impractical to make it mandatory. Some apps use features that are specific to certain hardware and simply won't run on other hardware. Checking a box isn't going to magically add compatibility.

 

[Benjamindaines]

You can also strip universal apps of their x86 or PPC code. (Useful if your running low on disk space, or do not want an application running on a certain architecture)

To get rid of x86 code, type the following into the terminal:

ditto --rsrc --arch ppc Safari.app Safari_PPC.app

To get grid of PPC code, type:

ditto --rsrc --arch x86 Safari.app Safari_x86.app

I would advise against that... it can make some apps unusable.

 

[Kormet]

I would advise against that... it can make some apps unusable.

Oh yes, I believe that is a given. I cannot imagine many situations where one would want to build just a PPC or just an x86 program; but the option is there, just in case someone finds it useful.

 

[Sayer]

Developing for both PPC and Intel Macs will significantly increase development costs, as the software will need to be tested on two completely different hardware setups with two divergent OSes.

While Mac OS X is making it less-painful to develop for Intel CPUs, it is not as simple as checking a box in Xcode.

File formats that were designed with Big-endianness in mind need to be carefully handled on the Little-endianness Macs and vice versa. Network-transmitted data may need to be swapped depending on the CPU in use by the app.

Lastly any low-level (assembly) optimizations will need to be duplicated for the other platform in hardware-specific ISA.

I predict that once the Power Mac and Xserve are Intel-CPU a lot of PowerPC/Universal apps will drop off with the next major version releases from some of the bigger/more popular developers. At that point the PowerPC-based Mac will be seen merely as a legacy system only and serious thought will need to be given to the increased cost of developing, testing and supporting a dead-end platform.

If you think not, take a look at what happened to Be when the Be OS went Intel-native after being PowerPC-only in software and hardware since its creation.

 

[janey]

You can also strip universal apps of their x86 or PPC code. (Useful if your running low on disk space, or do not want an application running on a certain architecture)

Or use lipo, cause...it's right there for ya...

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/lipo.1.html

 

[dr_lha]

Developing for both PPC and Intel Macs will significantly increase development costs, as the software will need to be tested on two completely different hardware setups with two divergent OSes.

While Mac OS X is making it less-painful to develop for Intel CPUs, it is not as simple as checking a box in Xcode.

File formats that were designed with Big-endianness in mind need to be carefully handled on the Little-endianness Macs and vice versa. Network-transmitted data may need to be swapped depending on the CPU in use by the app.

Lastly any low-level (assembly) optimizations will need to be duplicated for the other platform in hardware-specific ISA.

All these issues can be avoided easily by good programming practice and using the Frameworks provided by Apple. For example, endianness of data shouldn't be an issue because you should be using CoreData/XML/something else to store your data, no writing raw bytes to a file.

Plenty of software is developed to not care about endianness (like most Open Source software, that doesn't necessarily know what kind of CPU its going to be compiled on). A little bit of extra care goes a long way towards making programs that are not only portable, but will end up being easier to maintain for the future.

 

[caveman_uk]

Developing for both PPC and Intel Macs will significantly increase development costs, as the software will need to be tested on two completely different hardware setups with two divergent OSes.

While Mac OS X is making it less-painful to develop for Intel CPUs, it is not as simple as checking a box in Xcode.

File formats that were designed with Big-endianness in mind need to be carefully handled on the Little-endianness Macs and vice versa. Network-transmitted data may need to be swapped depending on the CPU in use by the app.

Lastly any low-level (assembly) optimizations will need to be duplicated for the other platform in hardware-specific ISA.

I predict that once the Power Mac and Xserve are Intel-CPU a lot of PowerPC/Universal apps will drop off with the next major version releases from some of the bigger/more popular developers. At that point the PowerPC-based Mac will be seen merely as a legacy system only and serious thought will need to be given to the increased cost of developing, testing and supporting a dead-end platform.

If you think not, take a look at what happened to Be when the Be OS went Intel-native after being PowerPC-only in software and hardware since its creation.

Whilst you're right about increased testing costs of having a universal binary, I would suggest that once the developer has invested time in creating the universal binary in the first place the major expenditure has been made. The cost of maintaining both builds is rather lower than the initial expense.

As another reply as said you can give a lot of the lower level endianness rubbish to Apple to sort out. Currently I only have one piece of code (in-house for the time being) that has to deal with endianness issues as it decodes a binary file format created by a windows program. Apple supplies routines to swap most C types (except float as far as I can see).

I can see the real drop off coming after Apple drops PPC in Mac OS. The smaller third party developers generally write new apps for the current OS and support just the current OS and the previous version in existing apps. I expect Leopard to be the last PPC OS.