19 ms·

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

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.

adomanico 10y ago
It does seem to be affecting the end user binary size: http://imgur.com/a/FEgQY http://imgur.com/a/FEgQY These numbers were all around 60mb on Xcode 8.2.1
- DavidSJ 10y ago
  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.)
  - jsmthrowaway 10y ago
    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. :)
  - saghm 10y ago
    Since you said that the "m" is obvious from context, I'll compromise from now on and use "mB" exclusively
  - paulddraper 10y ago
    Huh, and I thought mb was "make bucket", like aws s3 mb. http://docs.aws.amazon.com/cli/latest/reference/s3/mb.html http://docs.aws.amazon.com/cli/latest/reference/s3/mb.html
  - defined 10y ago
    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 10y ago
      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 10y ago
        "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 10y ago
        That is expressing a ratio. A more concrete example, .46 a person doesn't exist even if that ratio is useful for expressing statistics.
        drdeca 10y ago
        I think "gaining half a bit of information" about something can correspond to stuff that lets you update your probability distribution about it? I'm not sure.
        kristjankalm 10y ago
        yes, but your gain is still an integer number. the non-integer ratio is just a statistic (gain per number of units).
- DannyBee 10y ago
  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.
  - adomanico 10y ago
    These numbers matched exactly to what is currently in the AppStore for the last release we have ready for sale
    - DannyBee 10y ago
      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 10y ago
        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 10y ago
        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 10y ago
        I can't imagine anywhere besides Google that would actually notice or care about that.
- kalleboo 10y ago
  You should have included the whole window in the screenshot to prevent confusion: http://imgur.com/a/e2wb3 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."
notyourwork 10y ago
This is the type of comment I come to hackernews for. Great summary of the possible situation.
mikek 10y ago
I'm seeing a 3x increase in on-device binary sizes. 20MB to 60MB.
mikek 10y ago
I'm seeing a 3x increase in on-device binary sizes. 20MB to 60MB.
rurban 10y ago
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.
alimbada 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
    > 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?
masklinn 10y ago
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 10y ago
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-assistedPerformanceAnalysis.pdf 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/847512069209432064 https://twitter.com/JokerEph/status/847513808570523653 https://twitter.com/JokerEph/status/847513808570523653 https://twitter.com/JokerEph/status/847514189929234432 https://twitter.com/JokerEph/status/847514189929234432

adomanico 10y ago

It does seem to be affecting the end user binary size: http://imgur.com/a/FEgQY http://imgur.com/a/FEgQY These numbers were all around 60mb on Xcode 8.2.1

DavidSJ 10y ago
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.)
- jsmthrowaway 10y ago
  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. :)
- saghm 10y ago
  Since you said that the "m" is obvious from context, I'll compromise from now on and use "mB" exclusively
- paulddraper 10y ago
  Huh, and I thought mb was "make bucket", like aws s3 mb. http://docs.aws.amazon.com/cli/latest/reference/s3/mb.html http://docs.aws.amazon.com/cli/latest/reference/s3/mb.html
- defined 10y ago
  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 10y ago
    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 10y ago
      "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 10y ago
        That is expressing a ratio. A more concrete example, .46 a person doesn't exist even if that ratio is useful for expressing statistics.
        drdeca 10y ago
        I think "gaining half a bit of information" about something can correspond to stuff that lets you update your probability distribution about it? I'm not sure.
        kristjankalm 10y ago
        yes, but your gain is still an integer number. the non-integer ratio is just a statistic (gain per number of units).
DannyBee 10y ago
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.
- adomanico 10y ago
  These numbers matched exactly to what is currently in the AppStore for the last release we have ready for sale
  - DannyBee 10y ago
    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 10y ago
      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 10y ago
        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 10y ago
      I can't imagine anywhere besides Google that would actually notice or care about that.
kalleboo 10y ago
You should have included the whole window in the screenshot to prevent confusion: http://imgur.com/a/e2wb3 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."

notyourwork 10y ago

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

mikek 10y ago

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

mikek 10y ago

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

rurban 10y ago

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.

alimbada 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
  > 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?

masklinn 10y ago

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 10y ago

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-assistedPerformanceAnalysis.pdf 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/847512069209432064 https://twitter.com/JokerEph/status/847513808570523653 https://twitter.com/JokerEph/status/847513808570523653 https://twitter.com/JokerEph/status/847514189929234432 https://twitter.com/JokerEph/status/847514189929234432