Creating Custom UI Components in Swift: Innostax

Introduction to Custom UI

iOS app development often involves creating unique and attractive user interfaces. While Apple provides a robust set of standard UI components, there are situations where you might need to design and implement custom UI elements to meet specific design requirements. we will explore the process of creating highly custom and reusable UI components in Swift.

What are custom UI components?

Custom UI components are individual, reusable pieces of a user interface (UI) that are designed to be modular and can be used consistently across different parts of an application. These components can be as simple as buttons, text fields, or labels, or more complex elements like navigation bars, card views, or custom list views.

Key Features of Custom UI Components:

1. Modularity: Custom UI components are built as independent units, so they can be reused in multiple places within an app without needing to duplicate the code.
2. Consistency: By using the same custom components throughout the app, developers ensure that the UI has a consistent look and feel, which enhances user experience.
3. Customization: Developers can design the UI components to fit their app’s unique style and requirements, allowing for flexibility.
4. Maintainability: Since these components are reusable, they make it easier to update the design or functionality in one place, which automatically reflects across the app.

Examples of Custom UI Components:

• Buttons: A custom button with specific styles, animations, and actions.
• Input Fields: A text field with custom styling and validation rules.
• Navigation Bars: Custom navigation bars that include branding, custom icons, and specific functionality.
• List Views: A custom list component that shows data in a structured, reusable format.

Understanding the Basics

Before delving into advanced customization, it’s crucial to have a solid understanding of the basics. Custom UI components typically inherit from existing UIKit classes, such as UIView or UIButton. You’ll need to override methods like draw(_ rect: CGRect) and handle user interactions appropriately.

import UIKit

class CustomButton: UIButton {

    // MARK: - Initialization

    override init(frame: CGRect) {
        super.init(frame: frame)
        commonInit()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        commonInit()
    }

    private func commonInit() {
        // Custom initialization code
        // Add subviews, set default properties, etc.
    }

    // MARK: - Drawing

    override func draw(_ rect: CGRect) {
        // Custom drawing code
    }

    // MARK: - Interaction Handling

    override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {
        // Handle touch events
    }
}

Avoiding Memory Leaks and Retain Cycles in Custom Components

Custom UI components have a natural tendency to capture self inside closures that are used as animating, completion handlers, or callback properties that notify parent views about some internal state change. This leads to the creation of a retain cycle, which may result in the component and potentially a parent view not being properly deallocated.

A common source of this is a closure-based callback property, such as var onTap: (() -> Void)?. The closure passed to the component can capture the self, thus forming a retain cycle, which needs to be broken by capturing the weak reference to the component inside the closure. Another place where this pattern can occur is animating, completion handlers for animating. UIViewPropertyAnimator provides several ways to specify a completion handler which can unintentionally capture the reference to the component.

The best way to check for these retain cycles is using the Memory Graph Debugger that is available in the recent Xcode betas. By debugging the memory graph, it becomes apparent if the view controller or component that was deallocated is still retained somewhere, which would explain the memory leak.

Making Components Configurable

To take customization to the next level, you’ll want to make your components highly configurable. This involves exposing properties that allow developers to adjust appearance and behavior. Use property observers and default values to ensure a smooth integration process.

class CustomButton: UIButton {

    // MARK: - Customization Properties

    var cornerRadius: CGFloat = 8.0 {
        didSet {
            layer.cornerRadius = cornerRadius
        }
    }

    var borderColor: UIColor = .black {
        didSet {
            layer.borderColor = borderColor.cgColor
        }
    }

    var borderWidth: CGFloat = 2.0 {
        didSet {
            layer.borderWidth = borderWidth
        }
    }

    // ... Other customization properties

    // MARK: - Initialization and Drawing (unchanged)
    // ...

}

Adding Custom Animation

Create a more engaging user experience by incorporating custom animations. This could include animations for state changes, interactions, or even entry / exit animations. Use the UIViewPropertyAnimator class for smooth and interactive animations.

class CustomButton: UIButton {

    // MARK: - Animation

    func animateSelection() {
        let animator = UIViewPropertyAnimator(duration: 0.3, dampingRatio: 0.7) {
            // Custom animation code
            self.transform = CGAffineTransform(scaleX: 0.9, y: 0.9)
        }

        animator.addCompletion { position in
            if position == .end {
                UIViewPropertyAnimator.runningPropertyAnimator(withDuration: 0.2, delay: 0, options: [], animations: {
                    self.transform = .identity
                })
            }
        }

        animator.startAnimation()
    }

    // MARK: - Interaction Handling

    override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {
        animateSelection()
        super.touchesBegan(touches, with: event)
    }
}

Making Custom UI Components Accessible

One area that’s easy to forget during custom UI component building, and can also go unnoticed, is accessibility. As soon as you override the draw(rect:) function or build a view from scratch, you lose the default accessibility behaviors of UIKit controls. For example, custom button won’t vocalize with VoiceOver anything beyond visually presenting itself on the screen without telling VoiceOver what it does.

This is a simple issue to solve. In order to make VoiceOver speak out what the element actually does, all you have to do is set isAccessibilityElement to true and provide a meaningful accessibilityLabel for it. If your element represents a state of your application, for example a custom switch or toggle button, a selectble or unselectable card, accessibilityTraits and accessibilityValue would let VoiceOver announce when the button or card is on, off, selected or disabled to the user.

Dynamic Type is one such element you’d like to look at too. It might seem quicker to assign a fixed font size and be on your way, but omitting the scalable text fonts (e.g., UIFont.preferredFont(forTextStyle:)) means cutting people who increase their text size beyond system default. Your element, for them, won’t change, while the entire app expands. This is undesirable in terms of look and feel, and a relatively frequent source of user feedback.

I found the only way to catch things is by truly engaging VoiceOver and increasing dynamic type sizes in your system’s Settings. Eyeballing the element only gets you so far when it comes to making things accessible, though you really have to try using what you’ve built from your users’ perspective.

Supporting Interface Builder

Facilitate the usage of your custom components in Interface Builder by adding @IBDesignable and @IBInspectable attributes. This allows developers to preview and configure your components directly in the Interface Builder.

@IBDesignable
class CustomButton: UIButton {

    // ... Existing code

    // MARK: - Interface Builder Support

    @IBInspectable var isRounded: Bool = false {
        didSet {
            layer.cornerRadius = isRounded ? bounds.height / 2 : cornerRadius
        }
    }

    // ... Other inspectable properties

    // ...

}

Best Practices for Testing and Maintaining Custom UI Components

Once an app contains some custom component (e. g., CustomButton), testing and maintainability becomes one of the key points. An untested component often accumulates UI-related inconsistencies each time it is modified.

UI testing with snapshot comparison (iOSSnapshotTestCase or swift-snapshot-testing) is a great way to ensure nothing in your component’s appearance is changing unintentionally. The component is rendered and pixel-by-pixel compared to a reference image — and a developer should review these changes in the code repository. This way, corner radius, text color, and other visual elements are not accidentally changed.

If the component includes any business logic, it should be tested with unit tests as well. The simplest test would be to set up a property (e. g., a corner radius) and check whether it is properly animated or not. Unit tests help to catch breaking changes when a property observer is removed or a property is set to nil.

Good comments in the component’s code are invaluable once the component is used in multiple places. Adding a note about a property’s valid range (e. g., a corner radius) or a behavior description helps other developers to use the component properly without digging into the implementation details.

It is better to move shared components to a separate framework or Swift package rather than keeping them in each app. It allows easier maintenance since a single change propagates to all apps using the component. Otherwise, updating a component would require code review and changes in each repository holding the component’s copy.

Benefits of Creating Custom UI Components

• Custom UI components allow you to infuse your brand’s identity into every aspect of your application. Tailor colors, typography, and design elements, making sure a consistent and recognizable user experience that goes with your brand.
• By crafting unique and visually appealing interfaces, contribute to heightened user engagement. Users are more likely to interact with and remember applications that offer a unique and aesthetically pleasing design.
• Tailored UI components can be optimized for specific functionalities, resulting in improved performance. This optimization ensures that your app runs smoothly, with reduced overhead and increased efficiency, even in resource intensive scenarios.
• Custom UI components provide unparalleled flexibility, allowing swift adaptation to changing requirements. This adaptability ensures that your app remains relevant across iOS updates and various device form factors, enhancing its longevity and usability.
• Designing interfaces with the user in mind leads to improved usability. Custom UI components can be fine tuned to match user expectations, streamlining workflows and enhancing overall user satisfaction through intuitive interactions.
• Stand out in the competitive app market by offering a unique visual identity. Custom UI components empower your application to distinguish itself from others, making a lasting impression on users and potentially easily understood by a larger audience.

Custom UI Components vs. Third-Party UI Libraries: Making the Right Choice

While coding UI components from scratch should not be taken as the default choice, iOS app development teams and clients who opt for custom components rather than utilize a UI library have to consider the trade-offs of such decisions. In practice, the choice between developing in-house UI components and using an existing library is practically situational, as both options allow for creating iOS apps that meet the user’s expectations.

The decision to use an established library like SnapKit for layout needs or Lottie for animation is universally better in terms of time spent and code quality. UI libraries offer developers relatively well-debugged code that does not require any modifications to fulfill the specific expectations of a client or project. With that said, the lack of customization and control is the primary reason why developers sometimes refuse to use such tools. A library-specific component would require extra maintenance to adapt to a specific project’s requirements, whereas developing a UI component from scratch would be more efficient.

Custom UI components are reportedly the best option when building apps that have a unique identity or rely on a specific interface mechanic, as it would be necessary to adjust the interface to match the design in any case. Furthermore, a library-specific UI component may be unsuitable for specific third-party iOS versions, potentially causing issues for the users. Finally, having a custom UI component library can be substantially more convenient in the long run, as the code does not require any updates or adjustments. All things considered, in practice, teams working on iOS apps choose to use a mix of third-party UI components and develop their own components.

Conclusion

Creating highly custom and reusable UI components in Swift involves a combination of inheritance, property exposure, animations, and Interface Builder support. By understanding and implementing these concepts, you can develop flexible components that seamlessly integrate into your iOS projects. Experiment with different customization options and animations to enhance the user interface and provide a polished user experience.
For additional insightful articles and information, please reach out to us.

References

• Swift Documentation