Thanks, I hadn't seen that. I guess I'll pay for a tech support request and see if they can explain what's going on. I will post back here if I get an answer.

Thank you, that's a very helpful answer.You seem to have a good understanding of SwiftUI so I'm curious how you learned it. The documentation I've seen is often not very helpful. Many functions and properties have empty docs.I don't understand the layout algorithm. It appears that after years of telling us autolayout was great, they've abandoned it. But I don't know what's happening in its place, and how one might hook into it to observe/debug/modify it. For example, I would have guessed that the `HStack` would constrain it's contents, but it doesn't. If you put `.frame(width: 320)` on it (320 being the device's screen width), the children pickers just overflow, without any error messages about broken constraints.

There have been no meaningful updates to my bug report, but I posted about this problem again in another thread and someone gave a good workaround, at least for my specific case:https://forums.developer.apple.com/thread/127028

According to developer tech support, the current behavior is correct. Some of these devices, like 2nd generation iPad Pro, don't support read-write textures. I was a little confused that they wouldn't admit that it was behaving differently before, but I don't have time to do all the extra work to prove that to them.You can see the "function texture read-write" feature in the Metal feature table here: https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdfYou can detect the function texture read-write support like this:if #available(iOS 11, *) { if self.device.supportsFamily(.common3) || self.device.supportsFamily(.apple4) { print("supported") } else { print("not supported") } } else { print("Needs iOS 11 or higher") }

Hi 4k4,Here’s why I was confused. I gave Apple sample code that produces the error on iOS 13. Apple could run it on iOS 11 (maybe compiled with Xcode 9), on the device in question (iPad Pro gen 2), and get the proof (for or against), but they didn’t do that. Or at least, they didn’t tell me they did.I imagined it was relatively easy for Apple to do such a thing. For me as a solo developer it’s certainly not easy; I’d have to wipe my only device or buy another, download old Xcodes. Maybe I assumed incorrectly that Apple would be set up for running such a test, and that 3 people here saying they have a similar problem would be motive enough to do it. But if that's not the case, then I totally understand why neither I nor Apple want to spend time testing this!It's not a big deal, since we see how it works now and can move forward. I'm just curious what happened.take care,R

> ... old value will only be available until the moment the objectWillChange call completes, and not afterwards; the publisher is expected to enforce this. This is one of the reasons for the existence of the @Published property wrapper, and the change from the previous guidance of just using your own 'objectWillChange' subjectI'm curious if you found this in the docs somewhere, or ??. I can't find it in the docs for `ObservableObject` protocol or it's method `objectWillChange`. Or on the `Published` struct.In some situations I would prefer to use my own `objectWillChange` publisher, intead of @Published on properties. I'm now worried that going that way, without extra locking code like your example, could lead to race condition bugs where SwiftUI sometimes fails to properly update Views.

If you click on one of those initializers, the Xcode documentation browser shows no documentation - just the method signature. But the second way, the generated header on whatever it's called, you can scroll down and see more helpful documentation for the parameters to `init`, like this:extension Slider { /// Creates an instance that selects a value from within a range. /// /// - Parameters: /// - value: The selected value within `bounds`. /// - bounds: The range of the valid values. Defaults to `0...1`. /// - onEditingChanged: A callback for when editing begins and ends. /// - minimumValueLabel: A `View` that describes `bounds.lowerBound`. /// - maximumValueLabel: A `View` that describes `bounds.lowerBound`. /// - label: A `View` that describes the purpose of the instance. /// /// The `value` of the created instance will be equal to the position of /// the given value within `bounds`, mapped into `0...1`. /// /// `onEditingChanged` will be called when editing begins and ends. For /// example, on iOS, a `Slider` is considered to be actively editing while /// the user is touching the knob and sliding it around the track. public init(value: Binding, .......

Interesting. At first glance here I think I can make that work. I will have to think about pros and cons between that and the class-based approach in the real app.Thank you for the response.You mentioned that maybe protocols aren't a good fit here:> [quote] I'm inclined to think that this situation isn't quite a fit for the protocol approach, though. Since you're relying on ObservableObject at the root of the protocol tree, you're already limited to class types, which means you can just use classes all the way and use inheritance to do what you need.I'm attracted to protocols in this situation because as I think of different features that a marker might support, I can imagine concrete classes that support different subsets of those features. It doesn't seem to fit into a neat single inheritance hierarchy. So I was thinking I could use protocols somewhat like a 'mixin' or 'trait'. I haven't gotten deeply into this though. At the moment I don't have many marker types, so I'm not sure how it will play out.

Hi Mike,I played around with your code a bit. I'm no animation expert; I'm just learning about them. So this feels kind of hacky, but maybe it will help until something better comes along. I changed it so I could alternate between two strings, but the idea is the same.I didn't see how to create an animation that starts at the time of change without adding another property (`justChanged`) to represent the temporary pulse.Robstruct ContentView: View { let model = Model.shared var body: some View { VStack(alignment: .center, spacing: 30.0) { Button(action: { self.model.update() }) { Text("Tap Here") } Cell(model: model) } } } struct Cell: View { @ObservedObject var model: Model var body: some View { Text(model.myVar) .padding() .background(model.justChanged ? Color(white: 0.5) : Color(white: 0.9)) } } class Model: ObservableObject { @Published var myVar = "Pizza" @Published var justChanged: Bool = false static var shared: Model { return Model() } func update() { if myVar == "Pizza" { myVar = "Bananas" } else { myVar = "Pizza" } withAnimation { justChanged = true } DispatchQueue.main.asyncAfter(deadline: .now() + 0.5 ) { withAnimation { self.justChanged = false } } } }

I found the problem and a fix. It appears that the tap target is not the 40x40 ZStack, but rather the 1pt-wide white stroke line inside the ZStack. So I can fix this by adding a white rectangle behind that stroke, inside the ZStack, then the tap target becomes easy to hit again and all is well.

Are you saying your code won't compile when you put another view under the `logo()`? If so, it may be because SwiftUI has a limit on the number of subviews. I forget the exact number but it's around 10, so you may have reached it. One way around around this is to put some views in a Group. Eg:NavigationView { List { // Now these 4 children of List are only 1 child. Group { NavigationLink ... NavigationLink ... NavigationLink ... NavigationLink }I hope this will be fixed in future. Maybe they need variadic generics to do it. And yes the error messages from the compiler are very bad, at least in Xcode 11.3. I'm hoping it's better in 11.4 but I haven't tried the beta.

Hi Michael,I posted on the swift.org forums about this and someone answered saying it was a bug related to NavigationLink, and there is a radar for it. So apparently my example code _should_ work, regardless of whether the "source of truth" is a State or an ObservedObject. But I think what you did passing the object is a good work-around.Rob

This post was delayed by moderation, but in that time someone answered on the Swift forums. Apparently it's a known bug.

Bah, nevermind. My app had a "Spanish" localization, but not a "Spanish (Latin America)" localization. When I added the latter in the project settings, it started picking the right voice.

I'm having the same problem trying to test my IAP. I'm on an iPad with 13.3.1. In recent days the sandbox has given sporadic "Cannot connect to iTunes store" errors. Usually (for years now) the sandbox asks me multiple times for login/password, and I worried it was something I was doing wrong in my code, and that this might happen in production. This morning it's asking me over and over again, like you described. I did as you suggested - cancelled, and tried again. I got a couple "Cannot connect ..." errors and then on the 3rd try it went through.So, it seems they are having server-side issues, despite the status here saying it was fixed two days ago (on March 30):https://developer.apple.com/system-status/