Dropping iOS 8 support is not an explicit goal, but it might become necessary at some time in the future. This issue tries to track the things that need to be done when the time comes:
Revamp the app's layout system using layout anchors and layout guides. See the section Programmatically Creating Constraints in Apple's "Auto Layout Guide".
Set build setting CLANG_WARN_UNGUARDED_AVAILABILITY to YES_AGGRESSIVE. While iOS 8 was still supported this setting would have resulted in dozens of compiler warnings, all referring to the "unguarded" use of various layout anchor properties (e.g. leadingAnchor) in TableViewVariableHeightCell and TableViewSliderCell. In fact, usage of those properties is well guarded, but not in a manner that the compiler can recognize. After dropping iOS 8 support, those runtime checks can be eliminiated from the mentioned table cell classes.
Dropping iOS 8 support is not an explicit goal, but it might become necessary at some time in the future. This issue tries to track the things that need to be done when the time comes:
UIStackView
(see class reference, and the section Stack Views in the "Auto Layout Guide")CLANG_WARN_UNGUARDED_AVAILABILITY
toYES_AGGRESSIVE
. While iOS 8 was still supported this setting would have resulted in dozens of compiler warnings, all referring to the "unguarded" use of various layout anchor properties (e.g.leadingAnchor
) inTableViewVariableHeightCell
andTableViewSliderCell
. In fact, usage of those properties is well guarded, but not in a manner that the compiler can recognize. After dropping iOS 8 support, those runtime checks can be eliminiated from the mentioned table cell classes.