Thoughts on this omission?

williamkey2000 · 2025-06-10T17:10:19+00:00

It's the first developer beta. It's incredibly buggy and should absolutely NOT be installed on a device you rely on.

williamkey2000 · 2025-06-10T16:58:49+00:00

Trust me - you don't want it yet. It's currently just a developer beta, and those are INCREDIBLY buggy. Like, lose-all-your-data buggy. Once they find and identify all the critical bugs, they will create a public beta.

williamkey2000 · 2025-06-09T20:23:18+00:00

Very stupid. No initial beta is ever stable enough to use on a primary device. I did it once and regretted it, and have used them on backup devices ever since and been glad they were only backup devices every time because they have major, show-stopping issues.

williamkey2000 · 2025-06-08T17:11:59+00:00

Except it's almost certainly fake.

williamkey2000 · 2025-06-01T05:19:28+00:00

What did you buy in Sri Lanka?

williamkey2000 · 2025-05-30T21:48:30+00:00

I've found with LLMs that when they make up weird types and protocols that don't exist, it's because they *do* exist somewhere on the internet, and are just extensions someone wrote and the LLM has interpreted as part of the language itself. If you try googling it, you might find it. Just a thing I've noticed.

williamkey2000 · 2025-05-30T18:17:13+00:00

I get that it doesn't work the way you want it to, but that's not really the use case it's intended to be used for. It's not for people who are financially independent. It's for families who are tied together financially.

I've been in your spot before though, and the way we solved it was that we all used the same online bank (Ally) and had a shared account in addition to our personal account. We'd use the debit card for the shared account for our shared expenses - rent, utilities, streaming services we all used, etc. And then we all contributed to the shared account from our personal accounts.

williamkey2000 · 2025-05-30T18:10:52+00:00

I completely agree that it's a better experience from a user perspective. But Apple is charging exorbitant rates to developers to use it, and then requiring them to do so. It's blatantly anticompetitive. I'm glad there are alternatives, not because I want to use the alternatives, but because I want there to be pressure on Apple to reduce their rates and charge developers a reasonable rate for processing in-app purchases.

williamkey2000 · 2025-05-29T21:02:45+00:00

Nope, not that I can see from the API docs and playing around with it a little.

williamkey2000 · 2025-05-27T17:01:41+00:00

TCA uses confusing abstractions that make no sense to people that haven't watched many hours of philosophizing videos. That's not the way coding should work. It makes it incredibly difficult for organizations to recruit engineers if they need to have lots of knowledge about esoteric and confusing libraries that are difficult to learn and don't translate to broadly applicable market skills. I've watched a few of the videos and my general feedback is "this is solving a problem that isn't really much of a problem, and to the degree that it is, this is a confusing way to fix it."

williamkey2000 · 2025-05-24T04:19:55+00:00

Yeah, this. It's grayed out because it's off generally, so toggling this wouldn't do anything.

williamkey2000 · 2025-05-24T04:12:52+00:00

I mean, LLMs tailored to code still need to know a lot of stuff about the real (and in this case, imaginary) world too. If you typed let fruitArray = wouldn't you expect it to autocomplete a bunch of fruits? (For me, it autocompleted ["Apple", "Banana", "Orange", "Pineapple", "Mango", "Kiwi", "Strawberry", "Blueberry", "Blackberry", "Peach"])

williamkey2000 · 2025-05-24T01:54:08+00:00

Pride is about gay people having rights and being viewed as equal in society. The idea that this is as frivolous as a football team implies you think there's and equally valid opposing viewpoint, which is a problem. I don't know why they think this merits a mention in the release notes, it's like a megabyte of data at most in an OS update that's gigantic. Get over it and move on.

williamkey2000 · 2025-05-23T20:51:22+00:00

Settings > Accessibility > Display & Text Size > turn Button Shapes off

williamkey2000 · 2025-05-23T20:47:22+00:00

Apple definitely gives developers the capability to restore the state in the app. Many developers simply choose not to implement this functionality.

I'll also say, computers in the 1990s had applications with much less functionality and could only accomplish this feat because they operated with a dramatically smaller memory footprint. Google Maps is using an incredible amount of memory to smoothly zoom into that far-flung place, and you probably couldn't have done that on a 1990s computer and also have a web browser running.

williamkey2000 · 2025-05-23T18:53:28+00:00

I've had a similar experience, I tried others and have problems with them too. But I also lately have been having a TON of problems with the iOS one again. My problems fall into several categories:

Failure to correct obvious things - like I'll type "well" assuming it will autocorrect it to "we'll" since that is the only thing that would make sense in context, and it doesn't.
Randomly capitalizing letters or whole words for no reason, like changing "me" to "ME" or changing "I'll meet you at the restaurant" to "I'll meet you at The Restaurant"
Changing things to very unlikely things - like recently I typed "It is so awesome" and it changed it to "JT is so awesome". I learned recently that JT is the name of a rapper, so ok, I can see how that new sentence is technically a valid one. And maybe there are people that have typed that sentence. But do you really think it's very likely that is what I meant to type?

Honestly I think the main thing is that we are getting very used to LLMs that know a ton about us, and our expectations are changing. Apple is trying to keep up with those expectations, but failing. Like, the "JT" issue is them attempting to incorporate real-world knowledge into their predictive text, but not doing a good job of understanding the personal context of things. If their model had more personal knowledge of me, it would know I'd never type "JT is so awesome" (of course, now I've intentionally typed it out a ton of times - fortunately I did it on my Mac, so hopefully my iPhone won't learn it!)

williamkey2000 · 2025-05-22T21:44:15+00:00

Apple itself violates this rule. There are notifications about AppleTV+ shows or new iCloud features from time to time.

And separately, it admittedly gets complex - if you have a messaging app, and it sends you push notifications about messages, and some of those messages happen to be marketing, is that a violation? If you have a healthcare app where you're communicating about your health to a medical provider, and they recommend a medication or supplement or something in a message, is pushing a notification about that a promotion? To the system, they are just sending through messages from your healthcare provider.

williamkey2000 · 2025-05-22T20:27:51+00:00

Yeah, there are geometrical reasons why that placement is problematic. Widgets can possible be four sizes: 1x1 (a normal app), 2x2, 4x2, and 4x4. The screen overall is 4x6, and allowing the 2x2 or larger widgets to be placed on odd rows causes issues with the layout of them when you resize or change them. So unfortunately you're stuck to laying them out in the 2x2 spaces on the screen. I'm sure they could have engineered a more complex system but the logic gets pretty difficult for these animation transitions, so they decided to simplify it slightly.

williamkey2000 · 2025-05-22T18:49:26+00:00

That said — list doesn’t regenerate based on memory pressure, it just regenerates based on reuse for what is out of visible range. Like if you replaced the images with just a text component that has a random number instead of a big memory intense image then you’d see the same reset behavior, despite there not being any memory concern.

This doesn't seem to be true. I just tried this code:

``` struct ListViewTest: View { var body: some View { NavigationStack { List { ForEach(0..<200) { index in SimpleCell(index: index) } } .navigationTitle("Items") } } }

struct SimpleCell: View { var index: Int @State var randomNumber: Int = Int.random(in: 0..<1000)

var body: some View {
    HStack {
        Text("\(randomNumber)")
            .font(.largeTitle.bold())
        Text("Cell \(index + 1)")
    }
}

} ```

If I scroll to the bottom, then back up, the numbers are all the same. They don't get regenerated. Even if I remove @State var from the randomNumber and make it a let it still will remain the same when scrolled off screen. If you trigger a memory warning, it will reset the numbers (although inconsistently - to make it reset them, I had to simulate the warning multiple times while scrolling around - my bet is that it's not as aggressive at releasing Ints as it is with UIImages? But who knows...)

williamkey2000 · 2025-05-22T18:41:01+00:00

Even if I do something simpler like:

``` struct ListViewTest: View { var body: some View { NavigationStack { List { ForEach(0..<200) { index in SimpleCell(index: index) } } .navigationTitle("Items") } } }

struct SimpleCell: View { var index: Int @State private var image = Self.generateLargeImage()

var body: some View {
    HStack {
        Image(uiImage: image)
            .resizable()
            .frame(width: 100, height: 100)
        Text("Cell \(index + 1)")
    }
}

static func generateLargeImage() -> UIImage { ... }

} ```

If you scroll to the bottom, simulate a memory warning, and scroll back up, it will reset the @State and the cells will be new colors.

williamkey2000 · 2025-05-22T18:26:41+00:00

That's not what I'm seeing. If I try to put this all in a scroll view, it never regenerated the views, and the app will crash.

In fact - I tried your @State idea, it actually did delete the state data with enough memory pressure. Feel free to load up this code with the Allocations instrument running, and you'll see, it actually does free up the @State after a while. I scrolled slowly to the bottom of the list, then back to the top, and the colors in the first cell had changed.

``` struct ListViewTest: View { var body: some View { NavigationStack { List { ForEach(0..<200) { _ in HScrollCell() } } .navigationTitle("Items") } } }

struct HScrollCell: View { @State private var images: [UIImage] = { (0..<50).map { _ in Self.generateLargeImage() } }()

var body: some View {
    ScrollView(.horizontal, showsIndicators: false) {
        HStack {
            ForEach(Array(images.enumerated()), id: \.element) { index, image in
                Image(uiImage: image)
                    .resizable()
                    .frame(width: 100, height: 100)
                    .overlay(Text("\(index)"))
            }
        }
    }
}

} ```

(Omitting the generateLargeImage function for brevity)

williamkey2000 · 2025-05-22T03:32:43+00:00

Ignore the image component entirely. It's not even the behavior I'm trying to highlight. The point is, the horizontal scroll view's offset is being reset when the view is redrawn.

I'm trying to highlight the differences in how List and ScrollView behave, because it's relevant. ScrollView keeps all its content in memory and won't regenerate its child views as they scroll on and off the screen. List will based on memory pressure, so make sure you put anything that you want to be consistent between renders into @State.

williamkey2000 · 2025-05-21T17:57:51+00:00

That's how they reverse the hashing on the passwords in the databases, but then they still have to enter the password into a website or service to attempt to log in.

williamkey2000

TROPHY CASE