Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1(openradar.me) |
Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1(openradar.me) |
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.
1 - The binary format itself isn't very efficient. Compressing it usually yields at least a 50% reduction in final size, often more
2 - Even though .ipa is a zipped format, there's no actual compression on the binary itself because it's encrypted before compression. I have no idea why they do this, I can't perceive any security benefit(Any jailbroken phone can be tooled to output the unencrypted binary. And you can bet anyone trying to reverse engineer your app will be using a jailbroken phone for their work)
Basically, if you're a large company with lots of apps and shared dependencies(Google, Facebook, etc...) doing the "right" thing and writing shared library code across projects ends up bloating your binary size immensely. And since binary size(rather than resources like images) dominate the final app size, you're in trouble if you want to keep app size down.
Source: I work on the iOS app for a music streaming service, despite our best efforts, our app downloadable size is ~35MB(~45MB installed size). Our android counterpart, almost effortlessly has the same app functionality with a 14MB downloadable package(they did some cleaning a while ago and got it down to 10MB at some point). Thing is, if we do proper compression(no binary encryption, single architecture) we end up with a 19MB .ipa file
PS: The compression issue doesn't affect installed size, but I believe the issue here is simply that (1) the binary format they're using is just too damn inefficient by default
These numbers were all around 60mb on Xcode 8.2.1
(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.)
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."
That's the size as uploaded by the developer, not downloaded to user.
So
* the bitcode portion has grown by 4.5x
* the non-bitcode portion of the bundle has grown by 2.2x (40MB to 88MB)
https://twitter.com/JokerEph/status/847512069209432064 https://twitter.com/JokerEph/status/847513808570523653 https://twitter.com/JokerEph/status/847514189929234432
bitcode is already compressed.
But the regression is huge, there needs to be a command-line switch to turn that off.
Side note: filing a Radar is the new top of the customer acquisition funnel. Go Realm! :)
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.
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."
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.)
(For example, removing @2x images for a plus device that uses @3x images, or vice-versa).
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.
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.
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.
Binary sizes in iTunes connect (from our Xcode 8.3 build) all were 2x-3x larger depending on device.
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).
As for alternate language content, honestly that stuff doesn't take up very much space, and stripping it would break the code signature. The only way Apple could strip that is if they perform the equivalent of App Thinning based on a list of languages you specify when downloading the binary from the App Store (and even that wouldn't apply to downloading non-MAS apps).
Yeah. It's not like Apple had to settle lawsuits about batteries that seemed to be designed to break after a while. Oh, wait...
Play services and OS do not carry GMail shared components.
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
Google must have some insane cross-platform code library or something in there.
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?
That's potentially one explanation.
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.
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.
Please don't assume this. I have the great pleasure working with network Engineers, who have apparently globally decided that bits are a perfectly reasonable measurement of throughput and react very differently to speed in Mb/s and MB/s. I'm not trying to be pedantic or say that this is how it should be, I'm just saying that people really do use both units and it is horribly confusing and anything you can do to not be ambiguous is appreciated.
So a 1 megabyte file (as reported by the file system) is actually 1048576 bytes, which technically - sorry, I mean pedantically - speaking, is 1 mebibyte.
To make matters worse, disk manufacturers use the decimal prefixes, so our nice 1 terabyte drive is 931 mebibytes, but is reported by the file system as 931 megabytes (not MiB).
Finally, memory manufacturers use the binary prefix, so 1 megabyte of RAM is actually 1 mebibyte (1048576 bytes).
A bit of a mess, no?
All the above is, IMHO, a consequence of imprecision. If we get used to being loose with our terminology, we risk carrying that attitude over into our work product, with sometimes regrettable results.
So I'll continue to strive to be pedantic (translation: precise).
That amount of sloppiness in any other engineering discipline would just finish you off immediately.
This is putting the burden of collaboration in the wrong place: it shouldn't be a question of, can we expect a reasonable engineer in the industry to understand this unambiguously (with some deductions); but rather, can I hold down the shift key when typing the abbreviation for megabytes.
Obviously this depend on the actual audience, don't bother following this in team chat where speed is more important than clarity.
Just look at all that "technically it's mebibytes bla bla bla" in replies. No one cares. Write some code. Or better - go outside.
in that case it was confusion between metric and certain fantasy engineering units, but an error of 1000/1024 will cause troubles just as badly.
so with that attitude maybe don't write that code, and better stay inside or a rocket might fall on your head.
but for serious, that correction probably has taught more than 10 people the difference between uppercase B = bytes, lowercase b = bits, uppercase M = mega = 1 000 000, lowercase m = milli, MiB = mebibyte = 1024 x 1024 bytes = 1 048 576 bytes, or at least made them aware of the important fact there is a difference. while your pedantry about nitpicking has taught nobody anything except to always be alert cause there's people like you that like to offload mental ballast and use wrong units because they insist their errors can be inferred and corrected from context... which is an important lesson also, but as a warning, not to defend the behaviour.
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.
Between the org and culture differences I'm just not so sure Apple can be safely assumed as similar as you expect.
Bitcode can used to recompile for minor ARM updates, compiler bugs, new optimizations etc without having to get developers to submit new binaries.
Kind of.
On IBM i, C compiles to TIMI bytecode just like everything else. For producing actual native code directly from the compiler you need the Metal C compiler, or the POSIX compatibility environment (PASE).
The TenDRA C and C++ compilers also used bytecode (TenDRA Distribution Format).
(navigate to your app) > Activity > All Builds > (select the version) > (select the build) > App Store File Sizes
Not true anymore. OS X (and I assume iOS) reports sizes in power-of-10 units.
If you think about it, it is really user-hostile to express file sizes as powers-of-two. Who can remember that a "GiB" is 1073741824 bytes?
I don't think it's terribly user hostile to express sizes as powers of two when you work with these kinds of numbers for a living, especially when it's near the bare metal (Erlang binary data type FTW!)
But I do think it's user hostile to have two different units depending on what you're looking at. If it were all decimal or all binary, it would be much easier.
Then again, maybe doing more simple math by actually using one's brain wouldn't hurt either. :)
Edit: And yes, I'm aware that you'll never get the converted speed of what is written on the network device's box. But sometimes it's nice to have an upper limit you can compare to at least.
Of course when gigabit became a thing, your practical throughput was more like 75 MBps for a very long time, and being off by 25% in capacity planning is a pretty big error (one I've seen numerous engineers make, and a few make both, which means you're off by 40%)
I'm not sure.
That'd be an average, and it's like when you have 2.58 people per household. Presumably most people do not keep about 6/10 of a person around.
The point of a bit (in information theory) is that it is the smallest possible (read: not divisible) unit of information.
Entropy (in bits) is defined as - \sum_x (p(x) log_2 p(x))
There is no reason this has to be an integer, since probabilities are not restricted to being reciprocals of powers of 2.
Consider also that you can simply use a different logarithm base to get a different unit (e.g. use the natural logarithm to obtain the entropy in nats). It would be bizarre if the arbitrary choice of 2 as the base gave a unit that was indivisible.
I think this whole confusion comes down to the difference between a bit as a "unit of information in the sense of information theory" [divisible] and a bit as a "single physical one or zero" [not divisible]. The relationship between the two is that the entropy of a random variable is a lower bound on the average number of bits required to represent it.
which they aren't.
if you have a data storage thingy that can store any of three values, a ternary digit, it is exactly equivalent to log2(3) = ln(3) / ln(2) ~= 1.585 bits.
kind of like US pop-science articles like to say stuff like "a volume 1.5 olympic-size swimming pools" (because a megagallon is just weird), even though obviously, can never have half of such a pool or it would empty.
(ok after some consideration, you could have the bottom half)