Our DNA is written in Swift

Invalid File Frameworks

It’s been a while since I last submitted a build of to the iTunes. So I figured, I should update Cocoapods to the latest version and do a pod update. The archiving went find, but then I saw a new iTunes error when I tried to upload the build.

The error came from the verification process that iTunes runs after you have endured the long wait of uploading the bundle.

Screen Shot 2016-05-14 at 20.53.42

WFT?! Apparently something must have changed, because that worked before!

On iOS, frameworks should never have any other frameworks embedded. Technically they can, but usually they would be redundant because the app that uses the framework probably has a copy embedded as well.

Indeed, when I checked the product, I found that Xcode had added duplicates of all the internal Swift libraries:

Screen Shot 2016-05-14 at 20.55.54

Well, those 13 libswift*.dylib are completely superfluous there. The problem has a very simple solution.

Xcode determines whether or not to include the Swift dynamic libraries from the Embedded Content Contains Swift Code build setting. This seems to default to Yes nowadays.

Now this setting’s name is somewhat misleading because the framework in question does contain Swift code. But I needed to set the setting to No nevertheless because the swift dylibs are completely useless for a framework.

Screen Shot 2016-05-14 at 21.18.13

This is because at runtime the dynamic libraries will be loaded by the app anyway, from within the app’s frameworks folder.


At some time between 1.5.0 in (January 2016) and today (May 2016) either the default setting changed, or iTunes added a check looking for those disallowed superfluous files in embedded frameworks.

Each such set of Swift-dylibs adds 19 Megabytes to your app bundle. So it is a good thing that Apple now brings it to your attention when you are wasting space this way.

Also published on Medium.

Categories: Recipes

1 Comment »


  1. Vale faili raamistike |

Leave a Comment