UIAppearance was not so simple

    The UIAppearance protocol appeared in iOS 5 in 2011, in those distant times when Instagram didn’t have an Android application, and the serial Ned Stark wasn’t cut off yet.


    About Eddard

    The masters sent me a raven with the news that at the time of the release of iOS 5, they had already been chopped off. But in order not to spoil the red wedding or something else, perhaps I will leave everything as it is.


    There is enough information, tutorials, articles on this topic, every beginner iOS developer knows how and why to use it, so this article is not about that. I would like to reflect on the topic of what is wrong with him, and why Apple does not pay attention to it.


    As a small introduction, excerpts from the documentation that has always been, are and should be the main trusted source of information.


    You can customize the appearance of instances of a class by sending appearance modification messages to the class's appearance proxy.

    To support appearance customization, a class must conform to the UIAppearanceContainer protocol and relevant accessor methods must be marked with UI_APPEARANCE_SELECTOR

    For myself, I understand it this way: if you want to change the default appearance for all objects of the class that implements UIAppearance , check if the property is marked with UI_APPEARANCE_SELECTOR , and go. Accordingly, if the property is not UI_APPEARANCE_SELECTOR , then this will not work.


    But “doesn’t succeed” does not mean “you can’t try,” so I suggest that all curious people conduct a simple experiment: open the first project you come across and add the application:didFinishLaunchingWithOptions:following line to the method :


    UIView.appearance().isHidden = true

    Estimate what will happen and run.


    I, like a bore, would expect possible options:


    • Nothing happens;
    • nothing happens, but a log like "isHidden is not UI_APPEARANCE_SELECTOR, stupid" falls out into the console;
    • The application catches a critical error or assert with a similar message.

    But no, everything, including the main application window, becomes hidden. On the one hand, it is even logical - what is written is done. But on the other hand, it looks like undocumented behavior and, it seems to me, a rather big hole like that.


    I could still come to terms with the fact that if such tricks could be rotated only with those properties that affect the appearance, but this can be done with all the properties !


    For example, adding to the code that other projects use as a third-party library, here is a line that is sometimes called at a random moment in time:


    UITableView.appearance().delegate = nil

    You can reset all delegates to all tables that appear on the screen after this code is executed.


    Developers will have a lot of fun trying to figure out what happened! Surely, you can come up with something even more fun!


    I really hope that such things did not go unnoticed by Apple (I didn’t find any information on this topic), and such tricks are revealed somewhere at the stage of automatic assembly verification in AppstoreConnect. But to be honest, I don’t feel like checking.


    Such things guys. I will be glad to discuss if someone is also interested in the topic.


    PS Give me back my 2011!


    Also popular now: