
Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1 - adomanico
http://www.openradar.me/31302382
======
DannyBee
This appears to be bitcode. It probably means they just starting making use of
more metadata or something that is now included in the bitcode.

Bitcode also now deliberately trades off size vs speed and includes indexes
used for LTO, etc. They could be including those.

You should almost always expect bitcode to get beat by "llvm-dis|xz", because
the goal of bitcode is not to be the most compact possible format, but
instead, a compact format the compiler can use effectively :)

Now, if actual on-device binary sizes increased, my guesses would be:

1\. it now includes bitcode, or another architecture, in the binary (which
would be interesting)

2\. Something has gone horribly horribly wrong :P Really, speaking as a guy
whose org maintains the toolchains for platforms like this, there's a 0%
chance we wouldn't notice a 2x-3x size increase.

~~~
alimbada
The iOS Gmail app has increased in size to 140MB at the last update. I'm on a
16GB iPhone and I've noticed app sizes slowly increasing over the last two and
a half years that I've had my phone. I have to keep an eye on app size to make
sure I don't run out of space on my phone. I've already boycotted the Facebook
app, but apps like Gmail are too important to uninstall. If it comes to it
I'll be getting rid of a lot of other apps before Gmail (e.g. the Google app)
when I need to reclaim space. I don't understand how app sizes keep creeping
up; it's moronic. By contrast, the Reddit app is a slim 13MB and I'd say it
does a lot more than the Gmail app.

~~~
JustSomeNobody
Features mostly. I mean, you seem to absolutely need the Gmail app. While I,
too, have a Gmail account, I like the simplicity of the native mail app in
iOS. I don't need any additional features. I get mail, I read mail, I can
write mail.

~~~
tripzilch
you can't fill 140MB with "features mostly".

it's gotta be something like mostly media (uncompressed bitmaps), metadata,
(debug symbols maybe?), libraries / platform / compatibility layers (95% of
which is never used for any particular install).

I have seen what it looks like when you _actually_ try to cram "features
mostly" into a few tens of megabytes and the GMail app is not that.

source: the demoscene

~~~
kalleboo
I just downloaded the IPA. It literally looks like it has a 134 MB blob of
code (out of a 215 MB universal .app).

Google must have some _insane_ cross-platform code library or something in
there.

------
bdash
Note that the size increase is in the _bitcode_ portion of the binary. This
slice is stripped from the binary before it makes it to the user's device.
This means the size increase is merely an inconvenience during the development
process, and has no impact on the size of apps as users see them.

~~~
adomanico
Unfortunately this doesn't seem to be the case.

Binary sizes in iTunes connect (from our Xcode 8.3 build) all were 2x-3x
larger depending on device.

~~~
bdash
I think the size iTune Connect reports includes bitcode, and isn't
representative of the size of the app once it makes it to a user's device. The
information in the original bug report you linked to clearly shows the size
increase is limited to the bitcode portion of the binary.

~~~
Exuma
Why would they do that, visually in the store?

~~~
bdash
I'm not sure what you're asking here. Why would who do what?

~~~
Exuma
Why would they show the full size including bitcode when you go to download
it, when it doesn't get sent to the device anyway.

~~~
bdash
The size I'm referring to is shown in iTunes Connect, which is the
administrative side of the App Store that the developer uses to manage their
app releases. As far as I'm aware the size shown in the App Store's user-
facing UI does reflect the size that will be downloaded by the device. I think
it's possible to see this size in iTunes Connect, but since I don't myself
have any apps in the App Store I can't easily verify this.

~~~
jhammer
You can see the per-device estimated App Store file sizes in iTunes Connect:

(navigate to your app) > Activity > All Builds > (select the version) >
(select the build) > App Store File Sizes

~~~
DopamineHigh
ty

------
nstj
Really need to change the title to reflect that the increase in size is not
present in App Store binary.

Side note: filing a Radar is the new top of the customer acquisition funnel.
Go Realm! :)

------
mwexler
So, the app explodes in size, and since almost no app provides a "clear
cache/temp" feature, apps grow til you are crashing routinely. While iOS may
clear some space when it feels like it, I have a monthly routine of deleting
and reinstalling a slew of apps which take up gigs of space on the device
after usage, even though they are just showing data stored on a server. I
know, I shouldn't have to worry about this, that iOS will eventually clean it
up... but when apps are crashing b/c they can't get space, I wind up having to
manually step in.

So, a) for devs, if you think your app caches, provide a way to clear it (look
at Opera's Coast browser, who puts it in the Settings app), and b) for users,
if you think you are out of space, look at apps and compare app size to total
space, and you'll find some hogs.

~~~
ar15saveslives
iOS cleans up Caches/tmp directory, it it needs space.

[https://developer.apple.com/library/content/documentation/Fi...](https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1)

> "Note that the system may delete the Caches/ directory to free up disk
> space, so your app must be able to re-create or download these files as
> needed."

> tmp: "however, the system may purge this directory when your app is not
> running."

~~~
vinayan3
Despite this claim. It doesn't feel like it happens. Maybe, apps aren't
writing the Cache files to the right place and that's why they aren't being
cleaned up.

------
apple-fan-941
This is due to bitcode, which won't actually affect the binary size seen by
end users (i.e. app download size):
[https://twitter.com/jckarter/status/846796503775567872](https://twitter.com/jckarter/status/846796503775567872)
"That at least shouldn't affect your users' download size, then."

~~~
lordnaikon
Is this only true for store downloads? Because the majority of our apps is
delivered simply by a website download through the device via Enterprise
certificates.

~~~
bdash
If you're doing direct downloads then there's no reason to be building with
bitcode enabled, and so the size increase should not affect you at all.

------
aaronfuqua
Isn't 10.3 the first version that is introducing the new APFS file system? If
so, couldn't that have something to do with it? Does each app need to compile
for both supported file systems now? I am not a LLVM expert but someone with
more expertise on this subject might be able to say. I just found it odd that
no one else here had mentioned it. It is the big update for 10.3

~~~
djrogers
Apps aren't compiled for a specific file system, so no.

------
LeoNatan25
This has been fixed with Xcode 8.3.1.

------
CppCoder
Did anyone actually look at the content which is responsible for the increase
in size? I hope it does not include the source itself, comments, and who knows
what.

------
dep_b
It also seems to take 3x longer while the previous version was no speed demon
either. Guess why I have so much time to post here?

------
perlpimp
wonder what would
[https://github.com/google/bloaty](https://github.com/google/bloaty) say about
those binaries...

------
sebow
Remind me of Visual Studio

------
sneak
Apple charges $1200 to upgrade the latest touch bar rMBP from 512GB to 2TB of
flash.

Let's not forget that they are a hardware vendor.

I don't think it's some grand conspiracy theory, but the interests of the
vendor and of the user are not precisely aligned when it comes to efficient
usage of storage. (The lack of stripping applications of their alternate
language content on install/download also comes to mind.)

~~~
qzervaas
This theory is pretty easily debunked when you consider the primary goal of
bitcode is to strip assets from apps that aren't relevant to a user's device,
hence taking up less space.

(For example, removing @2x images for a plus device that uses @3x images, or
vice-versa).

~~~
sneak
I said explicitly in my comment that I don't think this is some grand
conspiracy. I don't think Xcode makes big files to use up disk space. I think
Apple just has little incentive across the entire ecosystem to use less
storage or use storage more efficiently.

Afaik bitcode is so that Apple can rebuild binaries for different target
architectures (e.g. new models of phone, watch, et c) without source developer
interaction. It should come in major handy in the OSX app store when ARM64
Macbooks ship in a year or two. A full app store of working apps on hardware
launch day will make the bitcode requirement worth it when it's the smoothest
architecture transition they've ever done (out of 680x0->ppc and ppc->x86).

~~~
LeoNatan25
Bitcode does not allow cross-architectural builds. This is a common
misconception. IR (& bitcode) includes architecture and platform-specific ABI.
What it does allow is for better optimizations as the LLVM backend optimizer
improves.

~~~
jevinskie
I would imagine that with enough engineering effort, a cross-architecture
"porting" of IR would be feasible. I doubt Apple will bother to do that when
they can just force developers to rebuild and republish lest they get left out
of the App Store.

~~~
LeoNatan25
Outside of a Java-style high-level VM, cross-platform cross-architecture in
the C world requires compilation. You cannot use what is not there. When
compiling a C language, macros are used to determine architecture and
platform, and extra code is simply not compiled. The most simplest of examples
is endianness handling, which would be totally broken if Intel-compiled code
is automagically made to run on arm.

~~~
astrange
iOS and macOS are both little-endian, but there are many other differences
between platforms (like pointer alignment, SIMD size, ObjC ABI) and bitcode
makes no effort at all to accommodate them.

Bitcode can used to recompile for minor ARM updates, compiler bugs, new
optimizations etc without having to get developers to submit new binaries.

------
alien3d
The same codebase compiled with Xcode 8.3 produces a binary about three times
larger at 158MB, including 70MB for bitcode alone.

Apple limit 100 mb per download.. So this big issue for all developer.We need
apple to remove the limitation over 100 mb or atleast 1GB.

~~~
HappyTypist
Bitcode size =/= binary size. Your binary sizes will remain similar.

~~~
alien3d
if so okay, but still i do confuse with the limitation of 100mb.Sometimes
facebook apps can update more then 100 mb and some apps cannot update over 100
mb.

~~~
0x0
That's probably because the app store may offer a delta update patch instead
of a full download.

~~~
alien3d
i prefer to knew more about it.. but seem here down vote making me sad those
coward downvoter.. maybe i will close this account..

~~~
Nexxxeh
I didn't downvote you, but I can help you understand why you were downvoted.

On HN, you'll usually get an answer if you ask a question.

"Is x going to be a problem for y?"

Making an incorrect statement however will get you downvoted.

"x will be a problem for y."

The other issue is your writing quality. You will get better results if you
put more effort into your writing.

You don't have to have perfect English. Many people on HN have English as a
second language.

Things like a capital letters at the start of a sentence, and using single
full stops (periods) at the end of sentences, show effort. You will find
people will be more tolerant of grammar issues if you at least put effort into
the basics.

