The response is cited a few times at Swift Blog, like the post of 1.0 release:

Because your apps today embed a version of the Swift GM runtime, they will continue to run well into the future.

But one thing, so far, I don’t see people talking about is how this embedded library affect the size of an app?

The easiest way to discover is to create an empty project and compare the size. I created two Single View Application projects using on Xcode 6.0.1. On the first image is the bundle directory of Objective-C app and on the second the Swift one.

The Objective-C only app bundle takes only 192 KB and the Swift app bundle 8.6 MB. The Swift binary is smaller but the runtime frameworks can be a huge overhead for many apps!

On the second post of Swift Blog talk about Compatibility:

As Swift changes, those frameworks will be incompatible with the rest of your app. When the binary interface stabilizes in a year or two, the Swift runtime will become part of the host OS and this limitation will no longer exist.

So for at least one year if you want to use Swift in your apps, you will have to accept this little overhead.

Update 2014/09/30: Worth to mention that the runtime libraries are embedded on every app that supports Swift, no matter the minimum deployment target.

There are three Access Control levels:

• Public access enables entities to be used within any source file from their defining module, and also in a source file from another module that imports the defining module. You typically use public access when specifying the public interface to a framework.
• Internal access enables entities to be used within any source file from their defining module, but not in any source file outside of that module. You typically use internal access when defining an app’s or a framework’s internal structure.
• Private access restricts the use of an entity to its own defining source file. Use private access to hide the implementation details of a specific piece of functionality.”

The default level is Internal access, this is fine, all your classes are visible only to your module, no imports, no external access. Although soon on later you will test your code, right?

First of all, XCTestCase are bundled on a different target and you don’t include your classes to the test bundle, right? That’s easy, just import the target that contains your class, if your target is called MyProject your test class will be like this:

1
2
3
4
5
6
7
8
9

import UIKit
import XCText
import MyProject

class MyProjectTests: XCTestCase {
    func testMyProject() {
        XCTAssert(true, "Pass")
    }
}

But this is not enough, do you remember that the default access level is Inernal? If you don’t change it in the class that will be tested the compiler will say something like: Use of unresolved identifier 'MyClass'. To void this just set your class and all the methods and properties that will be tested to public:

1
2
3
4

public class MyClass: NSObject {
    public var prop: String
    public init() {}
}

There is a discussion on Developer Forums where an Apple developer explains that this restriction is due to iOS 5 are not prepared to handle the fat binary headers that contain 64-bit code. Although static libraries aren’t handled by iOS but by the linker that came with Xcode and Xcode 5 linker obviously can handle 64-bit code!

The idea is pretty simple, build the different architectures separated then bind them using lipo. I know that is possible to do this using directly the Xcode, but I prefer to do it via command line (or Rakefile).

First build the binary with arm using xcodebuild:

1

xcodebuild -project 'StaticLibDemo.xcodeproj' -configuration 'Release' -sdk 'iphoneos7.0' clean build ARCHS='armv7 armv7s' IPHONEOS_DEPLOYMENT_TARGET='5.0' TARGET_BUILD_DIR='./build-arm' BUILT_PRODUCTS_DIR='./build-arm'

Note that you must set IPHONEOS_DEPLOYMENT_TARGET='5.0' and ARCHS='armv7 armv7s', it’s recommended to set build and product dirs to make the things more clear, take a look at Build Setting Reference for more details what this flags means.

Next build for arm64:

1

xcodebuild -project 'StaticLibDemo.xcodeproj' -configuration 'Release' -sdk 'iphoneos7.0' clean build ARCHS='arm64' IPHONEOS_DEPLOYMENT_TARGET='7.0' TARGET_BUILD_DIR='./build-arm64' BUILT_PRODUCTS_DIR='./build-arm64'

Note the difference on ARCHS and IPHONEOS_DEPLOYMENT_TARGET. We also need to build for simulator, in this case we have to change the sdk to iphonesimulator7.0 and build in two steps first for i386:

1

xcodebuild -project 'StaticLibDemo.xcodeproj' -configuration 'Release' -sdk 'iphonesimulator7.0' clean build ARCHS='i386' IPHONEOS_DEPLOYMENT_TARGET='5.0' TARGET_BUILD_DIR='./build-i386' BUILT_PRODUCTS_DIR='./build-i386'

Now the tricky part! If you just change the ARCHS to x86_86 depending on your Xcode setting you will got an error like: “x86_64 is not a valid arch”. To avoid this just add VALID_ARCHS='x86_64':

1

xcodebuild -project 'StaticLibDemo.xcodeproj' -configuration 'Release' -sdk 'iphonesimulator7.0' clean build ARCHS='x86_64' VALID_ARCHS='x86_64' IPHONEOS_DEPLOYMENT_TARGET='7.0' TARGET_BUILD_DIR='./build-x86_64' BUILT_PRODUCTS_DIR='./build-x86_64'

Finally we just have to create a fat binary with all the 5 architectures:

1

lipo -create './build-arm/libStaticLibDemo.a' './build-arm64/libStaticLibDemo.a' './build-i386/libStaticLibDemo.a' './build-x86_64/libStaticLibDemo.a' -output 'libStaticLibDemo.a'

I created a working example of this, you can get it here.