I do not have a clear idea and understanding of the correct approaches to the implementation / programming of the UI-part of the application, so to say, the "backend" part, so far there are no special problems.
I will give an example:
When I realized that the application needed to submit to something more advanced and modern than simple MVC, I studied the issue of architectural patterns, chose the right one (VIPER), studied it in more detail and implemented it.

However, the following tasks:

  • Make a reusable grid with elements of the "icon - signature" type, and show on a small screen in three columns, on large ones in four, plus slightly increase or decrease the size of these icons and signatures. As a result, I created a xib file for one such grid element, and a UIView descendant class, to which an array of images / captions is passed and it calculates and builds everything there
  • Two blocks (upper and lower) can vary in size relative to the content, and the block between them (label) takes up the remaining space. In this case, the text in UILabel should not go half the line under the frame. It was necessary in the code to slightly trim the height of the label so that the length was a multiple of the height of one line.
  • Reuse the table by removing some buttons from the tab-bar. For example, there is a main ribbon of elements, but there is the same ribbon, only with selected ones.

    I caused a lot more problems and google their implementation was much more difficult. In the end, I did everything myself, but I am sure that there are more correct and elegant approaches to solving those tasks with UI that appear every day. Also have a question: Storyboard or UI in the code? Or part there, part there? So far, I have a second option with a separate storyboard for each controller and interspersed with xib files for some reusable views, such as a round icon and a signature. However, there are suspicions that it is better to do this in code (setting sizes, positions, constraints), using third-party libraries for layout, because faster in terms of application performance, more convenient and easier in terms of version control.

    The question is not specifically on the above points, but on general theoretical training and good practices for working with UIKit. For it is easy to distribute the necessary non-adaptive interface, connect it with outlets and fill out the view with the necessary content for a long time, even 70% of the autolayout tasks can be implemented quite well. However, in the process of growing and complicating the ui and capabilities of the application, I increasingly need the theory and practice of UIKit higher than junior. Please tell me what are currently bad / best practices, what is considered good and what is not? Maybe there are some sites / tutorials where they show how to create reusable UI components, how to build complex autolayout (as a rule, all tutorials are very simple and in real life you have to do something many times more complicated, and the correct theoretical basis for solving these or There are no other less complex and real tasks UI).

      • 1 answer 1

      Here the question depends on your resources, if you do not require detailed processing of UIView, then it is better to use XIB or Storyboard, this will save your mind time. If you need to draw a complex UI, then it’s better to code it in a custom class inherited from UIView , with the addition of Core Graphics and Core Animation .

      Here are described in more detail the pros and cons. The article is quite old, but the concept has not changed. Manual layout vs Storyboard / Nib

      I can only recommend paid courses for practice. From their time they helped me a lot. Custom Controls in iOS , Drawing in iOS It is preferable to take a second course, as it is written in swift 4.

      So if you're going to create a UIView code. This library will make your life much easier. SnapKit

      • Thank you very much! - Artem Kolyadin