[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.

[entropy_]

The apple store binary format is really horrible when it comes to keeping the size down. Especially if you need to use libraries and whatnot. What it comes down to is this:

1 - The binary format itself isn't very efficient. Compressing it usually yields at least a 50% reduction in final size, often more

2 - Even though .ipa is a zipped format, there's no actual compression on the binary itself because it's encrypted before compression. I have no idea why they do this, I can't perceive any security benefit(Any jailbroken phone can be tooled to output the unencrypted binary. And you can bet anyone trying to reverse engineer your app will be using a jailbroken phone for their work)

Basically, if you're a large company with lots of apps and shared dependencies(Google, Facebook, etc...) doing the "right" thing and writing shared library code across projects ends up bloating your binary size immensely. And since binary size(rather than resources like images) dominate the final app size, you're in trouble if you want to keep app size down.

Source: I work on the iOS app for a music streaming service, despite our best efforts, our app downloadable size is ~35MB(~45MB installed size). Our android counterpart, almost effortlessly has the same app functionality with a 14MB downloadable package(they did some cleaning a while ago and got it down to 10MB at some point). Thing is, if we do proper compression(no binary encryption, single architecture) we end up with a 19MB .ipa file

PS: The compression issue doesn't affect installed size, but I believe the issue here is simply that (1) the binary format they're using is just too damn inefficient by default

[flamedoge]

shame since shared library was suppose to be "DRY". Why not run compression and then encryption?

[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.

[alimbada]

> I get mail, I read mail, I can write mail.

That's exactly what the Gmail app does too. What other features does it offer that the Mail app doesn't? If none, then why does it need to be so huge?

I picked on Gmail because it's the most recent culprit that I have noticed creeping (sometimes jumping) up in app size but it isn't the only one guilty of this. Like I said in my original comment, the Reddit app is 13MB and does a bit more than the Gmail app. I can read/write posts and comments and view images; similar features to Gmail, but I can also watch gifs and videos. Can someone explain why there is an order of magnitude of discrepancy between the two apps sizes?

[ceeK]

They're probably using several bloated SDK's within their app for core Google services, view elements etc etc. If they're using dynamic linking, they have to include these in the binary even if they only use a small percentage of the libraries.

That's potentially one explanation.

[bwat49]

I've never used the ios mail app, but in general gmail has a weird imap implementation that behaves wonky with a lot of mail clients so with gmail using the webmail or a gmail specific app is usually preferable.

[jandrese]

I made the mistake of getting a 16GB iPhone 4s last time. I'll never make that mistake again (well, it's impossible now I guess). I was forever having to delete stuff to make room for updates (and IOS gets all sideways when you run out of space halfway through an app update) and managing the memory. It's just not worth the constant headache.

[bpicolo]

Yeah, I have a 16gb iPhone 6 and it's gotten unbearable in the past few month. I don't even keep many apps around. No room for my music anymore :(

[tqkxzugoaupvwqr]

I use the built-in Mail app on macOS and iOS for Gmail accounts. Works well. If you need space, you should give it a try.

[izacus]

For comparison - GMail app on my Pixel XL takes 31MB for the app and about 10MB for data and cache.

[JeremyBanks]

That's more due to Google offloading common logic into shared Android and Play components than compiler efficiencies.

[izacus]

Erm, that's not true. As soon as GMail app updates on Android, it replaces the builtin one with full features. The shared "Play components" are things like push handling, which is builtin on iOS as well.

Play services and OS do not carry GMail shared components.

[notyourwork]

This is the type of comment I come to hackernews for. Great summary of the possible situation.

[adomanico]

It does seem to be affecting the end user binary size: http://imgur.com/a/FEgQY

These numbers were all around 60mb on Xcode 8.2.1

[DavidSJ]

60 millibits is pretty small.

(Pardon the joke, but while the "m" obviously means "M" from context, I really wish people -- especially computer engineers -- wouldn't say bits when they mean something eight times as large.)

[defined]

I think you have a good point. The whole reason for standards (like SI units) is so that people don't need to guess or interpret. I don't get why this was downvoted.

[kibwen]

A bit isn't a divisible unit, so nobody is going to be confused as to whether "mb" stands for "millibits". As for the capitalization of "b", if we're going to be pedantic then we should say "Mo" for "megaoctets", since "byte" is, as far as IEEE standards are concerned, of ambiguous length. But I think we can trust people enough to not spend too long puzzling over whether "mb" means megabytes or megabits, just as we can trust them to assume that byte implies eight bits in this context.

[rsync]

"A bit isn't a divisible unit"

What ? Sure it is. When you measure the information content (or, the entropy) of a message, you very frequently get non-integer numbers of bits per (character/unit/message/whatever).

Written english, for instance, has 1.46 bits of information per character.

Or 146 cb.

[kev009]

That is expressing a ratio. A more concrete example, .46 a person doesn't exist even if that ratio is useful for expressing statistics.

[akvadrako]

Or to express it another way, a variable with 3 possible states has 0.5 bits more capacity than one with 2.

[PeCaN]

> you very frequently get non-integer numbers of bits per (character/unit/message/whatever)

That'd be an average, and it's like when you have 2.58 people per household. Presumably most people do not keep about 6/10 of a person around.

The point of a bit (in information theory) is that it is the smallest possible (read: not divisible) unit of information.

[yjftsjthsd-h]

> But I think we can trust people enough to not spend too long puzzling over whether "mb" means megabytes or megabits

Please don't assume this. I have the great pleasure working with network Engineers, who have apparently globally decided that bits are a perfectly reasonable measurement of throughput and react very differently to speed in Mb/s and MB/s. I'm not trying to be pedantic or say that this is how it should be, I'm just saying that people really do use both units and it is horribly confusing and anything you can do to not be ambiguous is appreciated.

[defined]

Well, no. If we're going to be pedantic, we should say MiB (mebibytes), because file sizes on disk are expressed in multiples of powers of 2, but the SI prefixes are multiples of 10.

So a 1 megabyte file (as reported by the file system) is actually 1048576 bytes, which technically - sorry, I mean pedantically - speaking, is 1 mebibyte.

To make matters worse, disk manufacturers use the decimal prefixes, so our nice 1 terabyte drive is 931 mebibytes, but is reported by the file system as 931 megabytes (not MiB).

Finally, memory manufacturers use the binary prefix, so 1 megabyte of RAM is actually 1 mebibyte (1048576 bytes).

A bit of a mess, no?

All the above is, IMHO, a consequence of imprecision. If we get used to being loose with our terminology, we risk carrying that attitude over into our work product, with sometimes regrettable results.

So I'll continue to strive to be pedantic (translation: precise).

[srssays]

> Well, no. If we're going to be pedantic, we should say MiB (mebibytes), because file sizes on disk are expressed in multiples of powers of 2,

Not true anymore. OS X (and I assume iOS) reports sizes in power-of-10 units.

If you think about it, it is really user-hostile to express file sizes as powers-of-two. Who can remember that a "GiB" is 1073741824 bytes?

[ce4]

You probably meant 1TB to be 931 Gibibytes, didn't you?

[tempodox]

While we're at it, one should use “Mi”, not “M”. M is still 1000 * 1000, while Mi is 1024 * 1024.

That amount of sloppiness in any other engineering discipline would just finish you off immediately.

[btschaegg]

Agreed. Fun fact: Wolfram alpha understands Mebibytes, which is useful if you want to quickly convert between networking specs (say megabits) and "real" computer units.

Then again, maybe doing more simple math by actually using one's brain wouldn't hurt either. :)

Edit: And yes, I'm aware that you'll never get the converted speed of what is written on the network device's box. But sometimes it's nice to have an upper limit you can compare to at least.

[kupiakos]

After using many Unix tools that have this convention, I'm ok with 10 M referring to 1010241024 bytes (10 MiB), contrasted with 10 MB meaning 10,000,000 bytes.

[defined]

Ah, I didn't see your comment before I wrote mine. And I agree violently with your point of view.

[falsedan]

This is gatekeeping, since the message is coded to be obvious to those "in the know" (of course mb means mebibyte!) but is a barrier to those who are trying to learn more (mb probably means megabits per second? it's a unit for measuring download speed? why is the 's' left off?)

This is putting the burden of collaboration in the wrong place: it shouldn't be a question of, can we expect a reasonable engineer in the industry to understand this unambiguously (with some deductions); but rather, can I hold down the shift key when typing the abbreviation for megabytes.

Obviously this depend on the actual audience, don't bother following this in team chat where speed is more important than clarity.

[JohnStrange]

It is divisible in information and coding theory, where it makes perfect sense.

[ldev]

Because we solve practical problems, and do not nit pick of what is technically correct. We are not drones and easily understand that in this context it's megabytes.

Just look at all that "technically it's mebibytes bla bla bla" in replies. No one cares. Write some code. Or better - go outside.

[tripzilch]

space launches have crashed because of confusion over standard units.

in that case it was confusion between metric and certain fantasy engineering units, but an error of 1000/1024 will cause troubles just as badly.

so with that attitude maybe don't write that code, and better stay inside or a rocket might fall on your head.

but for serious, that correction probably has taught more than 10 people the difference between uppercase B = bytes, lowercase b = bits, uppercase M = mega = 1 000 000, lowercase m = milli, MiB = mebibyte = 1024 x 1024 bytes = 1 048 576 bytes, or at least made them aware of the important fact there is a difference. while your pedantry about nitpicking has taught nobody anything except to always be alert cause there's people like you that like to offload mental ballast and use wrong units because they insist their errors can be inferred and corrected from context... which is an important lesson also, but as a warning, not to defend the behaviour.

[defined]

This. Thank you.

[dom0]

Insightful comment which took me 2700 mS to write.

[JCharante]

You can downvote?

[mercer]

Yeah, when your karma is high enough. I don't know what the amount is that leads to downvote enlightenment though.

[eric_h]

I believe it is 1000.

[jsmthrowaway]

And I really wish people wouldn't start this argument when it's clear what was meant from context. We can't all get our wishes. :)

[paulddraper]

Huh, and I thought mb was "make bucket", like aws s3 mb.

http://docs.aws.amazon.com/cli/latest/reference/s3/mb.html

[saghm]

Since you said that the "m" is obvious from context, I'll compromise from now on and use "mB" exclusively

[kalleboo]

You should have included the whole window in the screenshot to prevent confusion: http://imgur.com/a/e2wb3

Specifically to those who don't use iTunes Connect, this page is titled "Estimated App Store file sizes for Build", and the (?) callout says "This is the amount of disk space the app will take up on the customer's device."

[DannyBee]

No, that's the wrong side of the store you are looking at :)

That's the size as uploaded by the developer, not downloaded to user.

[kalleboo]

Then that's pretty confusing when the (?) button next to Install Size says "This is the amount of disk space the app will take up on the customer's device."

[adomanico]

These numbers matched exactly to what is currently in the AppStore for the last release we have ready for sale

[DannyBee]

As it says below "You need to look at the download size on the end user device, not the binary size in iTunesConnect."

Is that what you are doing?

Because otherwise, it includes the bitcode size. (i don't pretend this makes sense. only that it is :P)

In any case, i would still bet more heavily on it being displayed wrong than anything else.

If i was to increase the binary size of first party apps at google by even 1%, there would be a mob with pitchforks at my desk in less than an hour.

I can't imagine apple is really different.

[techdragon]

I'm not sure the same can be assumed for Apple based on several things such as internal secrecy, differing organisational hierarchies, their willingness to focus on things that aren't tangible metrics like end user file download size.

Between the org and culture differences I'm just not so sure Apple can be safely assumed as similar as you expect.

[DannyBee]

None of the things you mention change the fact that if you increase the IOS system image size by 3x, it will likely no longer fit in the default firmware partition :)

[lawnchair_larry]

I can't imagine anywhere besides Google that would actually notice or care about that.

[DannyBee]

Gonna disagree: Pretty much anywhere that doesn't generate shitty apps cares about even small size regression

[azakai]

If so, it seems very confusing that the header is "Install Size".

[masklinn]

According to the author, the old package was 55MB including 15MB of bitcode, and the new one is 158MB including 70MB of bitcode.

So

* the bitcode portion has grown by 4.5x

* the non-bitcode portion of the bundle has grown by 2.2x (40MB to 88MB)

[Joky]

It impacts only the bitcode and not the final binary AFAIK. The issue is with debug-info not being stripped out completely as expected. It comes from a change from LLVM upstream that was made (in 3.9) to keep source locations for providing better optimization diagnostics. It interacts badly with the debug info stripping and apparently wasn't caught. It is used by the optimizer to tell you e.g. that a specific loop can't be vectorized. See http://llvm.org/devmtg/2016-11/Slides/Nemet-Compiler-assiste... for more details about how it's used.

https://twitter.com/JokerEph/status/847512069209432064 https://twitter.com/JokerEph/status/847513808570523653 https://twitter.com/JokerEph/status/847514189929234432

[mikek]

I'm seeing a 3x increase in on-device binary sizes. 20MB to 60MB.

[rurban]

I assume they added more bitcode so they can add better IPO jit optimizations in swift, across modules. Or optimize per target on those small devices.

bitcode is already compressed.

But the regression is huge, there needs to be a command-line switch to turn that off.