Apple released another shocker of a #SwiftUI sample: Wishlist: Planning travel in a SwiftUI app

https://developer.apple.com/documentation/swiftui/wishlist-planning-travel-in-a-swiftui-app

- uses var instead of let in immutable View structs.
- Uses non-standard State(initialValue:) instead of @.Binding.
- Uses @Observable class with @.State instead of struct for view data (TripEditModel and another named just Model in AddTripView).
- @Environment with @Observable instead of @Entry for a struct (maybe ok)
- Identifiable class Activity implements an id as UUID.

Wishlist: Planning travel in a SwiftUI app | Apple Developer Documentation

Build a travel planning app that organizes trips into collections and tracks activity completion.

Apple Developer Documentation

- it does sorting and searching via computed properties called from body instead of in actions.
- It needlessly uses @State var in the App when it could just be a let but neither are the correct way to init the real model and results in real model being init during previews.
- Preview data is implemented in non-standard way.

Nice the Goals tab has a 3D Cover Flow though!

@malhal

1. Why non-standard State(initialValue:)? It's fine in a View init.

2. Model in AddTripView is passed in the Environment, thus Observable and not a Struct.

3. What's wrong with using UUID to make a class Identifiable?

@alpennec

1. State(initialValue:) with object is a heap allocation every time the View is init which slows down SwiftUI. It's designed for value-types. That's why StateObject was added, it's init is lazy via auto-closure.

2. Yes I suppose because they wanted mutability in deep views. Although they also pass a binding to the model's property into direct child which is strange.

3. For class, Identifiable already implements id using pointer. If you wanted your own id you need a different name.

@malhal thanks for answering.