Recently I have successfully finished my first commercial Swift project. The last step was easy – create the production build. As I’m usually developing both for Android and iOS, it’s interesting to compare binary sizes for Android and iOS. Usually, Android apps are bigger. However, for my amusement this application was bigger for iOS and not only a few kilobytes, but 3.4 times bigger!
As it turned out, Swift application also contains a Swift runtime library within its bundle. According to Apple, the library is small:
Simply put, if you write a Swift app today and submit it to the App Store this Fall when iOS 8 and OS X Yosemite are released, you can trust that your app will work well into the future. In fact, you can target back to OS X Mavericks or iOS 7 with that same app. This is possible because Xcode embeds a small Swift runtime library within your app’s bundle. Because the library is embedded, your app uses a consistent version of Swift that runs on past, present, and future OS releases.
Actually it’s rather big for most application. To compare sizes, I archived empty single view applications in Swift and Objective-C.
Objective-C version: 172KB
Swift version: 8.2MB
For a game or for an application around 50 MB 8MB are really not so important. On the other hand, an utility application that would be around 2MB in Objective-C, the 10 MB size is rather too big. It’s a proven fact, that the application can loose many downloads due to its bigger size. You can reduce all your graphics to the minimum bearable quality, replace maximum images with code and minimise numbers of Xibs, but at the moment there’s nothing to do with this 8 MB overhead.
Fortunately, this is going to change soon:
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.
Until then, it would be wise to avoid Swift for size critical applications.