To me it also looks like related to the analysis during build time only by the fact that this warning happens on a simple build with no run, which has nothing to do with run time life cycle events in which the custom transformer might be registered. I hope we will get some more info on this.

I have submitted a Feedback via the Feedback assistant to the Xcode team. Will update as soon as I have a response.

Perfect, thank you. I also experiment with this (https://www.avanderlee.com/swiftui/conditional-view-modifier/) approach which works but yours is cleaner.

As of iOS 17.2 the use of .disabled(i > 3 && i < 8) no longer works. This might be an iOS bug in 17.2 as in 17.0 it works but for this reason I am updating this answer and will update if it gets resolved by Apple. For now I went back to using a custom @ViewBuilder described here

Thank you very much for the detailed explanation that all makes sense, I just wanted to make sure that I’m not missing something cool in DocC that could be beneficial in this case. Using a separate target makes perfect sense.

Ok, but how come the same is not true for the input22 string which is again "a" + emoji (different one). Looks like it works for some emoji symbols only, which is quite strange. I am currently going with the iterate over the string approach, but still I am trying to understand there is a different results when checking the two strings "a🥀" and "a😀".

Yes of course, the feedback number is: FB15218828

Interesting. Yes this looks to solve the problem, thank you I will use it. I am now wondering is this breaking anything important that SwiftUI might be doing intentionally. I am not an expert in SwiftUI mechanics and how it marks views as "dirty" but the solution you provided looks 100% correct. But the initial issue definitely looks like an internal bug in SwiftUI. Thank you.