Post not yet marked as solved
There is no support for programmatically showing a menu.
As the state of battery monitoring for your app is process-wide, it is likely that something else running in your app requested battery monitoring before you checked the value.
Post not yet marked as solved
This likely happened because you manipulated a UIView from a secondary thread. When that thread exited, CoreAnimation performed work on it that required layout, and thus called into auto layout, causing the assertion and your crash.
Post not yet marked as solved
The crash location likely indicates some kind of corruption has occurred – object_getClass() mostly does memory fetches from the start of the object, so if the object is corrupted, or the pointer passed to it is bad, then it is likely to crash. But unfortunately beyond that I'm not sure what might be causing this. Not animating things is only hiding the issue (as you likely have surmised).
Post not yet marked as solved
The state of the art remains view controller based status bar management. In particular your view controller overrides prefersStatusBarHidden and returns YES.
Post not yet marked as solved
There should be no need to process the image – the chart your referring to only referenced what formats were supported by CGBitmapContextCreate(), and it is also somewhat out of date (many of the Mac OS X only formats it references were added a few years ago).
CGImages support many more formats than are possible to generate with a bitmap context, so for displaying the image you generally don't need to worry about its internal format.
Post not yet marked as solved
My first guess wold be that the cells are using systemBackgroundColor as their background, which is white in light mode and black in dark mode. If this is the case – and since you seem to always want to take light mode snapshots – the simplest thing to do is set overrideInterfaceStyle on the OBAListView to .light when you are taking your snapshot.
Post not yet marked as solved
If I understand what your doing, your creating a new instance of HappyView() each time, changing the background color of its view, and then throwing it away.
The typical solution here is to remember what was selected (blue or green) and then when you want to navigate to HappyView() set the background color as part of navigating there.
Post not yet marked as solved
The design for the overflow button is not that you disable it, but that it disappear when there is nothing in it. There is no way to access the button that corresponds to it to modify its behavior.
First off, what you are doing isn't an override, its a replace (and probably only works because UIColorPickerViewController is an Objective-C class). The super your calling is UIViewController.viewDidLoad() so your eliding anything that UIColorPickerViewController may be doing in viewDidLoad() by doing this.
Secondly, your assuming that other clients of UIColorPickerViewController are setting the delegate before your viewDidLoad() code gets called.
What you are doing is very dangerous. You do not know what all clients of UIColorPickerViewController maybe expecting, how UIColorPickerViewController is internally implemented, or what you may break now or in the future by doing this.
UIColorWell is a control and as such you can assign multiple actions to it. This is how you would monitor color changes to the color well and react to it immediately.
Post not yet marked as solved
In general this means that you triggered layout on a background thread, I would start by looking at any code involved with a UIView or UIViewController, or barring that anything from UIKit that is not marked thread safe. Given your back trace, the issue is also not likely to be temporally "recent" – the code triggering this layout is happening because the thread exited, and some UIView happened to have been marked as needing layout while that thread was active, but Core Animation never got a chance to do the work it was asked to do.
Post not yet marked as solved
There seems to be a fair amount of missing setup and some missing extensions – I cut back what I could to get this to compile but couldn't reproduce the issue. Given what is happening in your keyframe animation, my immediate suspicion would be something about UIButton, but I don't have a ton of context to provide there.
It would help to file a feedback request with a complete project (post the FB number here and I can track it earlier) just so that we can both be sure we are looking at the same thing.
Thanks!
Post not yet marked as solved
Something is trying to create an animation for the CALayer.contents, and in this case since contents is likely nil on whatever view is being animated its tripping over an assumption in the keyframe animation tracking that the value provided will not be nil. Since only specific views will animate contents it's unusual that a tracking data structure is even being created for that key.
We would certainly appreciate a feedback request with all the information you have on hand.
Post not yet marked as solved
This implies that either you didn't set the class of the view controller correctly in the storyboard, or the destination of the seque isn't what you expected.
Post not yet marked as solved
Something is causing this UI snapshot when it isn't yet in a window (which is why its in the _UISnapshotWindow in this case). It would be appreciated if you could file a bug with any information you have on reproducing this.
