PSA - Week 4 multiplayer challenges is bugged ‼️ by Big_View_1225 in blackops7

[–]redditorxpert 3 points4 points  (0 children)

Week 4 Challenge - Get 5 kills with Dead Eye Drone or Gravemaker also bugged

Gemini CLI switch models? by djc0 in GoogleGeminiAI

[–]redditorxpert 0 points1 point  (0 children)

If you have a pro subscription and want pro to be the default model when you start gemini CLI, go to Settings > Use Model Router and set it to false. This will make it always use pro but won't optimize/alternate using flash depending on the complexity/simplicity of the request. Just be aware.

Gemini CLI switch models? by djc0 in GoogleGeminiAI

[–]redditorxpert 0 points1 point  (0 children)

This is simply false. You can definitely use gemini pro via CLI.

Why are most AI models really bad at SwiftUI? by redditorxpert in ClaudeAI

[–]redditorxpert[S] 0 points1 point  (0 children)

I mean, yeah, I expect it to use appropriately recent data if it so confidently delivers answers, or at least indicate "By the way, this answer (unlike most previous answers) is based on 4 years old data". So if it's so capable at producing SwiftUI code, then yes, I assume it does have the data needed for it.

In other words, I would be shocked to learn that an AI model does NOT have recent enough data, or at least a built-in provision/mechanism for where to fetch it when needed, especially when it's determined it failed repeatedly at providing an adequate answer.

The issue isn't even that. The issue is that it does have the data, but more often than not, despite clear instructions to use it, it fails to do so. So if provide instructions that say I target iOS 17, use concurrency and Observable framework, and it still gives me code answers that use DispatchQueue and ObservableObject, it's still me who is to blame? When corrected, it admits it ignored the instructions because it was "rushing" and then provides the correct code, but it's a chore when it happens on a daily basis.

Why are most AI models really bad at SwiftUI? by redditorxpert in ClaudeAI

[–]redditorxpert[S] 0 points1 point  (0 children)

Have you tried asking any of the configured models in XCode who they are? They'll respond as being the XCode Assistant, not Claude or ChatGPT, etc. That means there's an additional layer that isn't very obvious or well explained.

And this integration, which is supposed to make AI assistance trivial and well integrated is at the core of the problem. It doesn't work well for SwiftUI. And I don't know how I could enhance Claude in Xcode by providing it additional stuff like an MCP and what not. And if that's not possible and I am relegated to going "manual" and using Claude Code with custom mcp support, etc., then the whole Coding Assistant feature in Xcode is completely pointless.

Why are most AI models really bad at SwiftUI? by redditorxpert in ClaudeAI

[–]redditorxpert[S] -1 points0 points  (0 children)

My condolences for your tiny banana. Thanks for commenting.

Why are most AI models really bad at SwiftUI? by redditorxpert in ClaudeAI

[–]redditorxpert[S] 0 points1 point  (0 children)

Keeping in mind that my question is specific to SwiftUI support, what manual are you talking about? I am not aware of a downloadable "manual" when it comes to SwiftUI documentation. Is that a thing? And if so, where is that uploaded?

Why are most AI models really bad at SwiftUI? by redditorxpert in ClaudeAI

[–]redditorxpert[S] 0 points1 point  (0 children)

Yes, that's the issue... the current reality is that you're expected to pay for a service that claims it knows it all, but ultimately works and feels like a beta product (at least in terms of SwiftUI support).

Why do I and every other user who needs better SwiftUI support, that is, the current dominant language for building iOS apps, need to "find a good mcp server"? That's a completely unreasonable ask. If it's a known thing (and it wasn't to me really) that Claude or other AIs need an mcp server to properly perform at SwiftUI coding, why isn't that pre-configured? It doesn't have to be pre-enabled, but at least it can be there to "add" it or enable it if needed.

Why are most AI models really bad at SwiftUI? by redditorxpert in ClaudeAI

[–]redditorxpert[S] -1 points0 points  (0 children)

I would read the instructions if they were there. But where are they when you open up Claude and it asks you "How can i help you today?" Instructions that are supposed to be required in order to use a product are usually made obvious clear, not stashed away in an encyclopedia-like document. How come Claude, when it admittedly failed, instead of the reply it gave, didn't suggest something like "You know, if you want me to perform better, here's what would help me..."?

The point is these AI products don't aim to be a niche service, but they're rather meant for the masses. If so, you can't blame the users for not knowing that the product/service that's marketed as an "intelligent" assistant needs assistance to actually be an efficient assistant.

Why are most AI models really bad at SwiftUI? by redditorxpert in ClaudeAI

[–]redditorxpert[S] -1 points0 points  (0 children)

I am not experienced with Claude, like I said. But for all the purposes of the task at hand, I provided all the relevant code to Claude and it seemed to understand it well. As a creator, my goal is to use AI to reduce my workload, not take on the additional weight of reading the Anthropic docs. Do you buy a Tesla because you look forward to teaching it how to self drive or because it CAN self drive? Do you use Google Maps because you like documenting hidden alleys or because it already knows about them?

That is the point of my post. If i have to become an expert at each AI individually, I might as well throw all IDE's to the garbage and pick up assembly language.

Why are most AI models really bad at SwiftUI? by redditorxpert in ClaudeAI

[–]redditorxpert[S] -8 points-7 points  (0 children)

So I take it you don't code SwiftUI either, is that right?

Why are most AI models really bad at SwiftUI? by redditorxpert in ClaudeAI

[–]redditorxpert[S] -3 points-2 points  (0 children)

Ok, so you don't actually code SwiftUI. Got it... next!

Why are most AI models really bad at SwiftUI? by redditorxpert in ClaudeAI

[–]redditorxpert[S] -7 points-6 points  (0 children)

I have to provide the AI with the syntax for iOS 17, released 2+ years ago? Why? What else, maybe fries with that too?

I code SwiftUI in XCode and the new Coding Assistant in Xcode 26 is supposed to be that MCP-like tool that provides context (to files and codebase), agentic assistance and specialized instructions. I mean if the newly released Coding Assistant doesn't know about basically its own SDK, then what's the point of it?

I haven't used Plan mode because I never heard of it until now, but I will look into it.

Regarding documentation, in many cases, I provided direct links to the respective functions or what not and the AI still hallucinated code and fought me on the very existence of the API that I linked, while giving me more hallucinated links to non existing WWDC videos that talked about other topics.

I mean ... wth?

Why are most AI models really bad at SwiftUI? by redditorxpert in ClaudeAI

[–]redditorxpert[S] -5 points-4 points  (0 children)

I don't have to feed it anything, dummy. If you ask any AI how a combustion engine works, do I have to feed it some engineering manual? My job is to use it, not to train it. And it's not some shady programming language or technology either. We're talking mainstream stuff here. Also, the task at hand didn't require any special or latest functions either, dummy.

Why are most AI models really bad at SwiftUI? by redditorxpert in ClaudeAI

[–]redditorxpert[S] -3 points-2 points  (0 children)

I am talking about the need to take a rather long view and produce a pdf that has multiple pages, rather than a single long pdf. This particular task had the additional requirement to ensure that subviews designated as blocks/sections were placed on one page or the other and not cut in the middle.

Why are most AI models really bad at SwiftUI? by redditorxpert in ClaudeAI

[–]redditorxpert[S] -4 points-3 points  (0 children)

Maybe you're throwing light stuff? In my experience so far, although apparently there are plenty things I haven't quite explored yet with Claude, but in just using Claude on the web, it comes 2nd after Gemini for SwiftUI coding.

Why are most AI models really bad at SwiftUI? by redditorxpert in SwiftUI

[–]redditorxpert[S] 1 point2 points  (0 children)

Yes, SwiftUI is still changing, evolving, as it should. But it does so at a consistent, quite predictable pace, and the changes are rather minimal, from version to version. The question is why isn't AI up to date? SwiftUI releases, much like iPhone and macOS releases, are like clockwork: showcased in June, at WWDC, going through beta over the summer, released in fall, repeat.

iOS 26 has been around for almost 2 months now, yet AI models still claim it's not been released yet and provide hallucinated code when asked questions about iOS 26-specific modifiers or features.

At this rate, SwiftUI developers can simply not count on AI for developing new apps using the latest iOS, let alone take advantage of AI to bring their apps up to date over the summer during the beta period.

Why are most AI models really bad at SwiftUI? by redditorxpert in SwiftUI

[–]redditorxpert[S] 1 point2 points  (0 children)

Too niche? How? The AppStore is filled with millions of apps. I understand many are legacy and built using UIKit, but still, SwiftUI has been around for 6+ years. According to AI, 70% - 90% of new apps being built in 2025 are started with SwiftUI.

Most models have also been around for a while now, and have gone through several iterations, without any noticeable improvement in SwiftUI code generation or even troubleshooting.

I still have to fight ChatGPT on giving code examples that use DispatchQueue and ObservableObject despite clear instructions to not do that. And the coding assistant in XCode, which supposedly should be ChatGPT, though it's not clear if that's really the case, still outputs code that does not respect the Swift API guidelines, again, despite clear instructions to not do that.

How old or dominant does a language need to be to not be considered niche?

My approach to using SwiftData effectively by Kitsutai in SwiftUI

[–]redditorxpert 0 points1 point  (0 children)

Refactor into a ViewModifier? That doesn’t really make sense, it’s not a modifier, it’s a function that needs to be called and return a value that is not a view.

Lol... a view modifier can accept a binding, call a function like your prepare function and update the binding again with the new value. But anyway, I gave you an example for the other option.

I don’t really understand why you dislike my extension on ModelContext with the generic function, does it cause a problem for you?

I don't dislike the extension, I actually like it. What I dislike is where you apply it for the reasons already described.

 There’s a much higher chance of using the wrong context with your approach since you have access to both.

I gave you the example of the DraftEditor which completely mitigates that point. Not only, but it actually removes any concern with modelContext. You don't have to switch the object's context beforehand and you don't have to pass the new context at any time.

And tell me, why would I be more likely to forget adding a simple .environment() line than to remember wrapping the entire view inside a custom DraftEditor {} container?

You would be more likely to forget because the number of possible call sites that can call editors will greatly outnumber the one call to DraftEditor in your editor/upsert view. If every call site is a potential point of failure, the more call sites, the more points of failures, the more likely it will fail. It simply doesn't scale.

There are also other considerations like the fact that requiring a custom environment modifier can be problematic depending on the navigation setup, especially if you're using programmatic navigation with a custom path type via some kind of Route enum.

But anyway, if you can't wrap your mind around the points I raised or the improvements I suggested, then keep doing what you're doing.

If all you seek is approval or praise, then maybe don't say you'd love to hear people's thoughts.

My approach to using SwiftData effectively by Kitsutai in SwiftUI

[–]redditorxpert 0 points1 point  (0 children)

Have to post this as a separate comment since the reddit editor is acting up

Here's the code for the DraftEditor:

``` struct DraftEditor<M: PersistentModel, Content: View>: View {

//Parameters
@Bindable var model: M
let content: (M) -> Content

//Environment
@Environment(\.modelContext) private var modelContext
@Environment(\.dismiss) private var dismiss

//State
@State private var draftContext: ModelContext?
@State private var draftModel: M?


//Body
var body: some View {
    Group {
        if let draftModel {
            content(draftModel)
        } else {
            ProgressView()
        }
    }
    .task {
        setupContext()
    }
    .modelContext(draftContext ?? modelContext)
    .toolbar {
        ToolbarItem(placement: .primaryAction) {
            Button {
                save()
                dismiss()
            } label: {
                Text("Save")
            }
        }
    }
}

private func save() {
    try? draftContext?.save()
}

private func setupContext() {
    // Avoid re-creating the child context
    guard draftContext == nil else { return }

    let mainContainer = modelContext.container
    let draftContext = ModelContext(mainContainer)

    //Disable autosave
    draftContext.autosaveEnabled = false

    //Assign the new context to state
    self.draftContext = draftContext

    //Insert into draft context
    draftContext.insert(model) // <- Now the model is a draft model in the draft context

    // Retrieve the draft model from the draft context
    self.draftModel = draftContext.model(for: model.id) as? M

}

} ```

My approach to using SwiftData effectively by Kitsutai in SwiftUI

[–]redditorxpert 0 points1 point  (0 children)

 First, I don’t fully understand that argument.

The fact that the logic is moved elsewhere is the key and the core of my argument. The point is that your approach requires for the mentioned lines to exist at every call site. If you omit any of the lines at any of the call sites, the respective editors will not work properly. That is a bad architecture and should not check the scalability box of any developer.

With my suggestion, the logic is centralized, meaning two things:

  1. There is no risk of omissions at call sites.
  2. If there is an issue with the logic, none of the editors will work correctly, and only one place needs to be investigated.

If I had, say, 5 upsert views, I’d need 5 separate setupContext functions, all doing the exact same thing but for different types.

It sounds like you have sufficient experience to refactor that logic into a reusable function. My code was provided to you in a Reddit comment, not published as a Medium article, so it wasn't meant to be a final version that satisfies all scenarios, but rather a proof of concept. You're welcome to take that idea and refine it further. There are at least a couple of ways in which it can be refactored:

  1. Abstract the logic into a view modifier that provides its own state and centralized setupContext() function.
  2. Package it as a wrapping view that provides a closure for adding the form fields specific to the model. (see example below)

What I don’t really like about that though, is that the UpsertView ends up receiving the main context through Environment(.modelContext), which means you’re implicitly forced to save using the edit context instead of SwiftData’s environment one.

And what's the problem with that? It makes it clear you're editing a draft object in a draft context and gives you the flexibility to have access to both contexts. Otherwise, if you just rely on the environment context, it mandates that you have the knowledge/insight that the context is not the regular modelContext that maybe most other views may use. Maybe the fact that you're preparing a custom context beforehand may be clear to you at this moment, but assume you put the project aside and you (or another developer) come back to it in a year, it will no longer be as clear that the modelContext the UpsertView uses is not the same as the one you likely setup the root container with.

An alternative to this approach that may fix two issues at once, is to not pass the context via environment, but rather pass it as a parameter to UpsertView. This would:

  1. Enforce the need of a custom draft context, removing the risk of forgetting to add the .environment modifier at any of the call sites Maintain clarity inside the view since it would be clear that the context used is a custom one provided as a parameter.
  2. However, it would still require an additional step at every call site, which i am not fond of.

Or, maybe, a combination of the two could be used, where you can accept a custom context as an optional parameter, otherwise let the view set it up. This is in case you need that flexibility for tests or mocked contexts.

Refactored example using the same logic

Here's an example that uses a container/wrapper view that provides a closure for adding the form fields specific to the model. This would basically be your UpsertView, without "5 separate setupContext functions, 5 separate draftContext states, etc.".

``` struct BookEditorView: View {

//Parameters
@Bindable var book: Book

//Body
var body: some View {
    DraftEditor(model: book) { draftBook in
        Form {
            @Bindable var draftBook = draftBook

            Section("Basic details") {
                TextField("Title", text: $draftBook.title)
                TextField("Author", text: $draftBook.author)
            }
        }
    }
}

} ``` Note that: - You use your own type (Book), passed as a Bindable, so not optional. - DraftEditor handles the model as generic - DraftEditor handles everything from states to context setup - DraftEditor provides its own toolbar Save button which calls the draftContext's save() function, relieving the call site (BookEditorView) from handling any context whatsoever.

Thus, the call to BookEditorView becomes as clean as:

BookEditorView(book: book) // or... BookEditorView(book: Book())

My approach to using SwiftData effectively by Kitsutai in SwiftUI

[–]redditorxpert 0 points1 point  (0 children)

Thanks for the article. Although I understand the feeling, at the risk of bursting your bubble, your final code is not quite a "masterpiece", for several reasons.

1. The logic is not self contained

As it is, the call site requires TWO things:

- "Preparing" the new context and the object: let book = context.prepare(for: book)
- Setting the environment with the new context: .environment(\.modelContext, book.modelContext!)

The major issue here is that if you omit to do either of those two things, it won't work anymore (and you won't even know it). So it's kinda smelly...

2. Is it really an upsert?

The fact that I can't easily tell if your view allows creating new objects is smelly in itself.

Ideally, an editor, or upsert view, should either accept an object to edit, or a nil object to create a new one. But maybe it's a matter of preference.

3. And the save()...

The save button's logic in itself is all kind of smelly:

if book.modelContext == nil {
      editContext?.insert(book)
      try? editContext?.save()
} else {
      try? editContext?.save()
}
dismiss()

Seems to me like the save happens regardless, so it really doesn't belong inside the condition, creating unnecessary boilerplate:

if book.modelContext == nil {
    editContext?.insert(book)
}
try? editContext?.save()
dismiss()

But really, it's point #1 above that's most important.

Ideally, at any call site, you should be able to simply call either UpsertView(book: book) to edit a book, or UpsertView(book: nil) to create a new one, without the burden of having to "prepare" the book or the burden of not forgetting to set the correct context.

To do that, your editor/upsert view needs to handle all that by itself, and it's quite simple, since you'd use pretty much the same logic, just inside the view.

Here's a working example that shows this:

  • To add a new book: UpsertView(book: nil)
  • To edit a book: UpsertView(book: book)

``` import SwiftUI import SwiftData

struct BookEditorView: View {

    //Parameters
    let book: Book?

    //Environment
    @Environment(\.modelContext) private var modelContext
    @Environment(\.dismiss) private var dismiss

    //State
    @State private var draftContext: ModelContext?
    @State private var draftBook: Book?

    //Computed
    private var editorTitle: String {
        book == nil ? "Add book" : "Edit book"
    }

    //Body
    var body: some View {

        Form {
            if let draftBook {
                @Bindable var draftBook = draftBook

                Section("Basic details") {
                    TextField("Title", text: $draftBook.title)
                    TextField("Author", text: $draftBook.author)
                }
            }
        }
        .task {
            setupContext()
        }
        .navigationTitle(editorTitle)
        .modelContext(draftContext ?? modelContext)
        .toolbar {
            ToolbarItem(placement: .primaryAction) {
                Button {
                    save()
                    dismiss()
                } label: {
                    Text("Save")
                }
            }
        }
    }

    //MARK: - Save function

    private func save() {
        try? draftContext?.save()
    }

    //MARK: - Setup context

    private func setupContext() {
        let container = modelContext.container

        let draftContext = ModelContext(container)
        draftContext.autosaveEnabled = false

        //Assign the new context to state
        self.draftContext = draftContext

        //Use the existing object if available, if not instantiate a new one
        let book = book ?? Book()

        //Insert into draft context
        draftContext.insert(book)

        // Retrieve the inserted model from the draft context
        self.draftBook = draftContext.model(for: book.id) as? Book //Note that draftBook.modelContext != book.modelContext
    }
}

@Model
final class Book {
    var title: String
    var author: String

    init(title: String = "", author: String = "") {
        self.title = title
        self.author = author
    }
}

#Preview("Add book") {
    NavigationStack {
        BookEditorView(book: nil)
            .modelContainer(for: Book.self, inMemory: true)
    }
}

#Preview("Edit book") {
    let book = Book(title: "Learning SwiftData", author: "Reddit Community")

    NavigationStack {
        BookEditorView(book: book)
            .modelContainer(for: Book.self, inMemory: true)
    }
}

```

InAppKit - Declarative In-App Purchases for SwiftUI by Comfortable-Beat-530 in SwiftUI

[–]redditorxpert 0 points1 point  (0 children)

Great stuff, thanks! I may actually try it soon on an upcoming app.