The biggest disappointment for me, from poking around the tvOS SDK docs, is that the high-fidelity microphone (which clearly must exist on the remote in order for the Siri-enabled features to work) is not accessible from a public API.
Here's hoping someone will figure out a private API for it, even if I won't be able to ship apps like that on the App Store.
On the surface that would be a security risk that is hard to quantify (how would they figure out that an app is occasionally capturing audio from someone's living room and using and/or storing or sending it in a way that it's not supposed to?). For instance it could probably be used for some evil scheme to make targeted advertising.
They might be able to open it later if they can find a way to do so, e.g. perhaps only allowing post-processed text to be returned and not raw audio, and even then only whitelisted words.
That's rather sad. Weirdly enough, the remote with a microphone is only shipping in countries with Siri support. I wonder what happens when a new country gets support - do you need to buy a new remote?
What I don't understand is why the Apple TV comes with either 32GB or 64GB of storage, but apps are limited to 200MB and I don't exactly see Apple letting you download content to the device (a la AppleTV 1st Generation). So, why all the storage?
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.
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.
The point I think is that Apple expects users to have many apps they use regularly - allowing each app to take up large amounts of space reduces the device's overall functionality.
Apps can also go over the 200MB limit by providing content 'packs' to Apple, which are downloaded on demand by your app, managed by the OS, and evicted for space when necessary.
Overall the point is to simultaneously allow as many apps to be installed as possible while requiring as little user administration as possible w.r.t. disk space.
One persistent problem on iOS is that some apps really abuse the caches directory by filling them and failing to provide some kind of cache purging functionality or logic. Users' devices get full, and policing disk usage by apps individually is a pain - both fundamentally and with the current UI. Superficially the OS has the right to purge the caches folder any time it wants, but in reality actually doing so regularly would break a large number of poorly engineered apps.
An off-the-shelf spinning-disk HDD is $50; an off-the-shelf 32GB USB stick (for a flash memory example) costs $15. It's not the size of the device, it's the cost structure and maintaining margins.
You can use them offline if your resources have already been downloaded. Otherwise, it will be like any existing app that requires downloadable content - you need to be online to download the additional content.
Apps can download an extra 2GB initially, which happens immediately after install. A further 20GB can be fetched as on-demand resources, hosted on the App Store.
The 200MB limit makes sense because it allows the OS to purge any old download-on-demand data when space starts to run out.
On-Demand resources allows you to have a total of 20GB of assets per app, of which 2GB may be in use at one time. Downloaded resources do not get purged until the device is running out of disk space.
The 200 MB is the limit for the initial bundle, so in the worst case your binary plus the assets of a loading screen. Everything else you can on-demand load.
The advantage of the 64 GB device is that you have more room before apps start to re-download assets. In my case (1 Gbit/s fiber), I'll go for the 32GB model and count on fast downloads.
Can anyone tell if he was porting an iOS or OS X game to tvOS?
This suggests it was an OS X app: "While I didn’t delve too deeply, I was able to copy over most of my code from the Invaders project verbatim, just making a few tweaks for places where the OSX APIs differed from iOS."
> First, you can click on a story's domain to see the previous HN submissions from that site.
> Second, when you're logged in, stories on /newest and on /item pages have 'past' and 'web' links. Click on 'past' to search HN for previous stories with that title. This helps with finding duplicates. Click on 'web' go to a Google search for the story title. This helps with finding better sources and catching spam.
> Finally, when a story is the first post from a site, logged-in users will see the site name in green, by analogy with the green usernames of noob accounts.
Here's hoping someone will figure out a private API for it, even if I won't be able to ship apps like that on the App Store.