The original ARMv7s PSA

This is the content that was initially posted at “PSA: Do not release ARMv7s code until you have tested it”. It was written before the iPhone 5 was actually available, so when the latter shipped I had to put a less… peremptory post in place of the original one, which has been moved here in the interest of historical preservation.

As usual with an impending release of iOS (or Mac OS X, for that matter), Apple is encouraging developers to submit updates to their apps that take advantage of the new features of iOS 6, so that the app can be ready when iOS 6 ships to customers; sometimes the new “features” are in fact behavior the users expect, e.g. with multitasking in iOS 4, so it’s indeed worthwhile to make this kind of update as soon as you can, though maybe not necessarily as soon as Apple tells you to do it.

Word on the street is that some people have trouble doing so, however; apparently the GM for Xcode 4.5, which Apple mandates be used for submitting apps that use iOS 6 features, has added out of the blue a new architecture variant called ARMv7s, and it’s causing link errors when building this slice for app projects using third-party libraries, as those do not have an ARMv7s slice (bit of the same issue than for ARMv6-only libraries, except more widespread apparently). To be accurate, the linker errors with the following line in the build log:

(with some libraries, the linker will instead output the following when it errors, but it’s the same general problem:)

ld: warning: ignoring file libexample.a, file was built for archive which is not the architecture being linked (armv7s): libexample.a
Undefined symbols for architecture armv7s:

This is causing a rush to source updated version of these dependencies or even hackish instructions (no link, because too risky) to modify the libraries to craft an ARMv7s slice.

To which I’m saying: have you guys completely lost your fucking mind?

There is one simple, universal and safe solution for this problem: go to your project settings (or target settings, if they are overridden at the target level), and edit the Architectures setting from armv7 armv7s to armv7, and submit that. Think about it for a nanosecond: it’s obvious for which device this architecture variant is intended, so let me ask you, are you able to test code compiled for that device yet? No. And if there is one thing you should never ever do, it’s releasing code that you have not tested (even worse if it was crafted through hackish means). Even if it’s “only” a different compilation of the same source code, you never know. Best to have that new device run “plain” ARMv7 code which you can test on existing hardware and you know this new device is supposed to run correctly, as it has to support existing apps after all.

I cannot fathom why Apple added ARMv7s in such a way that existing projects start using it right away by default, because this is just nuts (e.g. when ARMv7 was introduced with the iPhone 3GS, ARMv6 kept being the default and there was an added “optimized” setting that built for but ARMv6 and ARMv7 if you wanted it). Don’t add stupidity to that stupidity, rather than creating an ARMv7s slice (or worse, going to great lengths to do so) that, again, you can’t test, opt out of ARMv7s, don’t blindly follow the default Apple put in front of you. When you will have that bright new device in front of you and have tested that the ARMv7s slice indeed runs on it, then you can consider adding back ARMv7s (though there will likely be no big benefit, so likely no need to rush to do so).