You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Significant binary size increase for iOS caused by engine roll #16357
According to dashboards, we are seeing iOS release size increase by 4.5M (we saw similar increases internally as well). Specific metric I was looking at was complex_layout ios release size. The culprit seems to be: 2134adc .
@cbracken is Flutter.framework/Flutter always a fat binary that includes armv7 now? If so, is this working as intended, and we're counting on thinning when it gets uploaded to app store?
The engine now includes armv7 support (though the app doesn’t yet) so this is somewhat expected. I’ll enable stripping the armv7 code using lipo temporarily but eventually the goal is for all apps to be universal binaries that run on both arm64 and armv7. We can verify the App Store does the stripping on their end when we finally enable this.
If we’re not lipo-ing binaries internally we should make sure we add that step. IIRC a bug already exists for that (or did at one point).
We do lipo binaries internally (but it is not part of the build rules themselves). We saw this increase after applying lipo.
Just for my information, could you please explain what is the difference between "lipo" and "App Store stripping"? I was assuming they are the same. If they are the same, that means App Store will not be stripping this binary either.
In that case, is the expectation to build two binaries targeting different devices? (just like we can generate multiple android binaries for different densities instead of jamming all assets into a single binary)
The flutter framework is built as a fat binary that has historically included x86_64 and arm64, and recently also added armv7. At build time in flutter_tools we build the user's app itself (also as a framework), then apply a thinning build phase which runs Apple's lipo tool over the binary and all dependent frameworks, which strips out all architectures except those necessary for the current build.
For a simulator build, this means x86_64, otherwise it typically means armv7 and arm64. Historically, we haven't shipped an armv7 framework, so in practice it meant arm64-only.
After a bit of further digging, it looks like some lipo-ing that should be happening internally is not happening. This is being tracked by b/77736869 and b/77813340.
Externally I'd like to verify our TestFlight binary download sizes. If they haven't regressed, then we can close as working as intended and re-baseline the benchmark (or update the benchmark to lipo the binaries in the same way Apple does). If they have regressed, we need to investigate what needs to be done to get App thinning enabled in ITunes Connect or elsewhere.
Thanks for the investigation. We will follow on this issue internally.
However, I would advise Flutter benchmarks to lipo release binaries the way they are done in AppStore. Two reasons:
A 250k increase for a 25M binary would be much less significant compared to a similar increase on a 11M binary. So you might miss significant bumps in benchmark.
Hello_Flutter iOS binary size is also used as an indicator for "Flutter Overhead" in multiple docs. If we are not lipo'ing these, we are giving the wrong impression.
Nothing left to do either internally or externally. We're lipo'ing binaries down to the minimum set of platforms a build should support (i.e. stripping x86 code from device builds, etc.), including in custom engine builds where only one arch is supported.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
mehmetf commentedon Apr 9, 2018
@cbracken
tvolkert commentedon Apr 9, 2018
Cross-posting from #16289:
flutter-team-archive/engine@adf5ddf -- Roll Dart to version 09e1766e6caa537e1271fbce04ebcbf8212b6569
flutter-team-archive/engine@aa9ce70 -- Add armv7 support to create_ios_framework script
@cbracken is
Flutter.framework/Flutteralways a fat binary that includes armv7 now? If so, is this working as intended, and we're counting on thinning when it gets uploaded to app store?tvolkert commentedon Apr 9, 2018
ftr, 2134adc will end up being dev release
0.2.10if this ends up being marked as a bad build.cbracken commentedon Apr 9, 2018
The engine now includes armv7 support (though the app doesn’t yet) so this is somewhat expected. I’ll enable stripping the armv7 code using lipo temporarily but eventually the goal is for all apps to be universal binaries that run on both arm64 and armv7. We can verify the App Store does the stripping on their end when we finally enable this.
If we’re not lipo-ing binaries internally we should make sure we add that step. IIRC a bug already exists for that (or did at one point).
mehmetf commentedon Apr 9, 2018
We do lipo binaries internally (but it is not part of the build rules themselves). We saw this increase after applying lipo.
Just for my information, could you please explain what is the difference between "lipo" and "App Store stripping"? I was assuming they are the same. If they are the same, that means App Store will not be stripping this binary either.
In that case, is the expectation to build two binaries targeting different devices? (just like we can generate multiple android binaries for different densities instead of jamming all assets into a single binary)
cbracken commentedon Apr 9, 2018
The flutter framework is built as a fat binary that has historically included x86_64 and arm64, and recently also added armv7. At build time in flutter_tools we build the user's app itself (also as a framework), then apply a thinning build phase which runs Apple's
lipotool over the binary and all dependent frameworks, which strips out all architectures except those necessary for the current build.For a simulator build, this means
x86_64, otherwise it typically meansarmv7andarm64. Historically, we haven't shipped anarmv7framework, so in practice it meantarm64-only.Apple's app thinning, on the other hand, happens after upload:
https://help.apple.com/xcode/mac/9.3/#/devbbdc5ce4f
cbracken commentedon Apr 10, 2018
After a bit of further digging, it looks like some
lipo-ing that should be happening internally is not happening. This is being tracked by b/77736869 and b/77813340.Externally I'd like to verify our TestFlight binary download sizes. If they haven't regressed, then we can close as working as intended and re-baseline the benchmark (or update the benchmark to lipo the binaries in the same way Apple does). If they have regressed, we need to investigate what needs to be done to get App thinning enabled in ITunes Connect or elsewhere.
mehmetf commentedon Apr 10, 2018
Thanks for the investigation. We will follow on this issue internally.
However, I would advise Flutter benchmarks to lipo release binaries the way they are done in AppStore. Two reasons:
zoechi commentedon Dec 4, 2018
Is there still something to do?
mehmetf commentedon Dec 4, 2018
Not internally. We are lipo'ing binaries properly now. @cbracken can comment whether the upstream process still needs to be improved or not.
cbracken commentedon Feb 4, 2019
Nothing left to do either internally or externally. We're
lipo'ing binaries down to the minimum set of platforms a build should support (i.e. stripping x86 code from device builds, etc.), including in custom engine builds where only one arch is supported.github-actions commentedon Aug 31, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.