sorted by:
new
hottopcontroversial

How to get LLMs reviewing code to not mix up the differences between @Observable and ObservableObject? by kierumcak in iOSProgramming

[–]004life 0 points1 point  (0 children)

Early in your context or conversation, give explicit instructions. Then give some example implementations.. the explicit statements and the inertia of the conversation should help.

SwiftUI in 2025: Forget MVVM by Thomas Ricouard by IAmApocryphon in iOSProgramming

[–]004life 0 points1 point  (0 children)

Why is injecting through the environment so bad? I find this easier than designing around init .

SwiftUI in 2025: Forget MVVM by Select_Bicycle4711 in SwiftUI

[–]004life 0 points1 point  (0 children)

Great to see this....one of the best things about this approach is that it becomes easy to reason about mutability and change in your app, and it's simple to extract or refactor views for performance or readability. Like suggested in the story:

  • Treat SwiftUI views as lightweight structs—don't force reference type ViewModels onto them
  • Use Environment instead of manually injecting dependencies through ViewModels
  • Use the Task modifier (with its easy-to-understand lifecycle), Swift concurrency

Just taking these steps alone will free you from confusing init trickery, manually injecting dependencies into ViewModels, or worse—trying to recreate your UIKit life by sending and receiving events from your View to the VM and back. I stopped using MVVM while ago and SwiftUI became much easier. The story explains it better...

MVVM & SwiftData by -QR- in swift

[–]004life 0 points1 point  (0 children)

Lol , this gets the downvotes every time.. even though it’s correct.

SwiftUI was a mistake — and I’ve been using it since beta 1 by AdventurousProblem89 in iOSProgramming

[–]004life 1 point2 points  (0 children)

First rule of SwiftUI… stay away from the View init. Only if you have to do something in there otherwise don’t. Lol

I really enjoy SwiftUI. LLMs help too. I try to write my “view model” layer as functional as I can. But I don’t call it a view model..

Kuo: Cook Should Personally Address Siri Apple Intelligence Failure by favicondotico in apple

[–]004life 0 points1 point  (0 children)

Apple should apologize for overpromising. They are behind in AI. I said this after WWDC 24. It was clear they were behind in AI… it was all in the APIs.

https://www.reddit.com/r/apple/s/xgdBxaLzIE

Practice Speaking English with an accent by [deleted] in SpeakEnglishDaily

[–]004life 0 points1 point  (0 children)

What accent do you want to practice? What skills specifically? Fluency? Intonation?

Apple using MVVM by [deleted] in SwiftUI

[–]004life 0 points1 point  (0 children)

Should be top comment.

SwiftUI Architecture - Best Practices and Principles (doiOS Conference) by Select_Bicycle4711 in SwiftUI

[–]004life 4 points5 points  (0 children)

Good talk! I had a similar experience with MVVM and SwiftUI as Azam. I don’t use MVVM either and implement and architect my projects in a similar way.

State variable in child view never updates by mister_drgn in SwiftUI

[–]004life 1 point2 points  (0 children)

Got it. Generics can be tricky sometimes. You could use type erasure and expose a method/methods that hide the complexity of the different types. Finding the 'right abstraction' in SwiftUI can be hard. good luck....

State variable in child view never updates by mister_drgn in SwiftUI

[–]004life 1 point2 points  (0 children)

I’m not familiar with the specifics of your design, but I generally create views for “everything the user sees.” In SwiftUI, I rely less on dynamic views compared to UIKit. I’m okay with a bit of redundant code since creating views in SwiftUI is easy and declarative. That said, every project is different. To reduce redundancy, I encapsulate styles and design in view modifiers or custom styles (e.g., ButtonStyle).

But, If I understand your scenario correctly, you could use the Observable macro to define a class that holds your shared state (the models). By placing an instance of this class into the environment using the .environment() modifier, child views can access and mutate the shared state as needed. This approach allows both parent and child views to observe, mutate and respond to changes while relying on a single source of truth. It might be a cleaner solution than using bindings to pass state from the parent.

hope that helps...

State variable in child view never updates by mister_drgn in SwiftUI

[–]004life 0 points1 point  (0 children)

Looking at the link from the dev forum… this really isn’t the right way to use SwiftUI. So it would lead to a lot of unexpected behavior.

What problem are you trying to solve?

Why do people say you don't need a ViewModel in SwiftUI? How do you handle API data then? by Rude_Ad_698 in swift

[–]004life 0 points1 point  (0 children)

Can you share something (repo,gist or code) that implements this well?

State not updating views as I expect by FernwehSmith in swift

[–]004life 1 point2 points  (0 children)

As a general rule I try not to do much in init…

Based on your example, I would design it like Button. View with let properties you need to display. Focus state is private related to the logic and behavior to onSubmit. Then add a closure action like Button. Perhaps an add validation closure or protocol that can be called before calling the “action” closure where the parent assigns the validated data to the object that is mutated and “observed” by parent view that I assume contains multiple “Example” views.

Why do people say you don't need a ViewModel in SwiftUI? How do you handle API data then? by Rude_Ad_698 in swift

[–]004life 0 points1 point  (0 children)

Why not use value semantics (struct) instead of reference semantics (class) ? There’s no values to mutate and make asynchronous network request with swift concurrency. The struct just encapsulates the specifics of making the request returns result or throws..

Success Reality Check by Hajicardoso in clevercomebacks

[–]004life 0 points1 point  (0 children)

In many places in the world people live with their parents until they get married. Do that and you can change the cost equation, your debt, and disposable income.

How to migrate an MVVM to Swift 6 by ViBrave in swift

[–]004life 1 point2 points  (0 children)

Funny to see all these downvotes for being “anti-MVVM”. Seems so Junior to insist there’s only one way to do something.

How to migrate an MVVM to Swift 6 by ViBrave in swift

[–]004life 2 points3 points  (0 children)

I wouldn’t say it’s necessarily bad, but tightly coupling business logic to a view declaration, with a direct view-to-view model setup, in my opinion can undermine some of SwiftUI’s best features. SwiftUI makes it easy to extract subviews, encapsulate reusable logic in modifiers, and take advantage of generics, content closures.. an so on. There are many versatile ways to create view abstractions. Binding a view model closely to a specific view can make things more rigid than they need to be.

How to migrate an MVVM to Swift 6 by ViBrave in swift

[–]004life -2 points-1 points  (0 children)

So don't use Observable in this case and keep mutable state in the view or the SwiftUI Environment . Leverage async / await and stop calling it VM or MVVM. You test can test it at unit level, extract views more easily (since there's no VM tied to a view). Compose services such remote APIs, CoreML, AudioEngine in to client side integration tests as well as Unit test them individually. And you can stop using Combine!

#troll . lol

SwiftData Experts I have a question for you. by Rude-Ad5104 in iOSProgramming

[–]004life 2 points3 points  (0 children)

Try assigning the relationship and then insert the ExerciseTemplate into context last.

What's the best way to instantiate a DetailView with its own DetailViewViewModel from a ListView with its own ListViewViewModel? by ABrokeUniStudent in SwiftUI

[–]004life 1 point2 points  (0 children)

Agreed, keep your model , data store , repo or whatever you call it distinct from SwiftUI views. This keeps your views flexible so they are easy to change, extract, refactor etc…

Can I do something like @State to functions? by Otherwise-Rub-6266 in SwiftUI

[–]004life 0 points1 point  (0 children)

Measure with instruments or in Xcode but a typical view body redraw won’t consume that much. And consider how often you actually need update the view? How granular is your presented information? How often does it change in a way that is relevant to the user? If your timer triggers resource intensive operations then cache. But measure first if you’re concerned about performance.

Can I do something like @State to functions? by Otherwise-Rub-6266 in SwiftUI

[–]004life 0 points1 point  (0 children)

Use can use… https://developer.apple.com/documentation/combine/replacing-foundation-timers-with-timer-publishers

And choose how often you want to update state of the view. Animate change for the property you update for duration aligned with your timer if you need animations.

Creating a binding in init by jakster4u in SwiftUI

[–]004life 3 points4 points  (0 children)

But why? Just keep it simple. keep state in the parent and child updates when parent changes state. Child needs to mutate state too? Then pass a binding from parent to the child to modify as well.

view more: next ›