The ApplicationAccessibilityEnabled hack may turn out to be a very bad idea about dcintrospect HOT 2 CLOSED

Sorry it's taken me so long to take a look at this.

I did a test with a basic table view that had about 30 rows, with only 8-9 visible. I tested on device and in the simulator with and without the accessibility hack. In both cases, tableview:cellForRowAtIndexPath: was called 10 times after [tableView reloadData]. That seems like about the right amount for how many are visible. I didn't notice any change with or without the hack.

I wouldn't be surprised if the behaviour you're seeing is a side effect of accessibility, as I guess it needs to indicate what's on and off the screen... but I can't reproduce.

On my current project, we run the accessibility hack on designated test devices plugged into the Jenkins CI box, so I'm not too worried if it does affect scroll performance since it's turning on accessibility is not part of our release build at all. It's still got me a little concerned though!

from dcintrospect.

Closing this. I guess everybody is using Reveal or Xcode's builtin hierarchy viewer nowadays.

from dcintrospect.