Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.framework binary size #123

Open
vytis opened this issue Sep 16, 2016 · 5 comments
Open

.framework binary size #123

vytis opened this issue Sep 16, 2016 · 5 comments

Comments

@vytis
Copy link

vytis commented Sep 16, 2016

I was looking through Frameworks folder in our app bundle and noticed that Decodable is one of the largest binaries. We use CocoaPods and data here is from an AdHoc build. Just to list a few other Swift-only frameworks:

Build framework Size
Alamofire.framework 2,5M
Decodable.framework 1,9M
Moya.framework 732K
JSONCodable.framework 612K

I am not too familiar with Swift build process to guess the reasons, but being 3x the size of another JSON mapping lib is a bit surprising.

@Anviking
Copy link
Owner

Anviking commented Sep 16, 2016

I've thought about this before, but not been too sure of what size would be acceptable. Decodable does code generation for a lot of nested generic types, which is very likely the reason.

The depth is currently set to 4. Reducing it to 2 shrinks the binary size from 1.7 MB to 0.4 MB for me.

I'm not good at CocoaPods but I think it would be possible to add a build setting for this or something. Will look into it.

In the long term, code generation won't likely be needed when Swift supports conditional protocol conformance.

@vytis
Copy link
Author

vytis commented Sep 16, 2016

Not sure if it's possible to have code generated on the fly with CocoaPods. The only thing that comes to mind is maybe have overloads for depth 2 in the main repo and move the rest to a subspec. On the other hand that might be a bad idea if people use them a lot.

@NachoSoto
Copy link
Contributor

@vytis given that those are debug builds it doesn't make much sense to compare sizes, since they includes debug information as well as multiple architectures (those are fat binaries). I'd recommend looking at the actual size from an App Store downloaded IPA.

@vytis
Copy link
Author

vytis commented Sep 20, 2016

@NachoSoto the app in question is not yet public, we are only doing external testing with TestFlight. However I am not aware of an easy way to download .ipa from App Store or TestFlight. Pre iOS9 you could extract the .ipa from device with certain tools, but they don't work anymore.

What would be the best way to compare resulting binary sizes for several frameworks?

@codeOfRobin
Copy link
Contributor

@vytis if you use Fastlane, you'll most likely find the .ipa in your source directory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants