Hacker News new | comments | show | ask | jobs | submit login

Swift is a big part of the app binary size bloat. It creates about 3-4x the amount of binary for about the same lines of code count as objective-c. Generic specialization happens everywhere in swift and using optionals takes a lot more ASM instructions than you would think it does. Swift also adds about 5-20MB of standard libraries for each app that uses it. Extensions like maps or watch apps also take a few MB each.

Also apple makes decisions like encrypting binaries and then compressing, removing a lot of over the air space savings. They don't give free apps the option to just sign their apps and not encrypt them for smaller IPA sizes.

I wouldn't be surprised if a similar decision was made in the xcode toolchain that caused a similar issue.




It's not Swift. App sizes are mostly increased by graphic assets, and libraries. Here is a 15,000 line swift app that compiles to 11 megs.

https://blog.halide.cam/one-weird-trick-to-lose-size-c0a4013...

I'm skeptical Swift creates significantly larger binaries, let alone 3x-4x, but I'd still use it if so. Using optionals and stronger typing is makes it easier to write correct code, and anyway we can save users from wild pointer crashes is super valuable. Far more valuable than the cost of a couple megabytes of code in an ocean of PNGs and Cocoapods.


I recall reading at one point that apps written in Swift statically bundle the entire set of libraries, whereas Objective C apps use shared libraries from the operating system. Something about Swift not having yet reached the level of maturity to warrant the use of stable shared libs. If and when Swift switches to supporting shared libs, app sizes should shrink.


Actually, use of large value types in Swift can cause significant binary bloat.

https://news.ycombinator.com/item?id=14207752


That same app written in 17kloc of objective c code would be significantly smaller. The reason why it's small is because it just doesn't have a lot of code. Most these fat apps have already done all the other easy crap specified in the article. The author knows that all the other apps are at least 500kloc of code minimum, he worked at twitter.

All other things being equal, a swift app is much larger. The article also is just talking about binary sizes, not about all the other graphical assets.


Yeah, Swift should only contribute a small, constant amount to account for the runtime and standard library. 3-4x doesn't make sense.


Go decompile using an optional or an array, or interfacing with an Obj-C lib, you'll be surprised how much ASM is generated.

You'll also be surprised how much stuff is reduced in swift 4. Swift is still in beta, lots of low hanging fruit to improve still.


> Also apple makes decisions like encrypting binaries and then compressing, removing a lot of over the air space savings.

Is compression not the first step of basically every encryption algorithm ever?


Not for apple fairplay DRM. :/ It's pretty obvious, you'll see how much the binary compresses to when you build on your machine vs what you download from the store and compare the sizes.


Oh, well that sucks. :/ I haven't done any iOS dev yet, I guess Android doesn't have the monopoly on stupid though.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: