Support for 100MB APKs on Google Play

iTunes Connect is overall a bit nicer to work with (but often fails with completely incomprehensible errors, usually involving certificates and code signing). The new "app slicing" thing Apple are rolling out sounds very good. On the downside, it's a very closed system. Apple don't want you to script or automate anything, they want you to use their tools, of which some are slick and some are very rough.

Amazon's store is similar to Google Play but much worse overall. Their web app is very clunky. Good: no APK size limit, so no expansion files needed! Bad: big APKs need to be uploaded via SFTP(!??). No clever binary deltas or anything as far as I can tell, just massive uploads and downloads for everyone.

In the Humble Bundle, a lot of the work is done manually. That sounds bad but they've actually been a real pleasure to work with. It's great when you're doing a Humble release of an existing game; do a few code tweaks if necessary, upload to Dropbox and mail them a link + hash. I don't think they do anything fancy in their back-end, though (and they probably don't have enough engineering capacity to do so).

I'd be interested to hear how Steam compares.

I'm just frustrated that they're just doing tweaks, rather than any deep fixes. Obviously the platform isn't doomed, because the competitors aren't much better!

Android updates have been incremental updates for three years now.

Hmm, OK! I have seen some news articles around that, but I can't find an authoritative bit of documentation or official blog post. If you have a link handy, that'd be great.

I've observed in practice that all my test devices seem to do full downloads rather than deltas, though many of them are running older OS versions. And I'm mostly concerned about expansion files. It's possible that the APK parts use deltas at least some of the time, though again, in my spot checks that doesn't seem to be the case.

why can't the developer do it, but also why does the developer have to do it?

What I'm envisaging is, the developer builds APK version 2 locally. They send a v1 -> v2 patch to the Play Store (which already has the master copy of APK v1). Use checksums to ensure it's all working as expected, and in the worst case fall back to a full upload of v2.

Maybe from Google's point of view it isn't worth spending any engineering effort to help developers who don't have access to really fast uploads. But it's not rocket science and it sure would be nice.

A bug regarding expansion files...what is the point of even linking that?

I think it's relevant because their recommended method of shipping a really big app is to put resource data into an OBB (a virtual filesystem), but the tools for building an OBB don't actually work reliably. Worse still, Android itself can't mount an OBB reliably! So if you care about stability and/or supporting a decent range of OS versions, you can't use OBBs at all. You have to use a zipfile or something as your expansion file, and manage it yourself. Not a huge deal, but it's more work, and it all contributes that little bit more to the bloat many people complain about.

It seems like in practice expansion files never use deltas, and (as far as I can tell) APKs generally don't either. I could be wrong about the APKs, or maybe my updates are always big because I'm using native code.

[Edit to add: my paranoid theory is that they pre-announced this, but then never properly shipped it. But I'd love to be proven wrong!]

[Edit edit: OK, it sounds like APKs already get deltas and it all just works invisibly. But I don't think expansion files get deltas.]

It's not as if one of the major use-cases is to copy APKs between devices with different architectures and have them work easily, and I'm pretty sure it should be possible to implement something that detects which one the device is before downloading, so how did this situation occur?

On iOS, for example, you include a startup image for each screen size / orientation. That could be a dozen or so full-screen images!

Unless the images are truly very different (and I don't see why they would be), isn't it possible to just include the highest resolution images and resize if necessary?

Modern "flat" UI images ought to compress much better, though...

If anything, "flat" UI means there shouldn't be a need to store much in the way of imagery - they can be procedurally generated very compactly in the code itself, or stored in some sort of vector format (even better) - but then again, I've seen people use huge solid colour bitmap images for UI elements in other (desktop) apps.

Libraries/frameworks are slightly more tricky but once again, there already is a solution: identify them as dependencies by something like a hash, and don't download if they already exist. You may end up with multiple versions of the same "module", but at least you won't get multiple copies of the exact same one.

I'm really astounded that such wasteful practices are prevalant in the mobile device world, where bandwidth and storage are far more constrained than for desktops. It's almost as if they deliberately chose the most bloated way to do everything...

Doing the work to split packages up into different architectures helps a lot (if you use a bunch of native code), but then you have to deal with the fallout of people downloading from google play for their device, and then posting the slim binary on the web that other people with different devices are going to download and install to incompatible phones.