I just happened to click on the Memory graph tool in the Xcode 12 Debugger and was impressed... can anyone help me to decipher what all these symbols could mean. There are yellow cubes and blue cubes; there are light blue OWL EYES (which might be Dictionary Objects) and a light blue cheeze slice, all quite a rich set of iconography that is attempting to convey ... something.

Have you tried to use the Xcode Debugger's View Hierarchy visualization tool? I am trying to figure it out - if you already have - please help me!

Over on the left you see a debugger dump of the View Hierarchy... in this case I've attached many views with an accessability identifier (just labeled identifier: <some string>). This gives me a bit of a clue as to what view is where. Unfortunenatly the identifier is not always stored nor used. One real problem I found was that if I placed an identifier [ .accessibilityIdentifier("checkboxHeader_view") ] for example on a container it would apply to all the sub-views and overwrite the more specific identifier. Exactly the opposite of my desired and assumed behavior. It would be really handy if the identifier was more prominently displayed in the exploded view - rather than hidden down in the accessibility section of text within the right pane. And bonus points if Apple included a search tool for all of this info.

The issue I've been trying to figure out for several weeks (off and on) is that a checkbox button "Select Card" functions perfectly fine in all the simulators - but does NOT function on my real device, iPhone 7. My working theory was that another view was infront of the button and "stealing" the touch events. Turns out my theory was bad... as @Lancer Kind pointed out that it could be a layout issue (I thought - what's that guy know about App layout - nothing - he's a backend dev). Once again he's right... how does he do it all the time! After putting some Spacer() views in my layout above the button the click started working!

Now it has yet to be understood... investigations are on-going... but over in that exploded view there is a possible hint... the top edge of the button capsule overlay is seen - and the rest of the button is cut off. I don't GROK that but it seems that Apples layout mechanisims can have flaws. One of which may be that a container with a button partially contained might not pass along touch events to an adjoining container - thereby "eating" the click event I'm counting upon.

There is a lesson to be learned here... I'm just yet to formulate it into a coheasive body of knowledge... something about views... and stacks of views with views... and it's just turtles all the way down.

Below - an example app where the use of accessibilityIdentifier() in a parrent container view overrides it's children's specific ID. Very different behavior than a property such as Color which does not have this overriding behavior.