iOS6, Xcode4.5 vs 3rd-Party SDKs

So, Xcode4.5GM hit the streets, metaphorically speaking,  yesterday and Apple is asking developers to start submitting their new and improved iOS6 apps for  the launch of the new OS and the glorious new iPhone hardware on the 19th.  But, there’s already a little trouble in the air in the form of ARMV7s library requirements. In a nutshell almost everyone is finding their apps won’t compile if they use any closed source 3rd party API SDK static libs — why?  No one’s libraries have ARMV7s slices needed to (presumably) support the new A6 processor in the iPhone 5.

It’s not really the fault of the 3rd party SDK providers given the GM was made available around 3PM Pacific time and the previous DP release of Xcode didn’t have this requirement. but the result is that  we have a lot of frustrated developers (myself included) who find themselves in a catch-22: can’t compile for the store and can’t use a preview or older version of Xcode …

The only  kinda sorta’ clue in the release notes is that the Xcode GM no longer supports generation of ARMV6 code, but that was a given with the deprecation of anything older than the  iPhone4…

Heres a list of heavily used 3rd party SDKs known so far to have issues (and any known work-arounds):

• FlurryAnalytics version 3.1.1 [Update: 14 Sept, 9:00PM PT: Flurry reports RMV7s version is now available as version 3.1.2 of their API]
• FacebookConnect v3.0 (binary installer, if you d/l the FacebookConnect source from GitHub and compile yourself you should be ok)
• Google Analytics, curent version.  (No fix available since code.google.com only hosts the binary distribution of the library.)
• UrbanAirship 1.3.x ( The source is available on GitHub)

… More SDKs and work-arounds as we get’em.  If you have any you’d like to share, please drop us a line at i...@macindie.com

[Update: 5:30PM PT:  Matt Galloway might have an interim fix/hack to get people over the hump which involves editing the library binaries  to change the cpu sub-type to 12 which is  the ARMv7s.  I haven't tried it myself and Matt doesn't mention any explicit down-side risks/consequences to trying this, but of course proceed with caution. You have no way of knowing if on an A6 chip (clearly what it's aimed at) you're going to cause all manner of mysterious crashes on iPhone5s... ]

As Jonathan Wight (@schwa) alludes to on Twitter, the downside to not having access to the source to 3rd party libraries for code on which your app is dependent is you’ve put your business at risk — there are very few reasons why any 3rd party app API provider should be holding back on source code to an API — after all, for 99% of them the secret sause is (or should be) in the back end service, not the iOS API SDK.