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.
Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1
91–100 of 142 posts
Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1
#92Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1
#93Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1
#94Earlier quoted context omitted.
A bit isn't a divisible unit, so nobody is going to be confused as to whether "mb" stands for "millibits". As for the capitalization of "b", if we're going to be pedantic then we should say "Mo" for "megaoctets", since "byte" is, as far as IEEE standards are concerned, of ambiguous length. But I think we can trust people enough to not spend too long puzzling over whether "mb" means megabytes or megabits, just as we c…
Well, no. If we're going to be pedantic, we should say MiB (mebibytes), because file sizes on disk are expressed in multiples of powers of 2, but the SI prefixes are multiples of 10. 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…
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?
Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1
#95Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1
#96Note 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.
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.
Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1
#97Earlier quoted context omitted.
Is 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.
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.
Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1
#98Earlier quoted context omitted.
"A bit isn't a divisible unit" 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.
Or to express it another way, a variable with 3 possible states has 0.5 bits more capacity than one with 2.
Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1
#99Earlier quoted context omitted.
60 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.)
I think you have a good point. The whole reason for standards (like SI units) is so that people don't need to guess or interpret. I don't get why this was downvoted.
Just look at all that "technically it's mebibytes bla bla bla" in replies. No one cares. Write some code. Or better - go outside.
Re: Xcode 8.3 produces binaries 3x larger than Xcode 8.2.1
#100Earlier quoted context omitted.
I think you have a good point. The whole reason for standards (like SI units) is so that people don't need to guess or interpret. I don't get why this was downvoted.
A bit isn't a divisible unit, so nobody is going to be confused as to whether "mb" stands for "millibits". As for the capitalization of "b", if we're going to be pedantic then we should say "Mo" for "megaoctets", since "byte" is, as far as IEEE standards are concerned, of ambiguous length. But I think we can trust people enough to not spend too long puzzling over whether "mb" means megabytes or megabits, just as we c…
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.