4 ms·

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 mean

by bdash 10y ago

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 10y ago
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.
- anderscarling 10y ago
  That's troubling. :( Same for both swift and objC?
- bdash 10y ago
  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 10y ago
    Why would they do that, visually in the store?
    - bdash 10y ago
      I'm not sure what you're asking here. Why would who do what?
      - Exuma 10y ago
        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 10y ago
        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 10y ago
        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 10y ago
        ty
- natch 10y ago
  You need to look at the download size on the end user device, not the binary size in iTunesConnect.
anderscarling 10y ago
Would be interesting to see numbers for the compiled, stripped and thinned binary the end user will download from the App Store (they are in the details view for the app build on iTunes Connect). My guess is that at least most of the change should go away there. With bitcode, app thinning and what not in the mix the Xcode build artifact is so much different from what's actually being downloaded it's hard to tell if this radar has real world implications for anyone but the developer uploading the build to apple. Still interesting, and potentially annoying though.
- bdash 10y ago
  The Apple bug report was filed by my colleague, JP, after we noticed that the built size of Realm's frameworks dramatically increased after updating to Xcode 8.3. We pay attention to the built size of our frameworks as we distribute precompiled versions of them (https://github.com/realm/realm-cocoa/releases https://github.com/realm/realm-cocoa/releases), and a signifiant size increase inconveniences our users. We've not tested the impact of the size on an app installed via the App Store, but since the increase is limited to the bitcode portion of the binary we have no reason to think it will be affected.
sigjuice 10y ago
I'm not well versed in the details of iOS development. Why is this inconvenient during development? Is the bitcode portion copied to your device and is a slow process?
- bdash 10y ago
  Some people like to check in precompiled versions of their dependencies. Others like to distribute precompiled versions of their frameworks or libraries. Larger binaries aren't great for either of those cases.
- anderscarling 10y ago
  Larger files to store and upload to iTunes Connect mostly. I don't think bitcode is ever transferred to development devices. I guess there is also a risk that the compilation process generating 3x larger files could also be slower as more work are being done - but that's just speculation.
lordnaikon 10y ago
Is this also true to user downloads from a website? The majority of your clients get our apps via Enterprise certificates not through the Apple store process.
- bdash 10y ago
  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.
- aaronbrager 10y ago
  When you create an archive, Xcode includes the full version of your app but allows you to export variants from the archive. I think most enterprise users disable bitcode for simplicity but it's possible to slice the variants and deliver the correct one to your users based on their device if you want to.
rincebrain 10y ago
As [1] points out above, while the largest increase is in the bitcode, it's still a 2.2x increase in the non-bitcode portions of the binary. [1] - https://news.ycombinator.com/item?id=13993961 https://news.ycombinator.com/item?id=13993961
- masklinn 10y ago
  And the 2.2x non-bitcode increase seems consistent with adomanico's report of a 2~3x increase of "App Store File Sizes" as reported by iTunes Connect: https://news.ycombinator.com/item?id=13992107 https://news.ycombinator.com/item?id=13992107

by bdash 10y ago

adomanico 10y ago

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.

anderscarling 10y ago
That's troubling. :( Same for both swift and objC?
bdash 10y ago
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 10y ago
  Why would they do that, visually in the store?
  - bdash 10y ago
    I'm not sure what you're asking here. Why would who do what?
    - Exuma 10y ago
      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 10y ago
        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 10y ago
        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 10y ago
        ty
natch 10y ago
You need to look at the download size on the end user device, not the binary size in iTunesConnect.

anderscarling 10y ago

Would be interesting to see numbers for the compiled, stripped and thinned binary the end user will download from the App Store (they are in the details view for the app build on iTunes Connect). My guess is that at least most of the change should go away there. With bitcode, app thinning and what not in the mix the Xcode build artifact is so much different from what's actually being downloaded it's hard to tell if this radar has real world implications for anyone but the developer uploading the build to apple. Still interesting, and potentially annoying though.

bdash 10y ago
The Apple bug report was filed by my colleague, JP, after we noticed that the built size of Realm's frameworks dramatically increased after updating to Xcode 8.3. We pay attention to the built size of our frameworks as we distribute precompiled versions of them (https://github.com/realm/realm-cocoa/releases https://github.com/realm/realm-cocoa/releases), and a signifiant size increase inconveniences our users. We've not tested the impact of the size on an app installed via the App Store, but since the increase is limited to the bitcode portion of the binary we have no reason to think it will be affected.

sigjuice 10y ago

I'm not well versed in the details of iOS development. Why is this inconvenient during development? Is the bitcode portion copied to your device and is a slow process?

bdash 10y ago
Some people like to check in precompiled versions of their dependencies. Others like to distribute precompiled versions of their frameworks or libraries. Larger binaries aren't great for either of those cases.
anderscarling 10y ago
Larger files to store and upload to iTunes Connect mostly. I don't think bitcode is ever transferred to development devices. I guess there is also a risk that the compilation process generating 3x larger files could also be slower as more work are being done - but that's just speculation.

lordnaikon 10y ago

Is this also true to user downloads from a website? The majority of your clients get our apps via Enterprise certificates not through the Apple store process.

bdash 10y ago
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.
aaronbrager 10y ago
When you create an archive, Xcode includes the full version of your app but allows you to export variants from the archive. I think most enterprise users disable bitcode for simplicity but it's possible to slice the variants and deliver the correct one to your users based on their device if you want to.

rincebrain 10y ago

As [1] points out above, while the largest increase is in the bitcode, it's still a 2.2x increase in the non-bitcode portions of the binary. [1] - https://news.ycombinator.com/item?id=13993961 https://news.ycombinator.com/item?id=13993961

masklinn 10y ago
And the 2.2x non-bitcode increase seems consistent with adomanico's report of a 2~3x increase of "App Store File Sizes" as reported by iTunes Connect: https://news.ycombinator.com/item?id=13992107 https://news.ycombinator.com/item?id=13992107