Hacker News Reader

Comment by osxrand | Hacker News Reader

It is o my the initial download that is limited to 200MB, once launched the app can then download another 2GB right away. You can have another 2GB on the device, and up to 20GB in the cloud. So 4.2GB on the device at once per game and all the slices in the cloud. So common content in the initial 2.2GB and the rest in the swappable chunks.

I'm guessing this is for a few reasons, one would be to get debs into the habit of creating these downloadable slices for something down the track. But that's just a guess.

Another would be that the game is downloaded really quickly, from the end users point of view, and able to begin being played really quickly, without having to wait for 4-20gb to download first, then realize you've run into storage issues and have to deal with them. Common files and first level or two while the next 10 are on their way down. Seems like a decent plan for a fast user experience, if that's why they are doing it.

View on HN

On the other hand it seems like a very bad plan for the available bandwidth in my region.

I have to deal with a 1 Mbps (yes, Megabit) DSL connection and while I'm grudgindly fine with running large downloads overnight, the trend towards streaming is a huge issue. My only other alternative is a metered LTE plan - 15 GB for ca. 50€, after that the bandwidth is throttled to 384 kbps or you can pay 10€ for every additional 5 GB of bandwidth.

Oh, by the way, this is in Germany - not some exotic third world country.

The problem is that most game developers are probably not writing SpriteKit/SceneKit games in Swift, but rather using Unity or some other kind of portable engine. Now they all have to wait for their toolchain to catch up with Apple's app thinning mechanisms.

After the complete failure of MFi controllers on iOS 7+, I hoped that Apple would make life easier for game developers, not harder. Now we have a 200 MB app limit plus the requirement that games have to work with the default remote.

My own take in MFi controllers is that they were always intended to primarily be used with the new Apple TV. Supporting them early was just a Trojan Horse to get them in the stores in advance of the TV launch.

The alternative to requiring thinning is to allow fat app downloads and pretty much guarantee that app thinning stays a niche capability with low adoption, so Apple is making sure devs and their tools vendors just have to suck it up. It also means developers of apps that can conceivably fit inside the 200mb limit will work their buts off to make sure it does, which will tend to improve download speeds.

Both effects will lead to a better user experience at the cost of some developer inconvenience, but frankly they're not asking anything unreasonable. Apple provide support for app thinning in their own frameworks, and if devs still freely choose to use different tools then that's up to them but a professional tool or framework that doesn't support thin apps in this era isn't worthy of the name.

> My own take in MFi controllers is that they were always intended to primarily be used with the new Apple TV.

Then Apple shouldn't have allowed Lightning-connected game controllers. I bought one for development purposes when their price dropped from $99 to "let's clear this shelf" ($15 in my case), and not only can I not use it with an Apple TV, it's also a terrible controller, on par with a $10 USB gamepad.

I agree that tvOS was probably the driving force behind MFi controller support, but I also think it was a complete failure. (Sadly!)

The on demand resources allow the OS to efficiently store only the resources that are needed. As you play through a game with 100 levels, the system can delete assets from earlier levels to make room for new assets for later levels. Effectively this makes it less likely that a user will delete your game as storage fills up. More work, but ultimately good for game developers on the platform.

Yes, the existence of on-demand resources is a good thing for game developers. No doubt about that! But forcing developers to use them after 200 MB is a hindrance, no matter which way you slice it.

Reply on news.ycombinator.com