Introduction

Xcode 5.1 caused build failures in many older Cordova projects because the toolchain became stricter about architecture compatibility. In practice, the issue was usually a mismatch between the architectures expected by the app target and the architectures actually compiled into libCordova.a. The fix is to inspect the library, align project build settings, and rebuild Cordova components for the correct targets.

Why the Error Happens

Xcode 5.1 changed default architecture behavior, especially around arm64 for device builds. Older Cordova static libraries were often compiled before that target was enabled, so the final link step failed when the application target expected an architecture the library did not contain.

A typical symptom was a linker error saying the library was missing symbols for the current architecture. That usually meant one of two things:

1. the app was building for arm64 but libCordova.a only contained older device slices
2. the simulator build expected i386 or x86_64 while the library only contained device slices

Inspect the Library First

Before changing build settings, inspect the static library that is actually being linked.

lipo -info libCordova.a
file libCordova.a

If the output does not list the architecture you are building for, the problem is confirmed. This is better than guessing in Xcode build settings.

Align App and Library Architectures

In old Cordova projects, the app target and CordovaLib target could drift apart. Both need compatible architecture settings.

The most important settings to inspect were:

• 'Architectures'
• 'Build Active Architecture Only'
• 'Valid Architectures'

For device builds in that Xcode era, a common target set was armv7 arm64. For simulator builds, i386 was often required, and later machines also needed x86_64.

An .xcconfig style configuration looked like this:

ARCHS = $(ARCHS_STANDARD)
ONLY_ACTIVE_ARCH = NO
VALID_ARCHS = armv7 arm64 i386 x86_64

The exact value depended on your Xcode version and the hardware you still supported, but the principle was constant: the app and the static library had to agree.

Rebuild CordovaLib Instead of Reusing a Stale Binary

One common mistake was treating libCordova.a as a fixed binary artifact. In many cases the cleanest fix was to remove stale build products and rebuild CordovaLib with the current toolchain.

1xcodebuild -project CordovaLib.xcodeproj \
2  -target CordovaLib \
3  -configuration Debug \
4  clean build

If the project was created by an older Cordova template, updating the Cordova iOS platform files was often necessary before rebuilding. Otherwise you could keep patching around an outdated generated project.

Device and Simulator Builds Need Different Attention

A build that succeeds on device can still fail on simulator, and the reverse is also true. That is because device archives use ARM slices, while simulator binaries in that era used Intel slices such as i386 and x86_64.

So validate both paths separately:

xcodebuild -sdk iphonesimulator
xcodebuild -sdk iphoneos

If only one path fails, inspect the library slices again and compare them to the active SDK.

When a Temporary Workaround Is Acceptable

For local development, developers sometimes set Build Active Architecture Only to YES in Debug. That reduced the number of required slices and could unblock simulator work temporarily. It was not a real fix for release builds, because archive and device distribution still required a complete set of supported architectures.

Use that setting only as a short-lived diagnostic step, not as the final solution.

Common Pitfalls

• Changing app target architecture settings without updating CordovaLib.
• Reusing an old libCordova.a binary after moving to Xcode 5.1.
• Testing only simulator or only device builds and assuming the problem is solved.
• Using Build Active Architecture Only as a permanent fix for release builds.
• Ignoring Cordova platform version updates when the generated project is too old for the newer toolchain.

Summary

• Xcode 5.1 exposed architecture mismatches that older Cordova builds often hid.
• The first step is to inspect libCordova.a with lipo -info.
• App target and CordovaLib target must agree on supported architectures.
• Rebuilding CordovaLib with the current toolchain is often the cleanest fix.
• Validate both simulator and device builds before calling the issue resolved.