51–60 of 142 posts
Earlier quoted context omitted.
Bitcode size =/= binary size. Your binary sizes will remain similar.
if 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.
Earlier 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…
That amount of sloppiness in any other engineering discipline would just finish you off immediately.
Earlier quoted context omitted.
The size I'm referring to is shown in iTunes Connect, which is the administrative side of the App Store that the developer uses to manage their app releases. As far as I'm aware the size shown in the App Store's user-facing UI does reflect the size that will be downloaded by the device. I think it's possible to see this size in iTunes Connect, but since I don't myself have any apps in the App Store I can't easily ver…
You can see the per-device estimated App Store file sizes in iTunes Connect: (navigate to your app) > Activity > All Builds > (select the version) > (select the build) > App Store File Sizes
Earlier 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…
While we're at it, one should use “Mi”, not “M”. M is still 1000 * 1000, while Mi is 1024 * 1024. That amount of sloppiness in any other engineering discipline would just finish you off immediately.
Earlier quoted context omitted.
These numbers matched exactly to what is currently in the AppStore for the last release we have ready for sale
As it says below "You need to look at the download size on the end user device, not the binary size in iTunesConnect." 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%…
Between the org and culture differences I'm just not so sure Apple can be safely assumed as similar as you expect.
This 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 "That at least shouldn't affect your users' download size, then."
Earlier 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…
"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.
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.
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.
This 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 "That at least shouldn't affect your users' download size, then."
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.
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.
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.