The day started out quite promisingly, because I have possibly figured out the cause of the 1-in-10 bug, with the help of good old stackoverflow. Apparently, Swift is very loose with its background threads, and unless you specify synchronous activation of an action on a background, the action will be placed automatically in the asynchronous queue, and thus is open to deallocation at the whim of the iPad, which essentially means it will randomly deallocate to admit a new queue procedure. Furthermore, when calling a new NSOperationQueue(), the default is to choose exactly this type of asynchronous background thread as the queue location, meaning the accelerometer actions were taking place on the background thread, and thus were deallocated randomly. To fix the problem, I force the accelerometer queue to be instantiated on the main thread, which is never deallocated as it contains the main UI elements. This was one of three options, but until I see a convincing reason to pick either of the others, I’ll stick with this. The other two options were: 1. create the queue synchronously on the background thread, which would be safer, but I worry about placing any UI element on a background thread, it just seems like quite poor form; 2. create the queue asynchronously on the main thread, which would allow the iPad to overwrite some queue updates if it became too expensive. I don’t think this is needed because the accelerometer is not an expensive update, and so just writing directly the the main thread is acceptable, I believe.
User studies went well today, though just as I fixed the 1-in-10 bug a new one has arisen, just as confusing in its origin, but luckily far more reproducible. To avoid reiterating to much, I’ll simply link to the stack overflow post I made about this one, where I detail its behavior quite in depth. Hopefully I will be able to solve it tomorrow. It must have to do with the deallocation of the scrolling label when I remove it from the superView, so I have to find a way to force deallocation on the main thread. It could be I do have to place the queue asynchronously to allow me to dynamically deallocate, but I will pursue other options until I find that to be the only option/I understand how to do it.