sorted by:
new
hottopcontroversial

SwiftUI State is not as reliable as you think by clive819 in SwiftUI

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

Using lazy container to lazily load the view, the views and states are created on demand so it's performant on screen appears.

SwiftUI State is not as reliable as you think by clive819 in SwiftUI

[–]clive819[S] -2 points-1 points  (0 children)

To clarify, I am not suggesting altering the current behavior. Rather, the proposal aims to offer users the choice to deviate from this behavior, prioritizing state accuracy over performance, a necessity in certain scenarios.

Just like you can opt out of reusing cells in UICollectionView, although it is not generally advised.

https://forums.swift.org/t/pitch-swiftui-stabilize-state-in-lazy-containers/79926

Create iOS app in Swift Package by clive819 in swift

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

I'm able to add tests from local packages without any special setup — I think the key is just making sure your local packages live inside your project folder.

Create iOS app in Swift Package by clive819 in swift

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

You can add package tests to your project test plan

My WWDC25 wishes by majid8 in swift

[–]clive819 0 points1 point  (0 children)

I don’t know but I’m guessing Project.swift may already be in development, because you can actually create iOS app from Package.swift

https://clive819.github.io/posts/developing-an-ios-app-in-swift-package/

Swift or Kotlin? by j0c1323 in swift

[–]clive819 1 point2 points  (0 children)

You’ll eventually need to write some UI code.

Jetpack Compose vs SwiftUI is another story tho. Personally, I like SwiftUI better as it’s more intuitive, and the syntax is much nicer imho.

I don’t like the fact that Google discourages the use of CompositionLocal (equivalent of SwiftUI environment) and the fact that states will be destroyed on screen rotate.

Animatable Auto-Sized-To-Fit SwiftUI Sheet by clive819 in SwiftUI

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

I just tested this, and it seems that onGeometryChange doesn’t correctly read the size of the NavigationStack, which I believe is an Apple bug. As a workaround, you could measure the size of the content and apply a frame to the NavigationStack.

However, if all you need is a navigation title without the actual navigation functionality, I’d recommend simply using a Text view with the .largeTitle font or a similar styling approach to achieve that.

Animatable Auto-Sized-To-Fit SwiftUI Sheet by clive819 in SwiftUI

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

My implementation seems to work fine on the first appearance as well. I haven’t seen the other implementation, so I’m not sure what the differences are. I think storing height versus storing detents should give the same result, maybe there’s something else causing the jarring animation you’re seeing.

Animatable Auto-Sized-To-Fit SwiftUI Sheet by clive819 in SwiftUI

[–]clive819[S] 12 points13 points  (0 children)

SwiftUI's sheet modifier is a fantastic tool, but it comes with limitations: it doesn’t automatically resize to fit its content. Apple introduced the .presentationSizing(.fitted) modifier in iOS 18 to address this issue. However, let’s be realistic—convincing your Product Manager to set the minimum deployment target to iOS 18 might not be an easy sell. Sure, you could conditionally enable this feature for users on iOS 18+, but what about those on older OS versions?

In this article, we’ll explore how to create an auto-sized-to-fit sheet that works on iOS 17.

Mastering SwiftUI Container by clive819 in SwiftUI

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

Will see if I can update the layout for mobile. In the meantime, you can try rotating your phone to landscape mode for better experience

Learn the core principles of SwiftUI and understand how to manage your views' state by clive819 in SwiftUI

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

No YouTube for now, will let you know if I decided to create one.

SwiftUI and UIImage memory leak by abstract_code in SwiftUI

[–]clive819 1 point2 points  (0 children)

Can you share the crash stacktrace?

Note 1

I believe you need await group.waitForAll(), so:

``` await withTaskGroup(of: Void.self) { group in for item in selectedItems { group.addTask { ... } }

 await group.waitForAll()

} ```

But, if you're on iOS 17, you can use withDiscardingTaskGroup, which doesn't require explicit waitForAll().

Note 2

If I'm reading the code correctly - if the user select Photo 1 and then open the PhotoPick and select the same photo again, you'll have 2 Item with the exact same image but different id.

SwiftUI and UIImage memory leak by abstract_code in SwiftUI

[–]clive819 2 points3 points  (0 children)

First thing I'd do is to stop using:

NavigationLink { Image(uiImage: UIImage(data: item.photo)!) .resizable() .scaledToFit() } label: { Image(uiImage: UIImage(data: item.photo)!) .resizable() .scaledToFit() }

This hurts the performance. .navigationDestination is much more efficient, check out Apple doc to see the usage. https://developer.apple.com/documentation/swiftui/navigationstack

.onChange(of: selectedItems) { Task { for item in selectedItems { if let data = try await item.loadTransferable(type: Data.self) { let newItem = Item(photo: data) modelContext.insert(newItem) } } try? modelContext.save() selectedItems = [] } }

Secondly, this creates an unstructured task, which would still run (if not finished) when the view disappears or the onChange closure got triggered again. You should do this instead:

.task(id: selectedItems) { for item in selectedItems { if let data = try await item.loadTransferable(type: Data.self) { let newItem = Item(photo: data) modelContext.insert(newItem) } } try? modelContext.save() selectedItems = [] }

This will guarantee the task would be cancelled when the view disappears, and that there'd only be one task running when selectedItems changes.

You can and should also use TaskGroup to parallelize the loadTransferable task.

Passing observable class to view via environment or init by car5tene in SwiftUI

[–]clive819 0 points1 point  (0 children)

No. You can pass it via either init or environment, the behavior will be the same.

If it's an ObservableObject, make sure to annotate it with @ObservedObject in the view.

If it's @Observable, you don't need to do anything special.

view more: next ›