So now that Tim Cook is gone will we see John Ternus actually apply some braincells to this?

They’re just going to keep losing. And every time they fight they make it worse. They had a chance to get off way easier years ago. They destroyed it by fighting tooth and nail.

I don’t want any of those features myself, I don’t think. Small chance at side-loading.

But everyone, even diehard Apple pundits, realized long ago this was a very stupid hill to die on.

Does this grant any of that?

Nope. Apple already allows local AI model running in apps on the App Store.

What’s the point of running ACR on first party app content? It’s first party. You should already know that data.

Good for LG for actually honoring the opt out. Same with Sony/Google and a few others.

My TV isn’t on my network, but it’s nice to know some do behave. For now.

This is meaningless. People go online to complain about problems. Very few people are going to show up to say “it’s OK I guess”.

Without accounting for that you can’t draw any conclusions.

Could you e plain the issue for a non-rustacean?

The Rust toolchain by default produces a lot of debug information for each crate being compiled and the language relies heavily on monomorphization (instantiating a different function/type for each combination of generics) which translates to generally having duplicated functionality where the only difference in the object code is the different types. These two things combined, along with large dependency trees and that "features" for conditional compilation cause the same crate to be considered different across different workspaces (meaning the rlibs that were created for one can't be reused for another), means that the target directory for Rust projects can quickly grow. That, + clippy not having stabilized an already implemented process to automatically delete files from the target directory when they are unlikely to be needed again (which can't be 100% accurate, it uses heuristics because a developer could always potentially need an exact rlib from 6 months ago, it is just unlikely) means that you can expect that under the default configuration your target directory ends up being huge after a short period of time.

A lot of those things are in different stages of being fixed. I would personally want the default for generated debug information to be changed. cargo gc will help with running out of disk space. Better cross-project reuse of existing rlibs could be accomplished with some better tracking of optional features that can be unified (think having `serde` with feature `derive` enabled in one project, and having it without it in another: features are supposed to be purely additive, so you could reuse the earlier rlib on the later, but in practice people (ab?)use features in non-additive ways so it isn't straighforward to do something like that by default). Tools like hakari lets you create workspace-unified Cargo.toml to emulate this behavior.

Woah, this is great to know. Thanks for explaining!

Oooh. “CHI and the Family Stone” is perfect.

Is this significantly useful to anyone?

It’s a neat accomplishment. And it was worth doing for that alone. Absolutely hacker worthy.

But as someone with an Apple Silicon Mac, I can run iOS apps on my computer if the developer has allowed it and I don’t. I’ve never come up with an actual need. It turns out it’s never really a problem for me.

The few things I use a lot on my phone already have desktop equivalents. The long tail stuff tends to be stuffed that I wouldn’t really use from my computer anyway. Like locking my car or using a banking app. One I don’t need, the other is already covered by the website.

So I’m wondering if anyone has found a strong use for this kind of tools.

What about that chinese cat feeder whose app requires a suspicious number of permissions, and requires max version of android 2 versions behind the current one?

Or maybe your security camera has a "free" plan without motion detection, and you just keep the app running with a screen grab on top to do your own AI motion detection.

Or my eero router, which doesn't have a web interface... etc etc.

There's a million cheap hardware gadgets that are going to lose sw support at some time, and stop being functional. This will help a lot with that.

Then I can probably vibecode a native reverse-engineered solution to both those specific problems in less effort than it took to vibecode an Android translator for Mac.

Perhaps you don't want to waste your time or tokens or whatever REing a thing and instead can use something someone else has distributed to solve the problem in a general way

>What about that chinese cat feeder whose app requires a suspicious number of permissions, and requires max version of android 2 versions behind the current one?

Did you read the project page? This runs with no sandbox. If you want to run shady chinese apps, you should be running it in android emulator (a VM), not this translation layer.

As someone who develops iOS and Android apps, I run production, store-installed variants on my Mac all the time for iOS apps. It's pretty nice and would be cool if I could do the same for Android.

>It's pretty nice and would be cool if I could do the same for Android.

android emulator?

If I could I would do it during development. The app I work on needs hardware so it’s not an option.

For me, the main use would be any app where I would like to type a decent amount.

I hate typing on non-physical keyboards.

I’m so glad they made that change. So much better than the old days.

I love Java and I’m so glad it’s kept improving so much despite all the turmoil in its ownership.

Election coming. Gotta gin up support. And if you forget later or it mysteriously falls to the bottom of your priority list so be it.

Also announcements of future announcements is trendy. Companies do it all the time.

So we have decided as a society, it seems. No one ever said policy had to be coherent.