The main benefits of using child view controllers:

1. Child view controllers are self-contained and independent from parent controller. They have own internal business logic and interface construction.
2. They have the same access to lifecycle events(viewDidLoad, viewWillAppear) as their parent controller. What might be convenient for many cases.
3. When using child view controllers as separate pieces of interfaces, they aren’t strongly coupled in the screen. It’s easy to replace one child controller on another.

Good candidates for considering this pattern are:

• view controller with embedded scrolling list, that contain many different complex blocks (f.e. feed screen)
• custom views, that can be presented as subviews in view controller (f.e. alert)
• view controller that can be divided visually into separate blocks with own business logic (see my own example below)

I’m writing this article to show the benefits of this pattern on real example.

Note: In this article, I’m concentrating the attention on how to struct custom interfaces in a complex hierarchy of views from the architectural point. I will skip explanations for implementations of interfaces, animations and dragging.

Let’s assume, that we have a task to create a profile screen, that contains different information about the user and also contains personalised suggested information. Design looks like this:

Visually we can divide the screen into 3 separate parts, each of them containing own data, business and server logic. One of the variants is to implement it via custom UIView classes. And keep all logic inside one view controller or/and inside those views as well. But just imagine, how massive view controller we will get finally 🤔 And even more, what if client or designer decides to add an extra one or two cards later 🤯

The rescuer here is an injection of child view controllers which lie perfectly on this UI/UX case. We will use one parent view controller that will be responsible for keeping three other child controllers:

1. Child controller for the top part (short profile info like avatar and name)
2. Child controller for the list of activity information (yellow card)
3. Child controller for the feed with recommendations (white card)

In order to add or remove child controllers to the parent we would need two straightforward helping methods:

add() method adds the child to the parent view controller. Then adds the view of the child to the view of the parent. Eventually, it notifies the child that it was moved to a parent.

remove() method notifies the child that it’s about to be removed. Then, removes the child from its parent. Eventually, it removes the view of child from the parent’s view.

Parent view controller ProfileViewController will be subclassed from CardsHolderViewController , which contains implemented logic to handle opening, closing and dragging of the cards.

The approach to constructing such interfaces is very simple. We have 3 views inside CardsHolderViewController.view : topView, cardView1, cardView2. During the initialisation of the screen, we’re setting initial frames for them. Each of these views will be responsible for keeping own child view controller, assigned from ProfileViewController.

Then, from viewDidLoad() method of ProfileViewController we’re assigning our desired child view controllers using helping methods attached earlier in the article.

1. ProfileShortInfoViewController for displaying avatar and name.
2. ProfileActivityViewController for displaying the list with activity history.
3. RecommendationsViewController for recommendations feed.

where methods setCardChildViewController(_) and setTopChildViewController(_) assign passing view controllers as a child, and then add the view of controller as a subview to the corresponding cardView or topView with desired frame.

That’s it 🙌. With this simple implementation, you’re getting constructed profile scene with child view controllers inside. Using interface debugging tool of Xcode, we can see a full visual hierarchy of subviews inside one scene:

One more thing ☝️

You could notice in the demo presentation, that cards are draggable and some animations occur during the opening and closing of the cards. CardsDragger class is responsible for handling gesture interactions and perform corresponding actions for cards(close/open). It’s initialised inside CardsHolderViewController and observes UIPanGestureRecognizer events.

It has didOccurDraggingEvent: ((_ value: CGFloat) -> Void) closure, that fires every time, when the frame of any card changes. One can use it to run own animations inside parent view controller based on cards’ states/frames. In my example, it’s an animation with avatar image and labels of top child controller.

Conclusion

We just saw on the real practical example, that it’s easy and convenient to construct complex screen via child view controllers using them as plugins. With this approach, it will be simpler to support and scale your code further. Of course, this is not a universal pattern, that must be applied everywhere for all screens. But I suggest to take it into consideration, when you going to implement a massive screen or when some complex pieces of the interface might be used as UI plugins in separate places in your app 😉

The full project is available on Github.
If you have any questions or suggestions, feel free to contact me by email or just leave a comment below.
Hope you found this article useful and inspiring. Thanks for reading 👏

Nowadays iOS developers must support around 6 different screens sizes of iPhones. This often requires to use different values when building interfaces for smaller and bigger devices. Usually, if you’re building interface from code, it looks like this somewhere in your view class:

This bunch of if/else doesn’t look sexy, and even worse, it has a chance to expand if you need to cover other devices separately. And when you have custom UI in your app, often you would need to provide such an approach in almost all of your screens.

So I wanted to improve this situation and thus I created SBValue.

SBValue

This is a simple structure, that accepts values of generic type, which associate with each of the iPhone devices. After the initialization of this struct, you just need to call definedValue , and it will return a value, which corresponds to the device, that uses your app. That’s it.

You can add/customise init methods in order to fit your requirments. And you can expand it with iPads as well.

To check for the device, that uses the app, I’ve implemented a popular solution:

Returning to previous example with ProfileView, it will look like this after injection of SBValue there:

In result:

• less lines of code
• expandable for other devices
• easy to assign as a variable, when needed

You might be interested to check also an approach of my friend when you implement UI via interface builder.

If you have any questions or suggestions, feel free to contact me by email or just leave a comment below.
Hope you found this article useful and inspiring. Thanks for reading 🙌

There are two main things, that I will demonstrate and explain in this article:

UIKit supplies us with a short amount of built-in transitions, that we regularly use while implementing a transition from one view controller to another. The most popular are modal present and navigation push. Because of their simpleness and wide common usage, such transitions could be boring and won’t make users excited in case when app’s design is fully custom.
A great solution would be to use possibilities of UIViewControllerAnimatedTransitioning and UIViewControllerInteractiveTransitioning protocols that stand for creating custom interactive transitions.

The second thing is about frequently used UI component at iOS — UICollectionView and its cells. Usually, if talking about interaction with cells, it’s enough for us to handle clicks via didSelectItemAt method of the delegate. But I want to show, how an injection of UIGestureRecognizer object can increase the potential of UICollectionView cells and distinguish it from the rest of the screen’s components.

Remark: I wrote this article to show the most important things and features, rather than teaching step-by-step implementation. So it assumes, that you feel confident with Swift language and know basics of UIKit.

Let’s start from transition

The project has a storyboard, that contains two view controllers. StartViewController(left) has a lot of subviews, just to show some content. But the view, that is interesting for us, has label “Open Cards View” and placed in the bottom. It will be responsible for catching gestures and presenting CardsViewController(right) by dragging or with a simple tap.
CardsViewController has collection view, responsible for showing cards and has few subviews to show different backgrounds based on transition’s progress.

A required thing to implement custom transition is to describe its mechanic’s rules at class, conformed to UIViewControllerAnimatedTransitioning.
For presenting transition create MiniToLargePresentingViewAnimator class, that inherits from NSObject due to UIViewControllerAnimatedTransitioning requirements. Also, you need to create MiniToLargeDismissingViewAnimator, responsible to provide custom dismiss transition. Both animators have pretty the same code, so let’s explore only presenting part.

MiniToLargePresentingViewAnimator has two properties: duration and initialY. With the first property, everything must be straightforward. initialY needs more attention. When the user starts dragging bottom piece of card, the next view controller is being presented and his position starts from initialY. initialY is the position of bottom card view.
This trick enables us to replace invisibly bottom card view with CardsViewController’s view and achieve the effect of a draggable card.
When CardsViewController is going to dismiss, it ended at initialY as well.

Magic happens at animateTransition(using transitionContext: UIViewControllerContextTransitioning) method, where described how the transition should work.
1. Getting view controllers, that are involved at transition. MiniToLargeAnimatable protocol is used here to avoid access to CardsViewController explicitly.
2. Setting initial frame and background appearance for presenting view controller.
3. This step is optional in general but required in our situation. Since you’re going to use custom modalPresentationStyle and interactive presentation, view controller lifecycle does not work as expected in this case. You have to track these events yourself.
4. Standard animating block, used to change smoothly frame and background of subviews owned by presented view controller.

By implementing such two animators you’ll have custom transitions for presenting and dismissing of view controller. But wait, are they already interactive and you can drag bottom card? Not yet. One more class is required to make transition interactive with gestures.

Let’s make transition interactive

You need a new class called MiniToLargeViewInteractiveAnimator that inherits from UIPercentDrivenInteractiveTransition. The main thing, that this class does is adding a gesture recognizer to the desired view and updating of the custom transition(implemented at animators above) based on the percent of the swipe made by the user at target view.
Since this class is responsible for managing both present and dismiss, gesture recognizer must be added to appropriate controllers’ views.

1. Store view controllers, involved in transition for later usage. Add gesture recognizer to target view based on present/dismiss case. And slow down completion of the transition by setting completionSpeed.
2. Removing gesture recognizer from view before deallocating animator since you don’t need it anymore. This step does not affect the transition.
3. Just handle all states of gesture and update custom transition based on swipe progress.
4. If you want to finish the transition earlier, you can check whether percent reached the threshold and call finish() method. Let’s ignore call prepareBeingDismissed() for now.
5. When the user ended dragging and transition was still in progress, you need to determine what to do based on shouldComplete property.

Let’s sum up what you have now. You created three classes, responsible for providing custom interactive transition: MiniToLargePresentingViewAnimator, MiniToLargeDismissingViewAnimator and MiniToLargeViewInteractiveAnimator. Now you need to figure out how to use all this stuff with our controllers.

TransitionCoordinator

In order to decouple CardsViewController from StartViewController due to common transition, let’s create a class, called MiniToLargeTransitionCoordinator. It conforms to UIViewControllerTransitioningDelegate and manages our draggable transition. StartViewController holds an instance of transitionCoordinator and calls only its two methods based on conditions.

Method prepareViewForCustomTransition(fromViewController: StartViewController) creates required bindings and interactive animators, instantiates CardsViewController and prepares it for draggable transition. Pay attention to gestureView of animators. On present transition we want bottomTriggerView of StartViewController to be responsive on pan gesture. And on dismiss case, hole view of CardsViewController responds to gesture.
Method removeCustomTransitionBehaviour() is called when you want to remove the possibility to show CardsViewController, including dragging behavior. For instance, when there is no data to show.

And finally MiniToLargeTransitionCoordinator implements required methods of UIViewControllerTransitioningDelegate protocol. These methods will be triggered to replace default transition animation in case of present(…) or dismiss(…) calls from our view controllers.

The only unusual moment here is about isTransitionInProgress check condition. It’s required because custom transition could be performed without interaction via a single tap on the bottom card at StartViewController or with manual dismiss at CardsViewController. In this case, methods must return nil for UIViewControllerInteractiveTransitioning.

Let’s dive into swipe UICollectionView cells

This is how CardCollectionViewCell looks at interface builder. In reality, there’s only one container, that holds different subviews. But I split it into two for providing better visualization. The left container is called frontContentView and represents the content of certain item in array. Specifically, this view will be dragging. On the right side, there is actionsView, that provides buttons to interact with the cell and its content.
In order to make CardCollectionViewCell or your own cell swipeable, inherit it from SwipingCollectionViewCell, which stands for providing swiping behavior.

CardCollectionViewCell is just a plain cell, that shows info to the user. It has one optional extra method frontViewPositionChanged(on percent: CGFloat) from the parent cell, responsible to update properties of subviews while cell’s swiping is in the progress. If you don’t want any UI changes on swipe, this method could be omitted.

Also, there is required override property swipeDistanceOnY. Or, in other words — it is the height of actionsView. Using this property cell determines bounds of swipe area. There’re only two possible states of the cell during the dragging: at the initial position and at the top position.

Let’s look at SwipingCollectionViewCell implementation.

When the cell is loaded from xib file, an initial position of frontContentView is saved as it will be needed later. Then pan gesture recognizer is added via lazy property. When frontContentView will be dragging up or down, visually it will be located outside of the cell’s bounds. So it’s required to set false for clipsToBounds property, otherwise dragging view will be hidden by the bounds of the cell.

Next code will show to you what exactly is going on during the dragging of the cell:

1. When pan gesture is activated, it will have different states. The most interesting for us is .changed state. Right here progress of frontContentView movement is being calculated and based on it you update frames and other properties of cell’s subviews.
2. On the .ended state you determine dragging direction and manually finish the animation.
3.1 and 3.2 methods move frontContentView with animation to appropriate place based on conditions. The unusual thing, that you likely noticed inside both methods is CADisplayLink. It calls animationDidUpdate() with refresh rate of the display. CADisplayLink enables to react fast to all changes that occur during the animation inside UIView.animate block.
4. You take frontContentView frame at a specific time interval during the animation and based on this frame calculate progress of animation. Basically, it is similar to logic inside .change state of handlePanGesture() method.

Important moment

At this moment you have like a card draggable view controller with draggable, scrolling cards inside.
You need to allow different gestures to act simultaneously. Otherwise, it will be a gesture conflict leading to incorrect work of any of the components. Implementation of shouldRecognizeSimultaneouslyWith method from UIGestureRecognizerDelegate protocol is a solution.

We’re done.

Now you know, how interactive transitions work under the hood and how easy it’s to make swiping cells. I believe, that with these bits of knowledge more new opportunities become available and it’s simpler to highlight your app from the crowd.
The full project is available on Github.
If you have any questions or suggestions, feel free to contact me by email or just leave a comment below.
Hope you found this article useful and inspiring. Thanks for reading!