Andrew Oliver (via Hacker News):
Applets are officially, completely removed from Java 26, coming in March of 2026. This brings to an official end the era of applets, which began in 1996. However, for years it has been possible to build modern, interactive web pages in Java without needing applets or plugins. TeaVM provides fast, performant, and lightweight tooling to transpile Java to run natively in the browser.
Previously:
The app is real, finished, tested, documented, and ready for submission.
All I needed was to join the Apple Developer Program.
[…]
When you want to publish an app on the App Store, the process is supposed to be simple: you sign in with your Apple ID, fill in your details, pay €99, and you’re in.
Except step 2 silently rejects me.
He contacted Apple Support:
And I was told, literally, that I cannot join, they will not tell me why, and there is nothing I can do.
[…]
After exhausting all normal support routes, I filed a formal GDPR request asking Apple for access to the data used in the automated decision that blocks my enrollment.
But he still didn’t get anything useful. Without sideloading, that means there’s no way to distribute the app.
Previously:
A few times now I’ve accidentally replaced a password that might have still been valid.
I’d like to be able to look through historical passwords for a site. It can be well-buried behind an option-click or something. Ideally they have timestamps of when they were valid too because why not, it’s a small amount of data.
1Password and PasswordWallet do this automatically, and I think it’s a great feature. It turns out that Passwords.app added it in macOS Tahoe and iOS 26, but I don’t think the user interface makes this very clear. The View History button doesn’t show up until after you’ve already changed the password, and it’s below the (possibly very long) Notes, rather than up next to the Modified date. So, when browsing all my old passwords, none of them show the button. When changing a password, it’s not until after you’ve defensively pasted the old one into the Notes (or not) that you find out there’s a rescue feature for the data loss that might have occurred.
And, as Marc Edwards reports, Apple missed a great opportunity to use the history:
It’s pretty easy to get Apple Passwords to lose data.
Create a new item with a password of “a”. Sync to two devices. Turn off internet on both devices. Set the password to “b” on one device, and “c” on the other device. Turn on internet. The conflict gets resolved silently. “b” might win, or “c” might win, probably based which changed most recently.
Apple Passwords has password history, but the discarded data wasn’t in my history.
[…]
iCloud Drive also silently resolves conflicts using a similar method, potentially destroying data. The same test can be used. Dropbox, Tresorit and other cloud storage services keep timestanped copies of files when it’s not obvious which version is the latest.
See also: Mac Power Users for discussion of other features people are interested in before switching.
Apple could ultimately have to pay up to an estimated 637 million euros to address the damage suffered by 14 million iPhone and iPad users in the Netherlands.
The lawsuit dates back to 2022, when two Dutch consumer foundations (Right to Consumer Justice and App Store Claims) accused Apple of abusing its dominant market position and charging developers excessive fees. The lawsuit was filed on behalf of Dutch iPhone and iPad users, and it claimed that Apple’s 30 percent commission inflated prices for apps and in-app purchases.
[…]
The civil App Store fee case that Apple is now facing in the Netherlands is separate from the dating app case that was levied against Apple by ACM, the Dutch competition authority.
Previously:
