I have a feeling that Apple might just start to run into the kinds of realities MS and others have been living with for years. Either they choose to piss off millions of users of older devices or figure out how to allow for evolution without causing problems for the installed base. Or, maybe they don't.
As an iDevice user I am glad that I chose to buy all my devices with the absolute max storage available. Everything I have has 64GB. So, we are good for a little bit.
As a developer I cringe at the situation. I am currently working on an app that has about 400 graphics files that will ship with the app. If you do it their way you have to produce each one of these files in four different resolutions. This means that the image directory is now huge. It is three times larger than a scenario where we would have app bundles customized for each device.
In looking at the problem we decided to do the following. All of our files are produced at what would be @2X resolution but are named without the @2X. We are going to ship the app with just 400 files at a single resolution instead of 1600 files at four different resolutions. In the end, if you do the math, your app bundle will be significantly smaller due to the significant reduction in size of the images directory.
As far as performance is concerned, the images work very well all they way back to iPod touch v2.0 devices. No issues there. So, that's the plan.
Maybe what Apple is pushing all of us towards is a scenario where we are forced to detect device type and capabilities and load resources accordingly on app first run. Think about this for a moment. Now their servers don't have to push out so much content and you will have to foot the bill for your free graphics-intensive app getting three million downloads. I could be off base here. But, I just don't see a way to deal with this unless you are willing to ship your app with thousands of files, most of which will never be used by the device the app is installed on.
I also think it's high time that apple put out an iDevice with the ability to expand memory capacity in the field. I know, I know, they want to control it all. They are big enough to have custom Flash chips made with all the encryption they want so people can't move the flash chips from phone to phone and steal software.
> I have a feeling that Apple might just start to run into the kinds of realities MS and others have been living with for years.
Why would they run into these realities now? Apple's been around just as long as Microsoft, and they have been pissing off their customer base with poor backwards compatibility the whole time. The scale is much larger now, I'll give you that, but the relentless forward-thinking is what has allowed Apple to get into the dominant position they are in now. Microsoft by contrast, got bogged down with the enterprise where large IT departments put them between a rock and a hard place by refusing to upgrade if they didn't support whatever byzantine legacy application infrastructure they were running. Even to this day where Microsoft realizes they need innovation, they are still forced to hedge their bets with this hybrid Windows 8 Metro crap.
Mark my words, this problem of app size is a tempest in a teapot. Given current trends, most iPads will be 3rd gen within a year, and in a couple years, the first iPad will fall off the iOS upgrade cycle. For every customer that Apple loses because they demand backward compatibility, they'll gain ten with the latest new shiny.
The reason Apple will not do anything this problem is not out of planned obsolescence or greed. All else being equal they would be happy for you to have unlimited space on your iPad. But to solve it is non-trivial and does not push their product forward. To the contrary, it adds complexity that will inevitably slow their product development, which runs directly contrary to their modus operandi.
"detect device type and capabilities and load resources accordingly on app first run."
That is not sufficient. You also would have to detect the case where a backup is restored to a device with a different resolution (could even be a lower resolution)
"you will have to foot the bill for your free graphics-intensive app getting three million downloads."
Not necessarily. The App Store could have provisions for doing these kinds of downloads. Because of the backup issue, I even think it would have to have support there, given that Apple would want to prevent the cases "sorry, cheapGames.com's server is awfully slow" or "sorry, junkSite.com's server has disappeared; we cannot get you the graphics for that game you bought anymore" (site names made up; if they exist in real life, the name match is coincidental)
I don't understand why "universal binaries" exist at all on iOS. On desktops where the app space is more "free" it has a purpose, but it's not like users are regularly moving apps from one iDevice to another -- so what on earth is the point of having three different things altogether? The much more intelligent solution would have been to simply allow developers to upload 3 different binaries, but only present it as one on the app store. Then the app store correctly downloads the correct one depending on your device (iTunes can keep all three if it wants or whatever), and then there is no need for the app store to muck around in your app internals or anything.
How many developers are willing to create and upload 3 different versions of their app? I seem to remember reading a thread here on HN complaining about that...
Would Apple allow an app maker to release their app for only newer iPads and iPhones, and not for the older devices? (I have no idea...)
I see your point, but users don't need to be moving apps from one device to the other. They just need to DL it on one and have it delivered to others, which is standard icloud procedure now. It's the same for backups, especially for apps that you want a copy nevermind what happens down the way (the app is deleted, the news version is crap, you can't connect to the store etc).
As a matter of price, for the reasons above I am OK to pay more for an universal app than have two different ones I'll have to manage separately.
This dilemma isn't limited to iOS, or mobile apps. It's all user-facing software. Everything that ships to users these days -- traditional desktop software, web apps, even static blogs -- is much larger than it needs to be to achieve its functionality.
This isn't necessarily a bad thing. There's a huge tradeoff between size of the product and development speed. We've switched to a pattern of bundling lots and lots of large libraries with everything we ship, and tons of static resources, and tons of translations, and on and on. And it makes everything huge.
But it means you "full-stack engineers" can knock out full-featured, money-making web apps in hours/days/weeks instead of weeks/months/years. Most of the "look at the monetized product I wrote this weekend!" posts that show up on HN could be a fraction of their size, but would have taken much longer to develop.
The link is specifically complaining about resource files, which are probably easier to manage than libraries, but it's still probably not worth the effort for Apple. By making it as simple as possible, developers don't waste any time worrying about how they are going to structure resource usage for their app. Just throw everything in there and get on with it.
At work, I develop for platforms with <1MB of RAM, and we can do plenty with them, but development time is ridiculous. You can knock out a full online dating site in 4 hours, eh? It takes that long to print "Hello World" on a serial port of a new microprocessor... maybe longer.
My side projects are in horribly wasteful monstrosities like Python and Objective-C/Foundation because, in my spare time, I like projects to actually get finished... to hell with binary size.
I agree with all the cynics saying that Apple doesn't care. Even if app sales go down because of full devices - please keep in mind how their profits are split between hardware and software/services.
I would go even further: They wouldn't even change it if it were free and easy to do. If they filtered out Retina graphics for non-Retina devices, the old iPad could hold more apps than the new one! If you upgraded to the new iPad, you would have to trim down your collection. It just doesn't make any business sense for them.
I guess everyone with a jailbreak will rejoice, this sounds like something a Perl one-liner could fix over ssh. And it could remove the builtin apps while they're at it. I am honestly jealous.
I think this is a bigger question of backwards compatibility. Surely Apple could find a technical solution to downloading Retina assets to non-Retina devices, but at the end of the day, what does this accomplish? It means that users of older devices will have a slightly better experience, at the expense of a nontrivial amount of work. Were such a scheme to be implemented, the developer would likely have to mark Retina files manually and Apple would have to add infrastructure on their servers. All this for something that will be pointless in the near future when Apple stops selling non-Retina iOS devices.
I don't mean to assert that Apple shouldn't attempt to separate out Retina assets, but I think it's worth considering the opportunity cost. There are a lot of other things Apple's engineers could be working on. Should this be their top priority?
This is the company that simply yanked out floppy drives when they decided they were no longer necessary, so it's probably not a priority at all. It doesn't directly cause breakage, and a few years down the line, Retina will be everywhere.
Retina graphics are already marked @2x. They could have implemented split bundles however Apple has never been one to maintain complete backwards compatibility. And I do agree Garage Band is obese, same as the OSX version which I had to uninstall from my MacBook Air because it took up way to much of the very limited SSD space.
I don't think we're talking about a "slightly better experience" -- this is the difference between having 20 apps and 40 apps (for example). Space is at a premium on these devices...
The comments I see are about technical solutions. I think Apple's happy that there's finally a reason for people without humongous music collections to pay $200 for 64MB of flash memory.
My cynical side agrees with you. It seems like an absurd markup, between 16GB and 64GB.
I've looked briefly into stripping an app: the ipa format is just zip. There is a plist with hashes of the assets. Don't know if that plist itself is hashed, but I'm thinking probably.
I like this author's thoughts, and there are some creative solutions offered by him and the commenters there on how to thin the assets. However, I would be interested to see how the assets' size stacks up against the actual binary.
Some of the biggest apps on my iPhone are iBooks (57.9MB) and Nook (51.3MB). I doubt their pretty little icons take up the lion's share of that size. I mean, Kindle does it in a measly 23.5MB (sarcasm, still big). I wonder, for instance, how much language support weighs in at. There was a mac program I used some years back called monolingual that would remove other languages, you know because I'll never need my laptop to work in Farsi, and thin the binary architectures. Saved many a GB when they were much more precious.
I'm assuming that most of these apps are made with some fancy service that generates an app for every platform under the sun from one app creator program, and as such, each native app is way bloated.
But, the consumers don't notice or care, so app creators are just going to be as inefficient in the interest of jamming new features into an app over optimizing it.
(edit: spelling, added parenthetical to Kindle app)
You'd be surprised: the assets take up about 50% of the total. It's simple enough to examine the contents of an IPA file:
iBooks used to be under 20MB. Over time it's expanded to its current size of 50.8MB when it's uncompressed (the extra space it's taking up on your device is probably the books themselves).
The vast majority of that is images. Apple have at least been somewhat smart about it, choosing in certain cases to use lossy JPGs rather than PNGs where the user won't notice (the startup image, for example).
The app also ships with some custom fonts, which take up a few of those MB. The languages, which you suspect take up a lot of the space, actually don't represent that much: each language is about 45KB.
The executable itself is 25MB: so basically, 50% of the app size consists of assets. The percentage is probably higher on most other apps, because the iBooks executable is rather large (unusually so).
As an app developer myself, I've (recently) just began using ImageAlpha + ImageOptim (http://pngmini.com/) to compress all my PNG images. These really do the job better than PNGCrush (Xcode's default) and cut them down to 50% of the original size without losing much quality.
From one app developer to another, if you're adding retina assets for the new iPad like me, remember to use ImageAlpha first!
P.S. If you're unsure of its advantages, check out this case study of ImageAlpha + ImageOptim used on Tweetbot: http://imageoptim.com/tweetbot.html
This is device fragmentation, like Android and Windows face. SVG might help in some cases. Apple's SDK should accept the best quality assets and resample for app versions for each device. Some apps will still benefit from targeting devices more specifically, though.
It's far from ideal, but it's a long way from the Android fragmentation (can't comment on Windows Phone, never been involved in dev for that).
With Android, there could be any one of dozens of resolutions (iOS has two basic resolutions, with a relatively simple 2x multiplier version of each of those), you could have a keyboard or not, you could be a device with a resistive screen with no multi-touch (or even no touchscreen at all), your OS version may dictate whether you can install on the SD card or not - or have one of many other significant differences - and the device may not be able to upgrade to a more up to date OS version, etc etc.
When we launched our app recently, we tested it on 3 different iOS versions (a 3GS, a 4S and an iPad 2), and about 20 different Android ones. I can't remember a single major issues that appeared on only one model of iOS device - and I can't think of any that have appeared in the wild either. On the other hand, we had dozens of "only occurs on Android device X with OS version Y".
There's a standard naming convention, iOS load [email protected] on retina and image.png on non-retina but it's not strictly enforced so apple couldn't delete all the @2x images on a non-retina device. Plenty of universal apps use the @2x iphone target images for the iPad display, for example, and this suggestion would break those apps.
As a developer, I've been more and more often leaning towards using tools like paintCode or just writing code for custom widgets instead of trying to make the 4 different images for iphone/ipad/iphone@2x/ipad@2x. This is a win/win because it looks better (except at very low res) and keeps the size of the app down.
Having the app store serve different apps for different target devices opens a can of worms. For example, if you backed up on one device and restored on another, you could get the wrong one. I think Apple made the right choice in preferring to make sure your apps work everywhere rather than save storage at the cost of complexity. And if that means they're nudging the consumer to upgrade to the lastest and greatest, I can't blame them for going that route.
I sympathize with the problem. Some of the apps on my iPhone have become bigger since they're universal and now include the retina iPad graphics. I agree with some of the other commenters here that the ideal solution would be to not download/remove the unnecessary graphics once on device.
But as I've run down on space, I've started to notice how odd various app's sizes are. There seems to be very little correlation between what I expect and the actual value. Here are some examples from my applications:
This doesn’t address the root problem, but liberal use of Imageoptim and ImageAlpha can drop file sizes for images by 50-60% in extreme cases. As a web guy when bandwidth matters I’m very familiar with these techniques, but maybe they haven’t got traction in the app world?
When creating iOS apps part of the process of transferring the app resources into the app itself involves compressing the images even further. There are ways to improve this, but at the base line you have it done for you.
So here is the big question: Are you going to buy less apps because of this "issue"? If not then there is no incentive to really fix it, nor for developers is it a problem that will be addressed.
When the same thing (at much smaller scale) happened on my Nexus One it definitely stopped me buying apps. In fact, to stay current with updates I had to start uninstalling apps I had paid for.
It will certainly make me think twice before buying new apps, yes. In some cases the app simply won't be worth the extra storage required (I'm thinking music apps in particular, since I like to play with them but don't use them seriously).
On the iPad is it possible to download an app and somehow cache it onto some other storage medium (i.e a PC or Mac HDD) so you can uninstall it, backup all your personal files and then sync it back over later (via LAN or USB)?
I ask because I was thinking of getting an iPad3 in the near future and was tempted to get the 16 GB model because I have many TBs of storage elsewhere on my PC/NAS/Servers so I'm not going to use it to archive anything long term. Plus an extra £70 for 16GB seems steep when I could get a 64GB SSD for the same.
Yes. iTunes on your desktop machine can store (and update) apps that you are not currently syncing to the device. Then, when syncing the iPad, you can check a box in iTunes to indicate that the app should be included on the device.
This isn't just in mobile apps, it happens on the desktop too; and it's a tricky problem. In general one has to blow up the size of an app to preserve a good user experience in other areas.
Consider download complexity. How many "versions" of your app would you need to have to give each user the optimal installation size? How often do you want to deal with people downloading the wrong one and having a bad experience? What about 3rd party distribution...any number of other sites may choose to offer download links and you have basically no control if they screw something up.
Another is problematic upgrades. Suppose you optimize a download for a user's current machine. Then they buy a new machine. They won't really try to understand why your app is now looking strange or misbehaving; they'll just think your app sucks.
On the Mac side I've chosen to go the oversized route. There's no doubt that my app bundle is 2-3 times as big as it ought to be (and unfortunately two thirds of the binary bloat goes towards supporting systems that few users are likely to care about at this point). But then downloads are simple: just "click here for the new version" and whatever your system you see something that works.
It does seem to me like this "space issue" is a very annoying an unethical way for Apple to automatically and slowly force people into buying newer devices with more storage (for whom the old 16GB versions were enough), and it comes as a surprise for most who start running out of space on their device and can't do anything about it. Also (and this is not Apple's fault) the new hi res photos and recorded videos contribute a lot too.
One possible solution is having apps ship with 1x graphics with an optional download to have 2x. That solution, however, is not something I would like as a developer or as an user.
Over the next few years, we'll probably go back to having just two screen sizes (Retina iPhone + iPad). This is just a side effect of the transition to retina, and it will go away soon.
Though from Apple's perspective it would make more financial sense to have you go buy a 64GB iPad. :)
Typically, when the App Store complains about lack of space to update all, you can still update them all one at a time, or do the big ones first, then, update all. That's because when you update apps, you've got two copies of an app on your device until the old version gets deleted, and when you click 'update all', it checks if you have enough space for all the apps in question to be duplicated.
[+] [-] robomartin|14 years ago|reply
As an iDevice user I am glad that I chose to buy all my devices with the absolute max storage available. Everything I have has 64GB. So, we are good for a little bit.
As a developer I cringe at the situation. I am currently working on an app that has about 400 graphics files that will ship with the app. If you do it their way you have to produce each one of these files in four different resolutions. This means that the image directory is now huge. It is three times larger than a scenario where we would have app bundles customized for each device.
In looking at the problem we decided to do the following. All of our files are produced at what would be @2X resolution but are named without the @2X. We are going to ship the app with just 400 files at a single resolution instead of 1600 files at four different resolutions. In the end, if you do the math, your app bundle will be significantly smaller due to the significant reduction in size of the images directory.
As far as performance is concerned, the images work very well all they way back to iPod touch v2.0 devices. No issues there. So, that's the plan.
Maybe what Apple is pushing all of us towards is a scenario where we are forced to detect device type and capabilities and load resources accordingly on app first run. Think about this for a moment. Now their servers don't have to push out so much content and you will have to foot the bill for your free graphics-intensive app getting three million downloads. I could be off base here. But, I just don't see a way to deal with this unless you are willing to ship your app with thousands of files, most of which will never be used by the device the app is installed on.
I also think it's high time that apple put out an iDevice with the ability to expand memory capacity in the field. I know, I know, they want to control it all. They are big enough to have custom Flash chips made with all the encryption they want so people can't move the flash chips from phone to phone and steal software.
Happy coding.
[+] [-] dasil003|14 years ago|reply
Why would they run into these realities now? Apple's been around just as long as Microsoft, and they have been pissing off their customer base with poor backwards compatibility the whole time. The scale is much larger now, I'll give you that, but the relentless forward-thinking is what has allowed Apple to get into the dominant position they are in now. Microsoft by contrast, got bogged down with the enterprise where large IT departments put them between a rock and a hard place by refusing to upgrade if they didn't support whatever byzantine legacy application infrastructure they were running. Even to this day where Microsoft realizes they need innovation, they are still forced to hedge their bets with this hybrid Windows 8 Metro crap.
Mark my words, this problem of app size is a tempest in a teapot. Given current trends, most iPads will be 3rd gen within a year, and in a couple years, the first iPad will fall off the iOS upgrade cycle. For every customer that Apple loses because they demand backward compatibility, they'll gain ten with the latest new shiny.
The reason Apple will not do anything this problem is not out of planned obsolescence or greed. All else being equal they would be happy for you to have unlimited space on your iPad. But to solve it is non-trivial and does not push their product forward. To the contrary, it adds complexity that will inevitably slow their product development, which runs directly contrary to their modus operandi.
[+] [-] Someone|14 years ago|reply
That is not sufficient. You also would have to detect the case where a backup is restored to a device with a different resolution (could even be a lower resolution)
"you will have to foot the bill for your free graphics-intensive app getting three million downloads."
Not necessarily. The App Store could have provisions for doing these kinds of downloads. Because of the backup issue, I even think it would have to have support there, given that Apple would want to prevent the cases "sorry, cheapGames.com's server is awfully slow" or "sorry, junkSite.com's server has disappeared; we cannot get you the graphics for that game you bought anymore" (site names made up; if they exist in real life, the name match is coincidental)
[+] [-] tolmasky|14 years ago|reply
[+] [-] stephengillie|14 years ago|reply
Would Apple allow an app maker to release their app for only newer iPads and iPhones, and not for the older devices? (I have no idea...)
[+] [-] hrktb|14 years ago|reply
As a matter of price, for the reasons above I am OK to pay more for an universal app than have two different ones I'll have to manage separately.
[+] [-] mrmekon|14 years ago|reply
This isn't necessarily a bad thing. There's a huge tradeoff between size of the product and development speed. We've switched to a pattern of bundling lots and lots of large libraries with everything we ship, and tons of static resources, and tons of translations, and on and on. And it makes everything huge.
But it means you "full-stack engineers" can knock out full-featured, money-making web apps in hours/days/weeks instead of weeks/months/years. Most of the "look at the monetized product I wrote this weekend!" posts that show up on HN could be a fraction of their size, but would have taken much longer to develop.
The link is specifically complaining about resource files, which are probably easier to manage than libraries, but it's still probably not worth the effort for Apple. By making it as simple as possible, developers don't waste any time worrying about how they are going to structure resource usage for their app. Just throw everything in there and get on with it.
At work, I develop for platforms with <1MB of RAM, and we can do plenty with them, but development time is ridiculous. You can knock out a full online dating site in 4 hours, eh? It takes that long to print "Hello World" on a serial port of a new microprocessor... maybe longer.
My side projects are in horribly wasteful monstrosities like Python and Objective-C/Foundation because, in my spare time, I like projects to actually get finished... to hell with binary size.
[+] [-] gurkendoktor|14 years ago|reply
I would go even further: They wouldn't even change it if it were free and easy to do. If they filtered out Retina graphics for non-Retina devices, the old iPad could hold more apps than the new one! If you upgraded to the new iPad, you would have to trim down your collection. It just doesn't make any business sense for them.
I guess everyone with a jailbreak will rejoice, this sounds like something a Perl one-liner could fix over ssh. And it could remove the builtin apps while they're at it. I am honestly jealous.
[+] [-] michael_miller|14 years ago|reply
I don't mean to assert that Apple shouldn't attempt to separate out Retina assets, but I think it's worth considering the opportunity cost. There are a lot of other things Apple's engineers could be working on. Should this be their top priority?
[+] [-] chipsy|14 years ago|reply
[+] [-] mcguire|14 years ago|reply
[+] [-] kenrikm|14 years ago|reply
[+] [-] high5ths|14 years ago|reply
[+] [-] thasmin|14 years ago|reply
[+] [-] martingordon|14 years ago|reply
[+] [-] aiscott|14 years ago|reply
I've looked briefly into stripping an app: the ipa format is just zip. There is a plist with hashes of the assets. Don't know if that plist itself is hashed, but I'm thinking probably.
[+] [-] taligent|14 years ago|reply
[+] [-] brokentone|14 years ago|reply
Some of the biggest apps on my iPhone are iBooks (57.9MB) and Nook (51.3MB). I doubt their pretty little icons take up the lion's share of that size. I mean, Kindle does it in a measly 23.5MB (sarcasm, still big). I wonder, for instance, how much language support weighs in at. There was a mac program I used some years back called monolingual that would remove other languages, you know because I'll never need my laptop to work in Farsi, and thin the binary architectures. Saved many a GB when they were much more precious.
I'm assuming that most of these apps are made with some fancy service that generates an app for every platform under the sun from one app creator program, and as such, each native app is way bloated.
But, the consumers don't notice or care, so app creators are just going to be as inefficient in the interest of jamming new features into an app over optimizing it.
(edit: spelling, added parenthetical to Kindle app)
[+] [-] objclxt|14 years ago|reply
iBooks used to be under 20MB. Over time it's expanded to its current size of 50.8MB when it's uncompressed (the extra space it's taking up on your device is probably the books themselves).
The vast majority of that is images. Apple have at least been somewhat smart about it, choosing in certain cases to use lossy JPGs rather than PNGs where the user won't notice (the startup image, for example).
The app also ships with some custom fonts, which take up a few of those MB. The languages, which you suspect take up a lot of the space, actually don't represent that much: each language is about 45KB.
The executable itself is 25MB: so basically, 50% of the app size consists of assets. The percentage is probably higher on most other apps, because the iBooks executable is rather large (unusually so).
[+] [-] icefox|14 years ago|reply
[+] [-] sidwyn|14 years ago|reply
From one app developer to another, if you're adding retina assets for the new iPad like me, remember to use ImageAlpha first!
P.S. If you're unsure of its advantages, check out this case study of ImageAlpha + ImageOptim used on Tweetbot: http://imageoptim.com/tweetbot.html
[+] [-] jfoster|14 years ago|reply
[+] [-] prof_hobart|14 years ago|reply
With Android, there could be any one of dozens of resolutions (iOS has two basic resolutions, with a relatively simple 2x multiplier version of each of those), you could have a keyboard or not, you could be a device with a resistive screen with no multi-touch (or even no touchscreen at all), your OS version may dictate whether you can install on the SD card or not - or have one of many other significant differences - and the device may not be able to upgrade to a more up to date OS version, etc etc.
When we launched our app recently, we tested it on 3 different iOS versions (a 3GS, a 4S and an iPad 2), and about 20 different Android ones. I can't remember a single major issues that appeared on only one model of iOS device - and I can't think of any that have appeared in the wild either. On the other hand, we had dozens of "only occurs on Android device X with OS version Y".
[+] [-] joeld42|14 years ago|reply
As a developer, I've been more and more often leaning towards using tools like paintCode or just writing code for custom widgets instead of trying to make the 4 different images for iphone/ipad/iphone@2x/ipad@2x. This is a win/win because it looks better (except at very low res) and keeps the size of the app down.
Having the app store serve different apps for different target devices opens a can of worms. For example, if you backed up on one device and restored on another, you could get the wrong one. I think Apple made the right choice in preferring to make sure your apps work everywhere rather than save storage at the cost of complexity. And if that means they're nudging the consumer to upgrade to the lastest and greatest, I can't blame them for going that route.
[+] [-] tibbon|14 years ago|reply
[+] [-] drewcrawford|14 years ago|reply
[+] [-] MBCook|14 years ago|reply
But as I've run down on space, I've started to notice how odd various app's sizes are. There seems to be very little correlation between what I expect and the actual value. Here are some examples from my applications:
First, some apps that have sane sizes
But many apps seem to use way more space than I would ever expect:[+] [-] robin_reala|14 years ago|reply
[+] [-] ortatherox|14 years ago|reply
[+] [-] pornel|14 years ago|reply
Most apps' size can be halved this way: http://imageoptim.com/tweetbot.html
[+] [-] icefox|14 years ago|reply
[+] [-] barrkel|14 years ago|reply
[+] [-] burnblue|14 years ago|reply
[+] [-] jiggy2011|14 years ago|reply
I ask because I was thinking of getting an iPad3 in the near future and was tempted to get the 16 GB model because I have many TBs of storage elsewhere on my PC/NAS/Servers so I'm not going to use it to archive anything long term. Plus an extra £70 for 16GB seems steep when I could get a 64GB SSD for the same.
[+] [-] noonat|14 years ago|reply
[+] [-] makecheck|14 years ago|reply
Consider download complexity. How many "versions" of your app would you need to have to give each user the optimal installation size? How often do you want to deal with people downloading the wrong one and having a bad experience? What about 3rd party distribution...any number of other sites may choose to offer download links and you have basically no control if they screw something up.
Another is problematic upgrades. Suppose you optimize a download for a user's current machine. Then they buy a new machine. They won't really try to understand why your app is now looking strange or misbehaving; they'll just think your app sucks.
On the Mac side I've chosen to go the oversized route. There's no doubt that my app bundle is 2-3 times as big as it ought to be (and unfortunately two thirds of the binary bloat goes towards supporting systems that few users are likely to care about at this point). But then downloads are simple: just "click here for the new version" and whatever your system you see something that works.
[+] [-] daniel_iversen|14 years ago|reply
[+] [-] sumukh1|14 years ago|reply
Over the next few years, we'll probably go back to having just two screen sizes (Retina iPhone + iPad). This is just a side effect of the transition to retina, and it will go away soon.
Though from Apple's perspective it would make more financial sense to have you go buy a 64GB iPad. :)
[+] [-] cbsmith|14 years ago|reply
[+] [-] WiseWeasel|14 years ago|reply