darren_

> Google employs _engineers_ to figure out the truth.

and people say hacker news has no sense of humour

> Can't imagine using MTG to learn a language.

Note that he's starting from N2 Japanese, which is already a high level of Japanese proficiency (although it does not test writing/speaking at all, so it's very feasible to have N2 yet be terrible at conversation). He's not exactly learning hiragana from M:TG.

The M:TG competitions are giving him a framework to practice that conversation, which believe it or not can be hard to come by in Tokyo without deliberate effort (see 'expat bubble'). The vocab/grammar on the cards is mostly incidental to all that. If he was playing online M:TG in Japanese he wouldn't be getting anywhere near the payoff.

No, it's an affectation.

Both of these only apply for US citizens or permanent residents so no, it's not just about paying some amount of money to avoid the theatre.

This site works fine in safari/mobile safari, it is not ‘chromium only’

> if I turn off Lock Screen notifications and turn on time sensitive notifications then will I get no marketing notifications, and only notifications about my driver turning up?

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.

> Something that isn't talked much about IPv6 and I believe has subtle and indirect influence on it's adoption is that it is far far far less human-readable than IPv4

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’)

You can still backup iPhones to your desktop instead of iCloud. At least for now.

Here's exactly what it means: Someone at Facebook, when creating the listing for the Threads app on the appstore, told Apple that the app might possibly collect Health data (etc). These labels are entirely based on self reporting by the person doing the upload. That's it, that's the entirety of what these privacy label things mean: the company making the app has made these claims about what it collects.

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.

This link says absolutely nothing about Flutter usage.

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.

i don't find it too compelling, but this test could potentially help you understand, to some degree, how important battery consumption of an app actually is to users.

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.

I’ve seen arguments that dark mode is important for accessibility, which seems reasonable to me, and depending on the company might be a dealbreaker.

I've mentioned this in another comment but: this update will permanently disable any 32 bit iOS apps you have on your device with no recourse or downgrade possible.

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

This upgrade will break any 32 bit iOS apps you might have on your device, and you have absolutely no recourse and downgrading is not permitted. I've lost access to several _paid_ apps due to this.

> GP’s question was whether the app will still save your queries and submit them once a connection becomes available just to scratch that data collection itch.

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.

> It turns out that there is no way to sign into the Google Keep app without also signing into Google in Safari!

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.

There's one major reason to care - the AppStore has a threshold (200MB i think) over which it will warn users about the app's size if they are on cellular connection (IIRC it used to block downloads entirely). So there's a fair bit of incentive to stay under 200MB.

The ars technica article about this has some additional info from the hacker about sony not really being able to do this:

"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.

> Apple Arcade is a good example of this. With the subscription, they have a bunch of games which used to be gem games, but had that part of the monetization removed. And all of the games are better for it - they removed a lot of the frustration, gambling, unnecessary delays, which had been added to push people to buy gems.

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.

This is iOS, right now, and that's a fairly substantial number of users. It's not ideal but we also aren't hearing regular reports of iOS users being compromised en masse despite their browser monoculture.

No it isn't. It's a bug that web browsers had FTP support in the first place - that's the job of FTP clients, browsers should just be handing off the link to one of them. cf the 'mailto' URI scheme - I think we've all come around to agreeing that web browsers shouldn't also be email clients.

Yes, the blogpost (and most of the HN comments here) are completely missing the point. This is just about deprecating a library for implementing material design on iOS, not deprecating the design language itself.

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.

Nope. You can see a preview of what Jeff's talking about with iOS Chrome, which has already done its own iOS-ification (de-materialization?)

Also, the existing MDC components are already built on top of UIKit - things like MDCButton is a UIButton subclass (with a lot of stuff added on). Same for textfields, collectionview cells, etc. There's no from scratch reimplementation of Apple's UI components that I'm aware of, just extensions to make the Material design stuff happen.

> You can avoid that with precheck.

No I can't, I was born in the wrong country and therefore may never be trusted enough to fly unmolested in America.

I don't see what's not to understand or what logging out has to do with it. I have a browser tab for an IM application, that's also available as a native app on my phone. That tab is always open on my desktop. If I have other tabs open and am doing stuff, I still want my IM status to be 'available', and I want all notifications about new chats to go to that tab and to no other devices, while I am on my computer doing stuff.

If I go out for a walk or I go watch some TV or otherwise stop using my computer, depending on the chat app I want to either automatically be 'unavailable' (for work chat app), or I want to stay 'available' but have notifications go to my phone instead of the chat tab (for friends' chat apps).

But this isn't adequate for the IM use case at all? I spend the bulk of my time not focused on my chat app tab(s) but I definitely want to be reported as 'available' by those chat apps, because I am if someone messages me.

NZer, have never heard anything about not using thumbs-up for hitchhiking.

I also can't imagine anyone (at least in NZ), who would be otherwise inclined to give you a ride, somehow getting irate about it either.

Strong disagree, if you like BoTW and are looking for similar you might get tricked into liking it for a bit until you notice how incredibly lackluster it is both at being BoTW (and at being interesting otherwise). The lack of emergent mechanics is a huge deal, but even the basic exploration sucks. Mondstadt is an utterly forgettable area (OK, the town is kind of fine, but the surrounding countryside is samey and unremarkable), and while Liyue is more interesting, it's mechanically awful as suddenly the verticality of the scenery increases massively so now your 'gameplay' consists of micromanaging your stamina meter as you tediously scale mountains. I quit before the new area so maybe it's better, I suppose?

And the non-BoTW elements are bad too. The 'strategic' choices in combat involve knowing what you're going to fight, matching your elements to that as best you can (oh, by the way, the two guaranteed free fire element characters are awful at actually delivering fire damage, so hope you gacha-ed one of the good ones if you need fire element). Where's the interesting strategy there? And then the actual fight is just spamming your attacks and rapid-fire switching characters so the elemental effects stack. Also, quite likely you're fighting a boss design that is literally a cube (there are multiple of these).

The 'meta-game' is knowing which bosses/domains/whatever you're going to grind x times today to maximise the chances of dropping one of the hundreds of materials you need to level up whichever character/weapon/skill you're targeting at this point. It's not exactly complex, the game tells you what drops you can expect. It's just a tedious grind, and it's cynically designed to keep you coming back to the game day after day (for people who haven't played: you can only grind these bosses/domains x times per day, and it doesn't take long before grinding up the materials you need to level up something requires multiple days of this grind. You can, of course, pay IRL money to grind a few more times in a given day. Oh, and you can only grind certain things on certain days of the week. So monday you're grinding for a weapon upgrade, tuesday for a skill upgrade, etc. It's incredibly obvious manipulation.)

And then after all that, the game levels up the world as you progress. You start out the game hitting level 10 hillichurls with your sword 5 times to kill them. After hours of playtime and leveling up and forging advanced weapons, you're now hitting level 60 hillichurls with your sword 5 times to kill them. Wow!

> How is implementing dark mode even remotely comparable to launching a new general purpose CPU and transitioning an entire product line from one CPU to another?? Is changing the color on a web site that hard?

They're definitely not comparable, but having been involved in implementing dark mode for an iOS app (the quote you're reffing is talking about the mobile app, not website): Yes, implementing dark mode for at least an iOS app can be surprisingly challenging (or at least, a lot of work). It's probably much easier to write a brand new dark-mode supporting app, but retro-fitting it onto an existing app is a whole other thing.

Your designers need to re-colour the entire UI (and this turns out not to mean just "Map colour X to colour Y" btw), you need to cope with on-the-fly switching (iOS devices can be configured to switch dark mode setting automatically at sunrise/sunset), anywhere you're doing custom drawing needs to have dark mode retrofitted into it, and if you're getting imagery from a backend anywhere you'll probably need to add support for getting both light/dark mode images at once (which of course also means you need to re-draw all that imagery for dark mode as well). There's bound to be more stuff I'm forgetting.

So yeah, dark mode for an app can be a bit of work, it's not just swapping colours.

> and I dare say most things (services, devices, etc) aren't even tested against IPv6.

literally every single iOS app is required to fully support ipv6 and will not pass apple review if it doesn't.