7

I've upgraded to XCode 4.5 to add armv7s arch support, however, I found that you cannot generate armv6 binaries with XCode 4.5.

I already support armv6, but, wanting to support armv7s with XCode 4.5 seems to force me to contradict the clause: "You are permitted to expand your device requirements only. Submitting an update to your binary to restrict your device requirements is not permitted."

Does anyone know if we are allowed to drop armv6, or if there's a workaround?

It is probably also worth mentioning that I'm building a framework (library), not an app. So I want to support app developers.

Christian
  • 1,900
  • 14
  • 19
  • 1
    This question shows up in the first page on Google, so I thought I'd point other users to this answer: http://stackoverflow.com/a/12678077/206520 – mmilo Oct 09 '12 at 15:57

2 Answers2

2

armv6 is the CPU architecture of the original iPhone and iPhone 3G. Seeing as how both are no longer supported for two generations of iOS and more, it is safe to remove it from the supported targets. In fact, targeting armv7 should produce more optimized binaries for current devices.

Seeing as how you are developing a library, this will impose restrictions on users. You will either restrict armv6 users or armv7s users - the choice seems obvious to me, but to be safe, I would recommend branching your armv7 and up version as a new project ("v2" perhaps), so users of the old library can continue using it safely until they are able to upgrade their projects. Keep the original unsupported to incentivise faster upgrades.

Léo Natan
  • 56,823
  • 9
  • 150
  • 195
  • Why was this comment downvoted? We just did this for our product. – Léo Natan Sep 25 '12 at 00:43
  • I don't think I downvoted this. I think if we say we only support iOS 4.3 and above we can remove armv6. The build machine will get XCode 4.5 and will build armv7/armv7s/i386 only. Anyone wanting armv6 will have to use an old release and if we need to support it, we'll have to keep an XCode 4.4 around for manually patching the old library. I'd rather not have to use a new name (e.g. "v2") for the library, if I can avoid it. – Christian Sep 26 '12 at 13:45
  • You can decide not to support it, and give the old, unsupported lib the "legacy" name. – Léo Natan Sep 26 '12 at 14:57
0

After re-reading your question, I am confused as to why you are having any sort of problem. You are building a framework, so this restriction does not apply to you:

  • Users who previously used your framework, the version that supported Armv6, won't be able to update their apps anyways unless they drop Armv6.

  • Since new app developers will be forced to use XCode 4.5, they will all be dropping Armv6 anyways. If they want to use your framework with new apps they won't be able to support Armv6 anyways.

So it seems to me, as a framework developer, that this guideline does not apply to you at all.

Edit - Also... Facebook app has been updated to only support iOS 4.3, dropping support for Armv6 devices. http://itunes.apple.com/us/app/facebook/id284882215?mt=8

Nitzan Wilnai
  • 923
  • 9
  • 24
  • I think you need some supporting evidence to show that you can restrict device requirements. What you are saying seems to contradict the following link: https://developer.apple.com/library/ios/#documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/B_DeviceCompatibilityMatrix/DeviceCompatibilityMatrix.html – Christian Sep 26 '12 at 13:41
  • I guess technically, existing users of the library could be users of the enterprise developer program and thus can still develop and distribute armv6 binaries. The chances of that are small though, and you can always just give them a binary built with XCode 4.4. The other thing, and I haven't tried this yet, is to build an armv6 binary with XCode 4.4's compiler and use `lipo` to splice it into the binary built with the iOS6 SDK. I suspect Apple might reject such a triple-arch binary though. – pmdj Sep 26 '12 at 17:26