[HN Gopher] Xcode 14 unintentionally increases app size
___________________________________________________________________
Xcode 14 unintentionally increases app size
Author : trevor-e
Score : 136 points
Date : 2022-11-10 18:17 UTC (4 hours ago)
(HTM) web link (www.emergetools.com)
(TXT) w3m dump (www.emergetools.com)
| fcknnhvn wrote:
| This is excellent news for anyone reverse engineering these apps,
| getting all these unintentionally-released symbols. Thanks Apple!
| crazygringo wrote:
| I'm actually curious if this has security implications? Is this
| making public anything that some app developers have thought
| important to obfuscate?
| can16358p wrote:
| If any developer is relying on security by obscurity to
| protect anything sensitive, they deserve to be accessed
| better sooner than later.
|
| However there are some practical purposes od obscurity like
| in games that madd reverse engineering harder (though
| possible of course), it might become easier in some
| situations.
| YetAnotherNick wrote:
| How can companies not check app size increase before submitting
| it.
| WirelessGigabit wrote:
| Because no one cares. It's all about getting it out there asap.
| All kinds of libraries get included for 1 simple function and
| this bloats the size of the app. Blindness has set in. It used
| to be that an exe was 5MB. Now it's 150MB because it has a
| browser with it.
| stevenkkim wrote:
| Do you check app size before downloading? I know I don't, and
| even if I did, I'm not sure what I would do about it as a
| consumer.
|
| If the user doesn't care and Apple doesn't care, then the
| company probably isn't going to care either.
| TheRealPomax wrote:
| Why would they care? Whether an app is 100mb or 500mb has zero
| financial repercussions for them. (In a consumer-friendly world
| they _would_ care, and we _want_ them to care, but as is, they
| have no reason to care)
| mig39 wrote:
| Are they dropping support for bitcode altogether in the future?
| plorkyeran wrote:
| Despite the release notes claiming it'll be removed in the
| future, trying to build with bitcode enabled is already a hard
| error in some cases with Xcode 14. Similarly the app store
| doesn't strip bitcode from things uploaded to it; it instead
| just tells you to rebuild with bitcode disabled.
| trevor-e wrote:
| https://developer.apple.com/documentation/xcode-release-note...
|
| "The capability to build with bitcode will be removed in a
| future Xcode release."
|
| Yea that is the plan from Apple.
| lzooz wrote:
| Symbols not stripped? That could be fun... is there a simple way
| of downloading unencrypted ipas from the app store without access
| to a jailbroken phone?
| malhal wrote:
| Download from App Store on M1 Mac (if it supports iPad)
| johnthuss wrote:
| "With Xcode 14, any app that relied on bitcode is no longer
| stripping binary symbols from their production app."
|
| This is a thoroughly researched article that clearly shows the
| cause and provides a solution. I hope the developers of these
| apps will take heed.
| dkonofalski wrote:
| Absolutely. In fairness, though, Apple should also catch this
| and either prompt or offer some kind of solution to this for
| devs that may be unaware of this change. The author seems to
| have found just this so a little education or notification
| would go a long way.
| ridiculous_fish wrote:
| Some speculation about why Apple is deprecating bitcode in this
| SO post:
| https://stackoverflow.com/questions/72543728/xcode-14-deprec...
| lgg wrote:
| The post's fundamental premise is wrong. LLVM bitcode is not
| architecture agnostic and never has been. Apple also has used
| it once, to move from 32 bit to 64 bit on watchOS. That was
| possible, but only because the armv7k and arm64_32 ABIs were
| developed together to ensure it would work.
| pjmlp wrote:
| And because Apple's own customisations to LLVM bitcode.
| newaccount74 wrote:
| I'm pretty sure the SO answer is (partially) wrong. As far as I
| understand, Bitcode is not architecture agnostic, you can't
| just take bitcode from a 32bit compilation and turn it into a
| 64bit executable since there still are a ton of architecture
| dependent things (like memory alignment) in the bitcode.
| astrange wrote:
| Yes, this answer is wrong. LLVM IR is not generic; not only
| can you not recompile to new architectures, it's not always
| true that it doesn't care what the original language was.
| (Since it needs to know the aliasing/memory model rules of
| the original language, sometimes you need new versions of
| bitcode to handle new languages.)
|
| It's generic for a little while as long as things don't
| change too much, but eventually they do.
| pjmlp wrote:
| This is told a lot, because people keep missing the point
| that Apple has their own form of it, they don't use raw LLVM
| bitcode.
|
| See WWDC talk about watchOS migration to 64 bits.
| lilyball wrote:
| That's true. However it is microarchitecture agnostic.
| throw10920 wrote:
| Isn't machine code also microarchitecture agnostic? I
| thought that the definition of a microarchitecture was a
| particular implementation of an ISA that externally
| conformed to the ISA in the same way as any other
| microarchitecture.
| valleyer wrote:
| Mostly, yeah. But microarchitectures do sometimes add new
| instruction set extensions, like how Intel's Skylake
| added AVX-512. Bitcode can be re-lowered to the new
| extended ISA to use these instructions (assuming you
| don't need to target earlier uarchs). Machine code, not
| as easily (and I don't think anyone really tries, though
| I'd be interested to learn if someone does).
| AnotherGoodName wrote:
| Does app size matter for install rates? I suspect not on high end
| mobile but this accident should give some data towards this.
|
| Will throw a spanner into the 'we can't release that feature as
| it will increase app size' thinking that I've witnessed in my
| mobile dev career. I've never seen it actually impact metrics
| that much.
| toast0 wrote:
| Larger apps lead to more cycling behavior. Remove X and Y,
| install Z, then later remove Z to install something else.
| Biggest app that doesn't need to be installed at the moment
| gets removed first.
| arcticbull wrote:
| They answer is yes, but only in some cases:
|
| - Getting warned about app size over cellular, which in iOS
| happens at 200MB.
|
| - In geographies where cellular data is expensive, slow or
| intermittent.
|
| - At the margin when you have many millions of users. The data
| bears out that it does have a small but measurable impact.
| wlesieutre wrote:
| There's a 200 MB size threshold where users on cellular
| connections get prompted if they're sure they want to download
| it, so if this pushes an app over 200 MB I would assume yes
| some users will bounce off of that.
|
| And in some places 200 MB can still be a big deal, the whole
| world isn't on 20 GB data plans.
| ajsnigrutin wrote:
| 200MB for a 3d game with a bunch of assests... sure... but
| somehow there are more and more >200MB apps, that are
| basically a packed webapp that should be below 10MB.
| _aavaa_ wrote:
| High end or low end it doesn't matter. Poorly engineered is
| poorly engineered regardless. High end phones with lots of
| storage can (for now) get away with running apps that take up
| 2x more space than they need to. For an analogous problem try
| running poorly coded apps on old hardware, looking at you MS
| teams or zoom.
| AnotherGoodName wrote:
| Sure but I've witnessed poor engineering from trying to keep
| app size down.
|
| A great example is 'make that feature entirely as a WebView
| to our site so we don't increase app size'.
| _aavaa_ wrote:
| Well hold on. That seems to be begging the question. If a
| whole feature can be replaced by a web view (and the site
| is already there), is an app actually required?
| [deleted]
| newaccount74 wrote:
| There are A LOT of people who ran out of space on their phones
| and can't install anything anymore. So if your app is 500MB,
| they'll first have to find 500MB worth of stuff to delete.
|
| If they really want your app, they'll look through the storage
| settings on their phone, and start deleting their biggest apps.
|
| So if your app is too big, many people won't even install it,
| and if they do, it'll be the first app to go if they need more
| space.
| mring33621 wrote:
| YES! Size matters.
|
| I just moved from android to apple and the IOS apps are 2x - 5X
| larger
|
| It's really a disgusting tax and I install a lot less apps as a
| result.
|
| They could easily fix this by adding intelligence in the App
| store, to serve up the binary for my device's architecture, but
| no, I have to get the universal bloated binary pig.
|
| Example: You're about to pay your bill at a restaurant. The
| server tells you that they have an app that will get you a
| discount/loyalty points. Your cell has a 4G connection. On
| android, the download size is 20-50MB. No problem. On IOS, the
| download size is 40-240MB. Problem!
| pyr0hu wrote:
| I don't know, downloading 40-240MB on 4G connection is not
| taking too much time. 4G is pretty fast
| ladberg wrote:
| While there is a lot of unfortunate size bloat in iOS apps
| (like the one in the article), including unnecessary
| architectures is not one of them.
|
| See the app thinning section here:
| https://developer.apple.com/documentation/xcode/doing-
| advanc... (which is automatically done on all apps
| distributed through the App Store)
| goldcd wrote:
| I'm not sure it affects install rates - but I know when I've
| been cleaning up my phone the apps that seem to occupy orders
| of magnitude more than their function would suggest, get culled
| first.
|
| Makes me feel old. I'm sure 20 years ago I could have told you
| say what app/game had been installed from floppies and which
| was "CD ROM only" My phone apps? Couldn't even guess as to
| their storage requirements. Probably a good thing that storage
| is so plentiful we normally don't care - but cynic in me thinks
| that a company selling storage with a massive markup, maybe
| doesn't have aligned interests.
|
| If 0.1% of people install an app, and it consumes a gig rather
| than 500Meg - and we sell millions of phones. That does turn
| into a real money pretty fast.
| gumby wrote:
| I thought the idea of bitcode is that Apple would produce
| binaries for each kind of supported device (i.e. different CPUs
| for supported models). Basically the benefit of a fat binary
| without having to generate one.
|
| Did they give up on this idea? Was it not worth it?
|
| EDIT: ridiculous_fish posted a link with some surmises on this
| question.
| pjmlp wrote:
| Because to gain some stability about the raw LLVM bitcode they
| had to maintain their own fork, and most likely decided it
| wasn't worth the effort any longer.
|
| Somehow people keep missing that Apple's clang and LLVM aren't
| the same one gets from clang.org.
| plorkyeran wrote:
| The one publicly known production use of bitcode was that it
| allowed them to recompile all existing armv7 watchOS apps as
| arm64_32, which made it so that the first 64-bit apple watch
| could run existing apps. This required specifically designing
| arm64_32 (which is arm64 but with 32-bit pointers) to enable
| this, and isn't really a viable approach for anything other
| than this specific scenario where they knew that they'd be
| migrating to a specific new architecture in the future.
|
| Before the first 64-bit watch was announced they were very
| vague and hand-wavy about what bitcode was for because they had
| to keep the upcoming products a secret, and sort of implied
| that it'd be used for things which didn't actually make very
| much sense.
| alerighi wrote:
| I think that here Android is a better ecosystem: you
| distribute your application as a bytecode, and then it's the
| phone itself to compile it to a real binary when you install
| it. This allow far greater compatibility with even very old
| versions of the OS or old applications in newer OS and
| simplifies the build process.
|
| Working in a company that builds both Android and iOS
| application I have to say that building iOS apps generates
| 10x the problems that you have with building Android
| applications, in terms of CI infrastructure, that means that
| Android you run gradlew and it works, provided you have the
| right JVM version installed, with XCode it's always a mess.
| Also for how it works the ecosystem with Android I'm not
| forced to upgrade, that means that if a project uses SDK X I
| can build it forever with that SDK and it will still work
| even on latest devices, with Apple you have to build with the
| latest toolchain if you want to execute on newer terminals.
| That makes Android far more suitable for b2b applications.
| pjmlp wrote:
| While I dislike the way Google has managed the whole
| Android Java story, the way they have doubled down on a
| managed environment for computing is great.
|
| Certainly not the first, yet it shows how it can look like
| when everyone is committed to make it happen, unlike what
| WinDev did during Longhorn project.
| arjvik wrote:
| Until apps start adding native code via the NDK, then you
| need one binary per arch
| pjmlp wrote:
| Unless one is a game developer, otherwise using the NDK
| is an exercise in masochism.
|
| In any case, Intel devices used to have ARM emulators,
| and Android on ChromeOS still does it.
|
| https://developer.android.com/topic/arc/device-
| support#arm-t...
___________________________________________________________________
(page generated 2022-11-10 23:00 UTC)