The latest Xcode update no longer builds for the armv7s architecture by default. Is it planned obsolesce or an oversight?
The current Xcode 6 defines ${ARCHS_STANDARD} as armv7, arm64. Also whenever you update Xcode it keeps pestering you to remove your own definition of what architectures to build so that it can decide this for you. If you give in to this insisting then you find that you’ll no longer build your things for armv7s.
The armv7s instruction set is found in Apple’s A6 (iPhone 5) and A6X (iPad 4) CPUs. The following Apple A7 (found in iPhone 5S, iPad Air, iPad Mini Retina) already had moved to 64-bit architecture arm64.
When Apple added support for building armv7s to Xcode they confused quite a few developers who were using binary builds of third party libraries, like Google Analytics. In order to build an app’s architecture slice the linker requires the same architecture also to be present in all linked static libraries. Developers had to remove armv7s support from their apps while the third parties where struggling to update their binary builds to add the new architecture.
That was not a real issue, because A6 would run armv7 code just fine, albeit with a few less optimizations. Nevertheless it is a bit unsettling if suddenly your app does not build any more with Xcode outputting a linker error about a missing architecture, just because you updated your Xcode.
The fix is quite simple. As an app maker you can simply go with Xcode’s recommendation and remove your override on the Architectures build setting. If this setting is shown in bold then you can revert it to the project-wide setting with CMD+backspace.
As a component vender you should probably go a different route. You want to leave the decision to support or drop armv7s to the developer. And therefore you should add the armv7s architecture to all your static library and framework targets for it to be included.
The developer’s linker will then pick out the architecture slices it needs for the app. You can see that certain architectures are included if you build with “Build Active Architecture Only” set to now. The default for Debug builds is to have this on Yes on only build for the current device or simulator architecture. Release builds have this set to No and thus all architectures mentioned are going to be built.
In the build log for the static library target you will have one line for the library for each architecture, followed by one line combining the individual libraries into one “fat” universal library.
Another method to verifying what architecture slices are present in a file is to use the file command:
file libBarCodeKit.a libBarCodeKit.a: Mach-O universal binary with 3 architectures libBarCodeKit.a (for architecture armv7): current ar archive random library libBarCodeKit.a (for architecture arm64): current ar archive random library libBarCodeKit.a (for architecture armv7s): current ar archive random library |
This library contains the slices for all relevant mobile architectures. If you are building a static framework or universal static library for binary distribution you would even include the simulator architectures. This looks like so:
file DTRichTextEditor DTRichTextEditor: Mach-O universal binary with 5 architectures DTRichTextEditor (for architecture armv7): current ar archive random library DTRichTextEditor (for architecture armv7s): current ar archive random library DTRichTextEditor (for architecture arm64): current ar archive random library DTRichTextEditor (for architecture i386): current ar archive random library DTRichTextEditor (for architecture x86_64): current ar archive random library |
To conclude, Apple is again nudging us in a certain direction: to stop supporting armv7s. This architecture has been superseded by powerful 64-bit CPUs in two product generations by now. Yet, as a component vendor I believe that we should still include the armv7s slice to leave the choice up to the app developers.
