Introduction

This question is mostly historical, and the first important answer is that iOS 5-era app targets usually did not need armv6 anymore. By that point, real App Store support had largely moved to armv7, so trying to build both armv6 and armv7 with an iOS 5 deployment target often mixes two different goals: targeting iOS 5 and supporting much older hardware.

Understand the Architecture Split

Older iPhone and iPod touch devices used armv6. Newer devices, including the iPhone 3GS generation and later, used armv7. If your minimum deployment target is truly iOS 5, armv7 is usually the relevant architecture.

That means the practical question is often not “how do I build both,” but “do I actually need armv6 at all.”

If Your Minimum Target Is iOS 5

For an iOS 5 target, the normal answer is to build for armv7 and stop there. In the older Xcode build system, that meant setting the architecture list to the standard device architectures for that period rather than forcing obsolete slices manually.

An old-style xcconfig example would look like this:

1ARCHS = armv7
2ONLY_ACTIVE_ARCH = NO
3SDKROOT = iphoneos
4IPHONEOS_DEPLOYMENT_TARGET = 5.0

That configuration matches the historical reality of the platform far better than trying to keep armv6 alive unnecessarily.

If You Truly Need armv6

If you really must support armv6, your project is a legacy-support project, not a normal iOS 5 project. That means:

• the deployment target likely needs to be older than iOS 5
• the Xcode version must still support armv6
• every static library or dependency must include an armv6 slice

An old multi-architecture configuration looked like this:

1ARCHS = armv6 armv7
2ONLY_ACTIVE_ARCH = NO
3SDKROOT = iphoneos
4IPHONEOS_DEPLOYMENT_TARGET = 4.3

Whether that actually works depends on the toolchain and dependencies. Adding armv6 to ARCHS does not help if the SDK or third-party libraries no longer support it.

Check Dependencies Before Blaming Xcode

A common failure mode in old projects is that the application target is configured for both architectures, but one dependency was built only for armv7. In that case, linking fails or the final app is incomplete.

Historically, lipo -info was the quick way to inspect slices in a static library.

lipo -info libSomething.a

If the output does not include both armv6 and armv7, that library cannot participate in a true dual-architecture build.

Fat Binaries and Tradeoffs

Supporting both architectures meant shipping a fat binary with multiple slices. That improved compatibility but increased bundle size and testing burden.

For a genuinely old codebase, that might have been necessary. For an iOS 5 app in the mainstream device ecosystem, it was usually unnecessary overhead.

The Real Decision Path

A better way to decide is:

1. identify the oldest device you must support
2. check which CPU architecture that device uses
3. choose a deployment target that matches that device baseline
4. verify that your Xcode version and dependencies support the required slices

If the oldest supported device is already armv7, do not complicate the project with armv6.

Common Pitfalls

The most common mistake is assuming “build with the iOS 5 SDK” automatically means “support armv6 devices.” Those are different requirements.

Another mistake is forcing armv6 into build settings without checking whether the toolchain and linked libraries still support it.

Developers also often forget that old architecture support increases test complexity. Even if the binary builds, it still has to run on the target hardware.

Summary

• For true iOS 5 targets, armv7 was usually the practical architecture.
• 'armv6 support mostly belongs to older legacy-device support scenarios.'
• Building both slices requires the deployment target, Xcode version, and dependencies to align.
• Check library slices with tools such as lipo -info.
• Decide from actual device support requirements, not from architecture names alone.