Description
The framework swizzles the UIView.init(frame:) method of each UIView subclass that conforms to AccessibilityIdentificable (not of the UIView superclass) in order the inject accessibility identifiers, but it is quite common for custom UIView subclasses to have a different initializer (that accepts arguments like UI models or closures).
These, of course, cannot be automatically swizzled by the framework, so a project can end up with lots of custom views that do not have their accessibility identifiers injected.
The above behavior is not explicitly documented in the README file or the code, so it is somewhat unexpected and it is not clear if it was intended.
Notes
We found out the above after adding this framework to a very big application and starting using it for more complex views, so we've been searching for solutions that don't involve changing the view initializers themselves.
Proposed solution
Swizzle the UIView.init(frame:) superclass method instead. This is a more intrusive option (as it affects all UIView subclasses, not just the ones conforming to AccessibilityIdentificable), but since we can restrict usage of the framework to only UI test targets via:
if ProcessInfo.processInfo.arguments.contains("-xcuitest") {
AccessibilityInjector.inject()
}
as given in the documentation, no production code will be affected (regarding both correctness and performance).
Description
The framework swizzles the
UIView.init(frame:)method of eachUIViewsubclass that conforms toAccessibilityIdentificable(not of theUIViewsuperclass) in order the inject accessibility identifiers, but it is quite common for customUIViewsubclasses to have a different initializer (that accepts arguments like UI models or closures).These, of course, cannot be automatically swizzled by the framework, so a project can end up with lots of custom views that do not have their accessibility identifiers injected.
The above behavior is not explicitly documented in the README file or the code, so it is somewhat unexpected and it is not clear if it was intended.
Notes
We found out the above after adding this framework to a very big application and starting using it for more complex views, so we've been searching for solutions that don't involve changing the view initializers themselves.
Proposed solution
Swizzle the
UIView.init(frame:)superclass method instead. This is a more intrusive option (as it affects allUIViewsubclasses, not just the ones conforming toAccessibilityIdentificable), but since we can restrict usage of the framework to only UI test targets via:as given in the documentation, no production code will be affected (regarding both correctness and performance).