You market your answer as the correct answer,. So it seems you have found the solution ? What was the problem ? That could be of interest for others.

I understand your frustration, but you give the answer yourself: "You need to submit an Appeal to expedite the process BUT you need to give a valid reason such as there is a bug happening in production or something..." That's the case everywhere when you appeal. There must be a reason for appealing that may justify a change in decision. In addition, when an app is rejected it is very important to explain clearly what you did to correct or why you think it is a misunderstanding. Not by considering the reviewer is dumb, but simply that he/she cannot spend 2 hours on the app and so needs easy to check information.

Note that @Binding does not seem necessary here.

There is a misunderstanding. You should not remove the all declaration @Binding var id: UUID    just replace with var id: UUID

Could you show the relevant code and the context of code (if possible full class which includes timer).

Thanks for feedback. Don't forget to close the thread my marking the correct answer. Good continuation.

Performance is not the most critical aspect. RAM, disk space and screen size are, IMO, much more important. I work frequently on a 2015 iMac (3,3 GHz Intel Core i5 four core, so not a really powerful machine with today standards). I upgraded from 8 to 24 GB RAM (was much needed), got original 2 TB disk and 27" screen. It is perfect for Xcode development.

I edited my answer (first guess with TextField was wrong).

Thanks for the feedback. Don't forget to close the thread once you've got a correct answer. Good continuation.

Thanks for the feedback. Note: you don't even need .searchable(text: $searchText). When TextField changes, State var searchText is changed, then body is reevaluated.

Thanks for the feedback, and great to read your app works now. As you get the log (RAMBar nil), that means the crash is just after, on the second print.

This may be an interesting read: https://stackoverflow.com/questions/68731011/when-is-deinit-exactly-called-in-swift

That what it says if you read just the first line. A field being edited is focused, a field may be focused without being edited. If you go through and make the effort to understand the examples, you will understand what they are. Sure, it is some effort, as for every learning… Good luck.

But doc describes how it is supposed to work. For instance: "In the following example of a simple login screen, when the user presses the Sign In button and one of the fields is still empty, focus moves to that field. Otherwise, the sign-in process proceeds."

Thanks, interesting information. But it would be so much better to have code snippets in the documentation.