Hands-on with the tvOS SDK
telliott.io
telliott.io
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.
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.
Though it might be weird having to explicitly read and grant permissions to a TV app.
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.
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.
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.
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.
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.
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.
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!)
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."
Is this a new feature?
https://news.ycombinator.com/item?id=10223645
> 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.
And to the downvoters too.