10 ms·
Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1
- deleted 10y ago[deleted]
- alien3d 10y agoThe same codebase compiled with Xcode 8.3 produces a binary about three times larger at 158MB, including 70MB for bitcode alone. Apple limit 100 mb per download.. So this big issue for all developer.We need apple to remove the limitation over 100 mb or atleast 1GB.
- HappyTypist 10y agoBitcode size =/= binary size. Your binary sizes will remain similar.
- alien3d 10y agoif so okay, but still i do confuse with the limitation of 100mb.Sometimes facebook apps can update more then 100 mb and some apps cannot update over 100 mb.
- 0x0 10y agoThat's probably because the app store may offer a delta update patch instead of a full download.
- alien3d 10y agoi prefer to knew more about it.. but seem here down vote making me sad those coward downvoter.. maybe i will close this account..
- Nexxxeh 10y agoI didn't downvote you, but I can help you understand why you were downvoted. On HN, you'll usually get an answer if you ask a question. "Is x going to be a problem for y?" Making an incorrect statement however will get you downvoted. "x will be a problem for y." The other issue is your writing quality. You will get better results if you put more effort into your writing. You don't have to have perfect English. Many people on HN have English as a second language. Things like a capital letters at the start of a sentence, and using single full stops (periods) at the end of sentences, show effort. You will find people will be more tolerant of grammar issues if you at least put effort into the basics.
- bdash 10y agoNote 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 agoUnfortunately 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 agoThat's troubling. :( Same for both swift and objC?
- bdash 10y agoI 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.
- DannyBee 10y agoThis 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 agoIt 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 ago60 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 agoAnd 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 agoSince you said that the "m" is obvious from context, I'll compromise from now on and use "mB" exclusively
- paulddraper 10y ago
- apple-fan-941 10y agoThis is due to bitcode, which won't actually affect the binary size seen by end users (i.e. app download size): https://twitter.com/jckarter/status/846796503775567872 https://twitter.com/jckarter/status/846796503775567872 "That at least shouldn't affect your users' download size, then."
- lordnaikon 10y agoIs this only true for store downloads? Because the majority of our apps is delivered simply by a website download through the device via Enterprise certificates.
- bdash 10y agoIf 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.
- deleted 10y ago[deleted]
- sneak 10y agoApple charges $1200 to upgrade the latest touch bar rMBP from 512GB to 2TB of flash. Let's not forget that they are a hardware vendor. I don't think it's some grand conspiracy theory, but the interests of the vendor and of the user are not precisely aligned when it comes to efficient usage of storage. (The lack of stripping applications of their alternate language content on install/download also comes to mind.)
- qzervaas 10y agoThis theory is pretty easily debunked when you consider the primary goal of bitcode is to strip assets from apps that aren't relevant to a user's device, hence taking up less space. (For example, removing @2x images for a plus device that uses @3x images, or vice-versa).
- sneak 10y agoI said explicitly in my comment that I don't think this is some grand conspiracy. I don't think Xcode makes big files to use up disk space. I think Apple just has little incentive across the entire ecosystem to use less storage or use storage more efficiently. Afaik bitcode is so that Apple can rebuild binaries for different target architectures (e.g. new models of phone, watch, et c) without source developer interaction. It should come in major handy in the OSX app store when ARM64 Macbooks ship in a year or two. A full app store of working apps on hardware launch day will make the bitcode requirement worth it when it's the smoothest architecture transition they've ever done (out of 680x0->ppc and ppc->x86).
- deleted 10y ago[deleted]
- LeoNatan25 10y agoBitcode does not allow cross-architectural builds. This is a common misconception. IR (& bitcode) includes architecture and platform-specific ABI. What it does allow is for better optimizations as the LLVM backend optimizer improves.
- deleted 10y ago[deleted]
- nstj 10y agoReally need to change the title to reflect that the increase in size is not present in App Store binary. Side note: filing a Radar is the new top of the customer acquisition funnel. Go Realm! :)
- CppCoder 10y agoDid anyone actually look at the content which is responsible for the increase in size? I hope it does not include the source itself, comments, and who knows what.
- perlpimp 10y agowonder what would https://github.com/google/bloaty https://github.com/google/bloaty say about those binaries...
- mwexler 10y agoSo, the app explodes in size, and since almost no app provides a "clear cache/temp" feature, apps grow til you are crashing routinely. While iOS may clear some space when it feels like it, I have a monthly routine of deleting and reinstalling a slew of apps which take up gigs of space on the device after usage, even though they are just showing data stored on a server. I know, I shouldn't have to worry about this, that iOS will eventually clean it up... but when apps are crashing b/c they can't get space, I wind up having to manually step in. So, a) for devs, if you think your app caches, provide a way to clear it (look at Opera's Coast browser, who puts it in the Settings app), and b) for users, if you think you are out of space, look at apps and compare app size to total space, and you'll find some hogs.
- ar15saveslives 10y agoiOS cleans up Caches/tmp directory, it it needs space. https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1 https://developer.apple.com/library/content/documentation/Fi... > "Note that the system may delete the Caches/ directory to free up disk space, so your app must be able to re-create or download these files as needed." > tmp: "however, the system may purge this directory when your app is not running."
- vinayan3 10y agoDespite this claim. It doesn't feel like it happens. Maybe, apps aren't writing the Cache files to the right place and that's why they aren't being cleaned up.
- mwexler 10y agoBut system controlled garbage collection is great until it's not. When I need space, I need it now, not when system decides I do. We've seen it with Java, and now with iOS. Yet another thing that iOS does on my behalf that I may wish to do myself.
- kalleboo 10y agoI made the mistake of buying a 16 GB iPad mini 2. While pretty much all I use on it are a screenful of streaming apps, it's chronically low on memory. I have iCloud Photos enabled and it set to optimize storage, but it regularly gets in a situation where there's not enough free storage to upload new photos to iCloud Photos, since iCloud Photos has filled up the 4 GB free storage...
- aaronfuqua 10y agoIsn't 10.3 the first version that is introducing the new APFS file system? If so, couldn't that have something to do with it? Does each app need to compile for both supported file systems now? I am not a LLVM expert but someone with more expertise on this subject might be able to say. I just found it odd that no one else here had mentioned it. It is the big update for 10.3
- djrogers 10y agoApps aren't compiled for a specific file system, so no.
- dep_b 10y agoIt also seems to take 3x longer while the previous version was no speed demon either. Guess why I have so much time to post here?
- sebow 10y agoRemind me of Visual Studio
- LeoNatan25 9y agoThis has been fixed with Xcode 8.3.1.