These constraints are not managed by you, and so there is nothing you can do to resolve the issue. Feel free to file a bug if you like.
Post not yet marked as solved
Unclear why it wouldn't be working, but if your update really is to just show the menu that you wish to apply to the UIButton you don't need to call updateVisibleMenu – just setting a new menu will cause UIButton to do that for you on your behalf and is recommended for these kinds of cases.
I'm not recommending you move back to the old navigation bar appearance API (e.g. barTintColor and friends). I'm just recommending you not call +appearance to set the standardAppearance and scrollEdgeAppearance.
If you are running on iOS 13 or later, we absolutely recommend you only use the UINavigationBarAppearance based APIs to customize your navigation bar (tintColor is a UIView property, and so is fine to use as well). But you do not have to use them via the Appearance proxy (aka +[UIView appearance]).
So all you need to do is change this:
if (@available(iOS 13.0, *))
{
[UINavigationBar appearance].standardAppearance.backgroundColor = color;
[UINavigationBar appearance].compactAppearance = [UINavigationBar appearance].standardAppearance;
[UINavigationBar appearance].scrollEdgeAppearance = [UINavigationBar appearance].standardAppearance;
}
to this:
if (@available(iOS 13.0, *))
{
navigationBar.standardAppearance.backgroundColor = color;
navigationBar.scrollEdgeAppearance = navigationBar.standardAppearance;
}
(it is rarely necessary to set the compactAppearance because if it is not set we simply use standardAppearance in its place).
There are 2 levels of "appearance" going on here, and unfortunately its a bit confusing I think.
When I say the appearance proxy I mean code like UINavigationBar.appearance() – this code creates a UINavigationBar-like object that you can treat just like a UINavigationBar for the purpose of setting many values that alter the bar's appearance. The thread you linked references the class UINavigationBarAppearance which is a consolidated object that lets you customize many aspects of a UINavigationBar's appearance.
So yea, its a bit confusing when you have to write it all out together like that.
If you are only changing the appearance of the navigation bar, you can just adjust it directly with code like navigationController.navigationBar.standardAppearance... (ditto for the other properties). You don't have to go through .appearance() at all.
The appearance proxy is only evaluated when a view enters the view hierarchy (not necessarily related to drawing). Using the appearance proxy as an app customization scheme has its pitfalls in other ways however, as the more times you use the appearance proxy with a specific property the slower it gets (it actually has to apply each appearance customization you ever make, in order, when a view enters the view hierarchy).
So in practice your kludge is expectedly kludgy, but primarily because the appearance proxy isn't really meant to be used in this way (although I can't really argue against doing this for this particular feature either – its really hard to update everything in your app if you have a lot of things to update that are all over).
Post not yet marked as solved
In general we wouldn't recommend UIGraphicsBeginImageContext as we introduced the UIGraphicsRendererContext APIs to replace it, but I don't think thats your actual question – I think your actually asking how to take a screenshot correct? If so probably the most reasonable thing to do is call UIView's drawViewHierachyInRect method to draw the content in your window into a graphics context which you can then save as an image.
Post not yet marked as solved
When you move a VNode from one location to another, do you use UIView.addSubview() (or similar method) or do you use CALayer.addSubview() (or similar)?
If the latter, your probably corrupting the layer tree inadvertently as UIKit expects to always manage layers that are owned by views, and managing the tree at the Core Animation layer for those layers may confuse UIKit.
Post not yet marked as solved
You register UICollectionViewCell.self as the class of cell to use for photoCollectionViewCell.identifier but later expect to get a cell of class photoCollectionViewCell. This fails and Swift calls the else branch where you call fatalError() (which is why there is nothing descriptive – its your fatal error, not the system's).
You should register your sell with photoCollectionViewCell.self so you get cells of the expected class back.
PS: Its customary to name types with a leading capitol letter – in this case PhotoCollectionViewCell – to distinguish them from variables (which usually start with a leading lower case letter).
It isn't clear why this would be happening to you – how do you have your view controller hierarchy setup? Is it just UINavigationControllers in UITabBarControllers or something more complex? If nothing else, it can often help to try to create a minimal reproduction case to narrow down what configuration is causing the issue, and then it makes it easy to file a feedback report.
Post not yet marked as solved
The size of view during viewDidLoad is not necessarily correct for final layout, in general we recommend you either use auto-layout or override UIView.layoutSubviews() or an analog like UIViewController.viewDidLayoutSubviews() or UIViewController.viewWillLayoutSubviews() to ensure that the subviews you create are laid out properly (this also applies to views you subclass – the size passed to initializers is not expected to be final, especially for larger more complex views like a SKScene subclass. Finally you should keep aware of coordinate system differences – UIView.frame is a view's extent in its parent's coordinate system and may not be correct for layout of subviews (setting a non-identity transform on a view will change its frame for example). You should always use bounds when referring to a view's internal coordinate space, such as when positioning and sizing subviews.
Finally your showTextField method always creates a new UITextField and adds it, which may be causing other issues (minimally, causing you to pile up UITextFields). Depending on specifically what is going on, you may either be positioning the UITextField you are creating offscreen, or you may be conflicting with positioning that SKScene itself is doing – I'm not familiar with that class enough to know how adding subviews affects its behavior.
Post not yet marked as solved
By default the navigation bar doesn't use a color, it uses a blur – the UIBlurEffectStyleSystemChromeMaterial blur style specifically.
Post not yet marked as solved
If you feel that this is an issue that could be improved you are always welcome to file a Feedback report. However consider that it is likely that UIKit has worked like this for a long time, and there are a lot of clients that may be (directly or indirectly) depending on any number of behaviors like this that may be the reason why such behavior persists.
In particular however, UIKit does expect these methods to be very fast because they may need to be called during other calculations that also need to be very fast. And while it is hard to deny that calling something once and remembering the value can be faster than calling it twice, it can also be very hard to do so in certain cases.
That does not look like an exception message from UIKit, so I don't really have any specific comments on this issue – given you mention updating GoogleMobileAds you might consult with them to see if they know what might cause this
Post not yet marked as solved
That means instead of using a mask, just use a superlayer or superview to do your clipping instead. So instead of creating a mask view and setting it as a mask on the other view, just add the other view as a subview.
Post not yet marked as solved
You could just calculate and set the contentSize manually.
That said the limit should be at least 1 million (it varies by platform for various mathematical reasons).
