It's up to the app developer, they get to mark notifications as time sensitive or not. So if someone decides that because a coupon is expiring soon it's "time sensitive" to ping you about it, then they can mark it as such. Hypothetically Apple could frown on this in app review, but it isn't something app reviewers are likely to be able to reliably catch.

What? This comes up in like 95% of ipv6 threads on HN (see also: ‘they should have just added an extra quad to v4 addresses’)

In this case Facebook appear to have simply ticked every possible box for data collection regardless of whether the app actually does it or not. Note you can't just get health data on iOS without asking, so people would notice if they tried. My guess is that actually figuring out what they do/don't collect was too hard, so they just said yes to everything.

It's about apps that are already written in native iOS code, which are currently using custom Material Design components (which are mostly/entirely in obj-c), and that going forward those custom Material components are going to be phased out and apps will use standard UIKit elements instead.

This tells you absolutely nothing about Google's commitment to flutter.

so you run a test where you intentionally consume more of some cohort of users' battery power (you could have several cohorts where you consume more and more power, even). and you look to see if the rate at which your app is deleted/force-quit by the cohorts with more power usage goes up. if it does then you can assume that you're overdoing the battery drain. if it doesn't then you can assume users don't really care (or don't care enough; maybe they're unhappy but your app is too important to them to delete).

why this could be useful is when you're deciding what to prioritize - if you've got data saying that users don't care about excessive battery consumption and they'll keep using the app anyway, you can argue against optimizing for battery life in future development, presumably letting your developers do things faster/more lazily. or, it could show that battery life is super important and be a valuable argument to prioritize power optimization work in the name of keeping your users from jumping ship.

personally i'd rather just presume that battery life is important and that optimizing for efficient use of our users' batteries is the right thing to do, regardless of hard data, but i'm sure there are people out there that think differently.

So, reason not to update: you like using software you've paid for.

disclaimer: googler

This can be tested. Translate shows up in your Google 'My Activity' page, so you can do some offline translations, then switch the network back on, and see if the translations show up in My Activity. Assuming you can trust the My Activity page to be complete and accurate (my opinion is you can, but i would say that)

and FTR: I've actually just tried it and offline translations do not show up in my activity so I highly doubt they're being surreptitiously uploaded.

If you're wondering why you're getting downvoted it's because this isn't true at all. I'm signed into (several) iOS google apps and my Safari browser is not signed into google.

"CTurt stressed to Ars that it would be nearly impossible for Sony to plug the hole that enables mast1c0re. That's because a version of the exploitable PS2 emulator in question is packaged with each available PS2-on-PS4 game rather than stored separately as a core part of the console operating system. [..] For physical PS2-on-PS4 discs, that means the exploit should continue to work as long as you refuse any online updates before playing. And for digital releases, even if the exploit is later patched out, there are methods to downgrade to a stored, exploitable version using proxy HTTP traffic from a local server."

so there isn't just a single PS2 emulator in the PS4/PS5's OS, it's a per-game emulator.

This is half-true, at least for the ones I tried on Apple Arcade. Example, the Castlevania game. All the stupid gem gacha bullshit addiction-driving stuff is still in the game, it's just that you no longer buy the gems, the game just absolutely throws gems at you for free while you play. But you've still got all the stupid mobile game addiction driving stuff like daily quests, 'pulls' to randomly get items, a tedious and complex system of upgrades for weapons/characters that's completely unnecessary (except it is necessary because the difficulty's tuned such that you'll never get through the game without engaging with it all), all that stuff. The Star Trek game was similar IIRC.

The games are still worse despite not wanting money, the (originally) monetization-driven game design poisons it anyway. For me this was one of the most disappointing parts of Apple Arcade, I'd thought the point was to pay for access to _quality_ games, not bullshit mobile games with the IAP hastily ripped out.

It's possible (likely, even) that parts of the design language will become more iOS-y (for example: I would bet that Material 'action sheets' disappear and get replaced with system-default ones on iOS, this has already happened on Chrome for iOS). But the material design language isn't going away.