This article was originally published on Hackernoon. It has been duplicated here for those who prefer to read articles on Medium. Enjoy your reading.

TLDR

This guide explores the creation of a retro-style progress bar in iOS, using CALayers for a nostalgic touch. It covers the step-by-step process, from designing each layer to implementing animations, offering insights into combining old-school aesthetics with modern iOS development. Ideal for developers and UI designers, the article provides both technical depth and creative inspiration for unique UI components.

Source Code:

GitHub - maxkalik/RetroProgressBar: A progress bar inspired by old versions of iOS and Mac OS X

I love building UI components. It gives me a kind of aesthetic pleasure to see and use them after making a build. This also combines with my love for the MacOS/iOS ecosystem overall. Recently, I was tasked with creating a custom progress bar using UIKit. It’s not a big deal, but probably 99% of iOS developers have made one from scratch at some point in their careers. In my case, I wanted to do a bit more than just create a couple of CALayers with animations based on a value range from 0 to 1. I was aiming for a solution that would be suitable for many scenarios where a progress bar is needed.

I want to throw myself back to the days when UI components in the Apple world looked like this:

Reflecting on the evolution of UI design, it’s been almost a decade since UI elements in the Apple world adopted a flat design with the introduction of iOS 7 in 2014. So, let’s indulge in nostalgia for the earlier versions of Mac OS and iOS and create a beautiful progress bar together.

If you enjoy using UIKit but are still unsure about how to manipulate CALayers, this article will be useful for you. Here, we will go through typical layout, animation, and drawing challenges, providing insights and solutions to help you along the way.

From UIView deep into CALayers API.

The progress bar might seem straightforward, but if we dive deep into the details, you’ll understand that it requires a lot of sublayers.

I’m not going to delve into CALayersit in detail here. You can check out this article where I briefly described what CALayers are and how they work: https://hackernoon.com/rolling-numbers-animation-using-only-calayers.

So, let’s break it into small layers:

1. General background Layer
2. Mask layer (Animatable part)
3. Progress background Layer
4. Glare Layer
5. Shimmering Layer

The background layer has two additional child layers:

1. Inner shadow Layer
2. Border Gradient Layer

Let’s structure it properly:

RetroProgressBar [UIView]
  |--General background [CALayer]
     |--Inner Shadow [CALayer]
     |--Border Gradient [CALayer]
  |--Progress Background Layer [CALayer]
  |--Animated Mask Layer [CALayer]
  |--Glare [CALayer]
  |--Shimering [CALayer]

Briefly, here’s how it should work: The Progress Bar should react to a value ranging from 0.0 to 1.0. When the value changes, we need to adjust the width of a layer based on this value:

bounds.width * value

Using this simple calculation, we can modify the width using CATransaction. But before we do this, we need to understand which layers should change when the value changes. Let’s revisit the structure and identify the layers that need to be responsive to value changes.

RetroProgressBar [UIView]
  |--General background [CALayer]
     |--Inner Shadow [CALayer]
     |--Border Gradient [CALayer]
  |--Progress Background Layer [CALayer]
  |--Animated Mask Layer [CALayer] : [Animated Width]
  |--Glare [CALayer] : [Animated Width]
  |--Shimering [CALayer] : [Animated Width]

It appears that we need to develop a protocol that can be adopted by the layers that need animated width based on value.

ProgressAnimatable protocol

In protocol, we need just two methods: change the layer’s width with animation and without.

protocol ProgressAnimatable: CALayer {
    
    /// Sets the layer's width instantly to the specified value.
    func setToWidth(_ width: CGFloat)
    
    /// Animates the layer's width to the specified value.
    func animateToWidth(_ width: CGFloat,
                        duration: TimeInterval,
                        animationType: CAMediaTimingFunctionName,
                        completion: (() -> Void)?)
}

Implementation:

extension ProgressAnimatable {

    func setToWidth(_ width: CGFloat) {
        guard width >= 0 else { return }
        
        removeAllAnimations()
        
        CATransaction.begin()
        CATransaction.setDisableActions(true)
 
        self.bounds.size.width = width

        CATransaction.commit()
    }
    
    func animateToWidth(_ width: CGFloat,
                        duration: TimeInterval,
                        animationType: CAMediaTimingFunctionName = .easeInEaseOut,
                        completion: (() -> Void)? = nil) {
        guard width >= 0, width != self.bounds.width else {
            completion?()
            return
        }
        
        let animation = CABasicAnimation(keyPath: "bounds.size.width")
        animation.fromValue = bounds.width
        animation.toValue = width
        animation.duration = duration
        animation.fillMode = .forwards
        animation.isRemovedOnCompletion = false
        animation.timingFunction = CAMediaTimingFunction(name: animationType)
        
        CATransaction.begin()
        CATransaction.setCompletionBlock {
            self.bounds.size.width = width
            completion?()
        }
        
        self.add(animation, forKey: "widthChange")

        CATransaction.commit()
    }
}

Both methods use CATransaction. The first method might seem odd because we only need to change a value without animation. So, why is CATransaction necessary?

Try creating a basic CALayer and changing its width or height without any animation. When you run a build, you’ll notice the CALayer changes with an animation. How is this possible? In Core Animation, changes to layer properties (such as bounds, position, opacity, etc.) are typically animated based on the default action associated with that property. This default behavior is intended to provide smooth visual transitions without the need for explicit animations for every property change.

This means that we need to explicitly disable actions in CALayer. By setting CATransaction.setDisableActions(true), you ensure that the layer's width is instantly updated to the new value without any intermediate animated transition.

The second method offers a flexible and reusable way to animate the width of any layer conforming to the ProgressAnimatable protocol. It provides control over the animation's duration and pacing and includes an option for a completion action. This makes it well-suited for various animation needs within the UIKit framework.

Our candidates to conform to this protocol will be three layers: Animated Mask Layer, Glare Layer, and Shimmering Layer. Let’s go ahead and implement it.

ProgressMaskLayer

It’s time to conform to our protocol, and the most important layer in this setup will be our general CAShapeLayer. Why do we need this mask? Why can't it just be a CALayer with an animated width? As an iOS Engineer, especially one focusing on front-end development, you often need to anticipate potential use cases for your components. In my instance, there is a Progress Background Layer. This isn't an animated CALayer, but what if it were animated with something like CAReplicatorLayer? If you're concerned about performance, you'd likely consider that such a layer should be rendered once and then simply perform its animation. That's why this mask can be extremely useful. It allows for efficient rendering while still offering the flexibility needed for various animation scenarios.

final class ProgressMaskLayer: CAShapeLayer, ProgressAnimatable {

    override init() {
        super.init()
        
        backgroundColor = UIColor.black.cgColor
        anchorPoint = CGPoint(x: 0, y: 0.5)
    }

    override init(layer: Any) {
        super.init(layer: layer)
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

Let’s take a look at this line:

anchorPoint = CGPoint(x: 0, y: 0.5)

This line is crucial for our Progress Bar. By default, CALayers are centered, with the anchorPoint located at the center of the layer, not on the middle of the left edge as commonly assumed. The anchorPoint is the point around which all transformations of the layer occur. For a layer used as a progress bar, this setting typically means that when the layer's width changes, it expands equally in both directions from the anchorPoint. However, if we adjust the anchorPoint to the middle of the left edge, the layer will expand only to the right while the left edge remains fixed in place. This behavior is essential for a progress bar, ensuring that the growth of the bar appears from one side rather than both.

private let progressMaskLayer = ProgressMaskLayer()
private let progressBackgroundLayer = ProgressBackgroundLayer()

public init() {
        super.init(frame: .zero)

        layer.addSublayer(progressMaskLayer)
        layer.addSublayer(progressBackgroundLayer)
        
        progressBackgroundLayer.mask = progressMaskLayer

}

In the snippet above, we initialize two main parts of the Progress Bar: ProgressMaskLayer and ProgressBackgroundLayer. Let’s take a look at the second one.

final class ProgressBackgroundLayer: CAGradientLayer {
    
    override init() {
        super.init()

        locations = [0, 0.5, 1]
    }

    override init(layer: Any) {
        super.init(layer: layer)
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    override func layoutSublayers() {
        super.layoutSublayers()

        colors = [
            backgroundColor?.lightened(by: 0.3),
            backgroundColor,
            backgroundColor?.darkened(by: 0.5)
        ].compactMap({ $0 })
    }
}

As you can see, it’s a CAGradientLayer featuring three colors. This implementation transforms an injected color into a vertical gradient, enhancing the visibility of the progress bar and giving it a more voluminous appearance.

To make this possible, I prepared two methods in a CGColor extension. For fun, I chose not to convert CGColor back to UIColor, but to play solely within the realm of CGColor:

extension CGColor {
    func darkened(by value: CGFloat) -> CGColor {
        guard let colorSpace = self.colorSpace,
              let components = self.components,
              colorSpace.model == .rgb,
              components.count >= 3 else {
            return self
        }

        let multiplier = 1 - min(max(value, 0), 1)
        let red = components[0] * multiplier
        let green = components[1] * multiplier
        let blue = components[2] * multiplier
        let alpha = components.count > 3 ? components[3] : 1.0

        return CGColor(
            colorSpace: colorSpace,
            components: [red, green, blue, alpha]
        ) ?? self
    }
    
    func lightened(by value: CGFloat) -> CGColor {
        guard let colorSpace = self.colorSpace,
              let components = self.components,
              colorSpace.model == .rgb,
              components.count >= 3 else {
            return self
        }

        let red = min(components[0] + value, 1.0)
        let green = min(components[1] + value, 1.0)
        let blue = min(components[2] + value, 1.0)
        let alpha = components.count > 3 ? components[3] : 1.0
        
        return CGColor(
            colorSpace: colorSpace,
            components: [red, green, blue, alpha]
        ) ?? self
    }
}

As you can see, it’s not too complicated. We just need to getcolorSpace, components (red, green, blue, and alpha), and model. This means that based on the value, we can calculate a new color: either darker or lighter.

Glare

Let’s move towards making our Progress Bar more 3D-ish. Now we need to add another layer, which we’ll call Glare.

It’s a straightforward implementation, but it should conform to the ProgressAnimatable protocol.

final class ProgressGlareLayer: CALayer, ProgressAnimatable {
    
    override init() {
        super.init()

        backgroundColor = UIColor.white.withAlphaComponent(0.3).cgColor

        anchorPoint = CGPoint(x: 0, y: 0.5)
    }

    override init(layer: Any) {
        super.init(layer: layer)
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

To keep things simple, we only need the background color here to be white with an alpha of 0.3.

Little Nice Shimmering

I know some might say that MacOS X or iOS before version 6 didn’t have UI components with shimmering effects like this. But, as I said, this is like a movie inspired by a real story. This shimmering accentuates the 3D effect and makes it more visible.

final class ShimmeringLayer: CAGradientLayer, ProgressAnimatable {

    let glowColor: UIColor = UIColor.white
    
    private func shimmerAnimation() -> CABasicAnimation {
        let animation = CABasicAnimation(keyPath: "locations")
        animation.fromValue = [-1.0, -0.5, 0.0]
        animation.toValue = [1.0, 1.5, 2.0]
        animation.duration = 1.5
        animation.repeatCount = Float.infinity
        return animation
    }
    
    private func opacityAnimation() -> CABasicAnimation {
        let animation = CABasicAnimation(keyPath: "opacity")
        animation.fromValue = 1.0
        animation.toValue = 0.0
        animation.duration = 0.1 // Quick transition to transparent
        animation.beginTime = shimmerAnimation().duration
        animation.fillMode = .forwards
        animation.isRemovedOnCompletion = false
        return animation
    }
    
    private func animationGroup() -> CAAnimationGroup {
        let pauseDuration = 3.0 // Duration of pause between shimmering
        let shimmerAnimation = shimmerAnimation()
        let opacityAnimation = opacityAnimation()
        let animationGroup = CAAnimationGroup()
        
        animationGroup.animations = [shimmerAnimation, opacityAnimation]
        animationGroup.duration = shimmerAnimation.duration + pauseDuration
        animationGroup.repeatCount = Float.infinity
        
        return animationGroup
    }

    override init() {
        super.init()

        setupLayer()
    }

    override init(layer: Any) {
        super.init(layer: layer)
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    override func layoutSublayers() {
        super.layoutSublayers()

        startAnimation()
    }
    
    private func setupLayer() {
        let lightColor = UIColor.white.withAlphaComponent(0.7).cgColor
        let darkColor = UIColor.white.withAlphaComponent(0).cgColor
        
        colors = [
            darkColor,
            lightColor,
            darkColor
        ]
        
        anchorPoint = CGPoint(x: 0, y: 0.5)
        locations = [0.0, 0.5, 1.0]
        startPoint = CGPoint(x: 0.0, y: 0.5)
        endPoint = CGPoint(x: 1.0, y: 0.5)

        shadowColor = glowColor.cgColor
        shadowRadius = 5.0
        shadowOpacity = 1
        shadowOffset = .zero
    }
    
    private func startAnimation() {
        if animation(forKey: "shimmerEffect") == nil {
            let animationGroup = animationGroup()
            add(animationGroup, forKey: "shimmerEffect")
        }
    }
}

Here, we need two animations (Opacity and Location) combined into a CAAnimationGroup. Also, using CAAnimationGroup allows us to arrange a pause between animation sessions. This feature is quite useful because clients might want to control this property as well.

As you can see in the picture, this adds more 3D effects, but it’s not quite enough. Let’s move forward.

Background Layer

We need to work with our static background layer, which lies beneath the animated Progress Line. If you recall, we have two additional sublayers there: the Inner Shadow and the Border Gradient.

|--General background [CALayer]
     |--Inner Shadow [CALayer]
     |--Border Gradient [CALayer]

I would say these two layers were quite popular in search queries several years ago, possibly due to UI trends. Let’s create our own versions and immortalize them in this article for future generations :)

Inner Shadow Layer

The class is designed to create a layer with an inner shadow effect, which can be a visually appealing way to add depth to UI elements.

final class InnerShadowLayer: CAShapeLayer {

    override init() {
        super.init()
        
        masksToBounds = true
        shadowRadius = 3
        shadowColor = UIColor.black.cgColor
        shadowOffset = CGSize(width: 0.0, height: 1.0)
        shadowOpacity = 0.5
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    override func layoutSublayers() {
        super.layoutSublayers()
        
        // Creates a path for the shadow that extends slightly outside the bounds of the layer.
        let shadowPath = UIBezierPath(roundedRect: bounds.insetBy(dx: -5, dy: -5), cornerRadius: cornerRadius)
        // Creates a cutout path that is the inverse of the layer's bounds.
        let cutoutPath = UIBezierPath(roundedRect: bounds, cornerRadius: cornerRadius).reversing()

        shadowPath.append(cutoutPath)

        self.shadowPath = shadowPath.cgPath
    }
}

We need a CAShapeLayer because we have to set shadowPath. For that, we need to create a path for the shadow that extends slightly outside the bounds of the layer using insetBy from bounds. And then another UIBezierPath — a cutout path that is the inverse of the layer’s bounds.

In the illustration, it’s already almost there. But we need the last layer which will bring us back to MacOS X Leopard.

Border Gradient Layer

It’s a subclass of CAGradientLayer designed to create a gradient border around a layer. It uses a CAShapeLayer as a mask to achieve the border effect. The shapeLayer is configured with a stroke color (initially black) and no fill color and is used as the mask for the BorderGradientLayer. This setup allows the gradient to be visible only where the shapeLayer has a stroke, effectively creating a gradient border.

final class BorderGradientLayer: CAGradientLayer {
    
    let shapeLayer: CAShapeLayer = {
        let layer = CAShapeLayer()

        layer.strokeColor = UIColor.black.cgColor // Temporary color
        layer.fillColor = nil
        return layer
    }()
    
    init(borderWidth: CGFloat, colors: [UIColor]) {
        super.init()

        self.mask = shapeLayer
        self.colors = colors.map { $0.cgColor }
        self.setBorderWidth(borderWidth)
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    override func layoutSublayers() {
        super.layoutSublayers()
        
        shapeLayer.path = UIBezierPath(roundedRect: bounds, cornerRadius: cornerRadius).cgPath
    }
    
    func setBorderWidth(_ borderWidth: CGFloat) {
        self.shapeLayer.lineWidth = borderWidth
    }
}

The initializer of BorderGradientLayer accepts a borderWidth and an array of UIColors for the gradient. It sets up the gradient colors, applies the border width to the shapeLayer, and uses the shapeLayer as a mask to restrict the gradient to the border area.

The layoutSublayers method ensures that the path of shapeLayer is updated to match the layer's bounds and corner radius, making sure the border fits the layer correctly. The setBorderWidth method allows dynamic adjustment of the border's width after initialization.

Way better. Ok. let’s stop making visual stuff and let’s work on the logic.

All together.

Now it’s time to combine all these layers and let them into life.

private lazy var backgroundLayer = BackgroundLayer(
        borderWidth: borderWidth,
        colors: borderColors
)
    
private let glareLayer = ProgressGlareLayer()
private let shimmeringLayer = ShimmeringLayer()
private let progressMaskLayer = ProgressMaskLayer()
private let progressBackgroundLayer = ProgressBackgroundLayer()
    
public init() {
        super.init(frame: .zero)
        
        layer.backgroundColor = UIColor.white.cgColor
        layer.masksToBounds = true
        
        layer.addSublayer(progressMaskLayer)
        layer.addSublayer(progressBackgroundLayer)
        layer.insertSublayer(backgroundLayer, at: 0)
        
        
        progressBackgroundLayer.addSublayer(shimmeringLayer)
        progressBackgroundLayer.addSublayer(glareLayer)
        
        progressBackgroundLayer.mask = progressMaskLayer
}

Let’s take a look at how we going to deal with all layers which should change their width with animation:

public func setValueWithAnimation(_ value: Double,
                               duration: TimeInterval = 1.0,
                               animationType: CAMediaTimingFunctionName = .easeInEaseOut,
                               completion: (() -> Void)? = nil) {
        
        let newWidth = calculateProgressWidth(value)
        let animationGroup = DispatchGroup()

        animationGroup.enter()
        shimmeringLayer.animateToWidth(
            newWidth - WIDTH_ANIMATABLE_INSET,
            duration: duration,
            animationType: animationType,
            completion: animationGroup.leave
        )
        
        animationGroup.enter()
        progressMaskLayer.animateToWidth(
            newWidth,
            duration: duration,
            animationType: animationType,
            completion: animationGroup.leave
        )
        
        animationGroup.enter()
        glareLayer.animateToWidth(
            newWidth - WIDTH_ANIMATABLE_INSET,
            duration: duration,
            animationType: animationType,
            completion: animationGroup.leave
        )

        animationGroup.notify(queue: .main) {
            completion?()
        }
}

First, we need to prepare a width from a value. The value should be less than 0 and greater than 1. Plus we need to take into consideration a possible border width.

fileprivate func normalizeValue(_ value: Double) -> Double {
    max(min(value, 1), 0)
}

private func calculateProgressWidth(_ value: Double) -> CGFloat {
        let normalizedValue = normalizeValue(value)
        let width = bounds.width * normalizedValue - borderWidth
        return width
}

For the correct 3D effect, glare, and shimmering layers should be with a little padding from the right and left sides:

newWidth - WIDTH_ANIMATABLE_INSET

And finally, the method uses an animation group (DispatchGroup) to synchronize the animations of three layers: shimmeringLayer, progressMaskLayer, and glareLayer. Each layer's width is animated to the calculated width (adjusted by WIDTH_ANIMATABLE_INSET for shimmeringLayer and glareLayer to fit the design) over the specified duration and with the specified animation curve.

The animations are coordinated using the DispatchGroup, ensuring that all animations start simultaneously and the completion closure is called only after all animations have finished. This method provides a visually appealing way to update the progress bar's value with a smooth, synchronized animation across its various decorative layers.

Source Code

The latest version exists as a Swift Package and Pod. Btw, contributions are welcome!

GitHub - maxkalik/RetroProgressBar: A progress bar inspired by old versions of iOS and Mac OS X

Usage

Create an instance of RetroProgressBar. You can add it to your view hierarchy as you would with any UIView.

let progressBar = RetroProgressBar()

Customization:

progressBar.progressColor = UIColor.systemBlue
progressBar.cornerRadius = 5.0
progressBar.borderWidth = 2.0
progressBar.borderColors = [UIColor.white, UIColor.gray]

To change value with animation:

progressBar.setValueWithAnimation(0.75, duration: 1.0, animationType: .easeInEaseOut) {
    print("Animation Completed")
}

Without animation:

progressBar.setValue(0.5)

Final Thoughts

Recreating this old-style progress bar has been a nostalgic dive into the aesthetics I deeply miss. Working with UIKit andCALayer reminded me of the versatility and power of our tools as developers. This project wasn't just about technical implementation; it was a journey back to a beloved design era, proving that we can still craft anything, including the timeless charm of older designs.

This experience has been a poignant reminder that in UI design, simplicity and nostalgia can coexist beautifully, bridging past and present.

Happy coding!

Want to Connect?
Feel free to follow me on Twitter.
To learn more about me, check out my interview on Hackernoon.
I welcome and appreciate any feedback, suggestions, or comments
on my research and articles.

Recently, I was interviewed about mobile app development. I’ve curated the most intriguing questions and consolidated my insights into this article, which might be useful for those in non-technical roles from small/mid-size businesses. I welcome you to join the discussion in the comments.

When it comes to mobile app development, do you recommend hiring an in-house team or partnering with a mobile app development agency? While budget is a significant factor, which option do you believe delivers better quality, and why?

It is a super individual and depends on the business’s specific needs, budget, constraints, and targets. If a project is already well funded, and implies the long-term vision of updates and iterations, then, I would say an in-house team would be better. Generally, if a project has a specific budget and well-prepared plan, then it could be better to find a dev agency that would commit service to create everything based on an agreement.

Let me provide some examples. Consider a mobile application for a dance festival somewhere, where people can see lineups, a map, some information, and so on. Does this app need a specific in-house team to develop? I think, not.

Another example. Consider a project that potentially in the future could be a huge thing. There is a founder who decides how it would be better to hire, but mostly from my experience, that kind of project is developed by an in-house team. Especially if the projects are already well funded. Founders prefer to invest in developers who will make a product at the next desk in the office.

The last example. Consider a project in which you have to use a really specific technology, and this technology can be used by one of a kind. Let’s say an agency can provide a service to develop a feature using this specific technology. So, if deadlines are really close, a dev agency could be useful.

Gartner sees architecture as the heart of a mobile app. Do you agree? If yes, please state a one-liner reason for it.

Agree, because it helps developers communicate with each other by maintaining, scaling, and creating new application components.

Can you break down the different types of mobile app architectures? And in your opinion, which is the best fit for today’s small businesses? We’re curious because there’s a common belief that PWAs might be superior to Hybrid and Native apps.

Native iOS / Android Apps, Cross-Platform Apps (Flutter, React-Native), Hybrid Apps (Xamarin, Ionic), Web Apps (React, Vue), Progressive Web Apps (PWDs) and Server-Driven UI (Lona). In the case of small businesses, from my perspective, I see the tendency to use cross-platform technologies in start-ups, especially in Europe. I explain this to myself so: Time is money, which means the biggest cost is — developer hours. If a business doesn’t need a specific API, higher performance, and more rich UX then why not save money? In the case of PWAs it’s getting really interesting: No need for app store submission (It’s a huge thing in my opinion). In the case of iOS platforms, iOS 16.4 (released in Spring 2023) already brings push notifications for web apps. An App Can be added to the home screen, in MacOS users can add PWA to the Dock.

In the initial brainstorming and discussion phase, what core elements do you focus on when thinking about a new mobile app’s architecture?

Initially, I’m trying to grab information about business requirements, target audience, platforms, and expected user experience. From a technical perspective, it’s important to discuss which technology / API can be more useful, and how reusable, and scalable a mobile app project should be.

How do you define the primary purpose of an app — Is there a checklist or a set of guidelines you follow?

Yes, exactly I have a checklist. Basically, there are a set of questions about analyzing competitors, market trends, target audience, feature set discussion, deadlines, prioritization, and so on.

When researching the target audience, what tools or methodologies do you employ to understand their OS preferences and needs?

I can only say if a product has already launched. I’m a big fan of two platforms: Google Analytics, Amplitude

Based on your experience, which demographic tends to gravitate more towards iOS, and which one leans towards Android?

I think a typical iOS user is from a Western country and can be ready to spend money on app purchases and in-app transactions. iOS user is younger than a typical Android user. In the case of Android users, I see that the cost of a device matters to them. Also, I know a lot of developers who really love to customize their devices. By the way, Apple also tries to attract more audiences by offering more and more customization of iOS.

iOS or Android, which app development is better per your experience? This is a frequently asked question.

As an iOS Developer, I prefer technologies from Apple. Let’s consider SwiftUI — a declarative framework for building UI in Apple platforms. If to compare SwiftUI with Flutter, then it’s easy to see the resemblance. The general tendency in my opinion is to as much as possible to simplify building UI and allow developers to focus on solving business problems.

How do you “proofcheck” an app idea? What are the top resources, like GitHub, that you might recommend for checking free source codes or similar ideas?

I just google it, and use GitHub or GitLab to check sourcode if it’s possible, cannot say anything new here.

When establishing an app development team, what roles such as project manager, UI/UX designer, assistant coder, quality analyst, app developer, marketing, or product manager to check the app for market fit, do you deem essential, and why?

The app development team is who directly impacts the project’s success. From my experience, the typical small team is Mobile Developers, Backend Developers, QA / Tester, UI/UX Designer, Legal Advisor, Product Manager, and Data Analyst.

How do you prioritize and decide on core features for an app? Can you share an instance where a feature seemed essential but was later dropped based on practicality or user feedback?

In small teams, there is not so much time to play a role in a large company where stakeholders discuss core features and prioritize spending expensive time of developer hours. Mostly priorities and core features are born from business initiatives (from founders). Consequently, sometimes even core features are turning out to be not so important and even can be dropped. In my current iOS project, we had a main screen with a scroll without even a bottom tab bar, which means all navigation happened by scrolling this main content. When we launched our beta version we started to get user feedback (via Intercom) where they asked how to find a particular section. So the primary idea of having everything on one single screen was dropped and we made a predicted UI — bottom tab bar.

What are the must-have toolkits and software packages for mobile app developers today? Please do mention the purpose of any you mention here.

IDE: Xcode (for iOS or cross-platform developers) — it has everything you need to build iOS apps: editor, simulators, debugging tools, instruments, and so on; Android Studio (for Android and cross-platform developers) — it has an editor, emulator, and debugger. If a mobile developer is making hybrid mobile apps using Xamaring or Unity then the IDE could be Visual Studio or Rider from Jet Brains. These IDEs help to make C# projects and .NET. (In my personal experience, I used almost all these IDEs at once, especially when I needed to make an API between Swift and C# for Unity). When I was a React-Native developer, I used a lot Visual Studio Code. I would say VSCode (btw it’s free) can help a lot if your project has a backend, so it could be a useful editor for backend purposes.

Of course, developers should use source control tools like GitHub, GitLab, or Bitbucket.

The last thing is packages, and it really depends on the project you are working on.

The most common technology that helps small/mid-size businesses is Firebase — it scales you from nothing to everywhere, but it depends on how much money costs each user for you. If it’s going to be millions of users, then Firebase is getting really aggressively expensive. The stage of mid-size companies if they still use Firebase they need to forecast the future of user amount and the number of requests from the client.
AWS Amplify — provides scalable and secure cloud services for mobile applications.
Network handling and HTTP requests: Alamofire (iOS), Retrofit/Volley (Android).
CI/CD Automation — Fastlane, CircleCI, or GitHub Actions.
UI/UX — Figma

All team members can communicate via Slack. Tasks can be organized in traditional Jira or more modern Linear.

Monitoring and analysis can be handled well by Crashlytics, I would say it’s one of the best tools to identify app crashes. In the case of iOS development, XCode provides an organizer where a developer can retrieve detected crashes from App Store Connect.

How important are mockups and wireframes in the development process? How do you ensure that the UI/UX meets user expectations? Do you think UI/UX agencies are a great option to partner with, for SMBs?

In simple words, at this stage, businesses can save money and avoid mistakes, such as an unsuccessful feature that had to be dropped.

Through experimenting with UI/UX designs, conducting tests, and aligning with best practices, you’re more likely to meet or even exceed user expectations. Also, the more detailed and well-prepared wireframe — saves the time of mobile developers.

With rising concerns about data privacy, how do you ensure an app complies with data protection guidelines, like GDPR?

In my experience, we (including mobile developers) constantly test and check apps for data protection guidelines. Written tests, flexible database, transparent communication with users about how their data will be used and stored — all these things make an app data protected.

Can you share some best practices for coding and programming? What does the KISS (Keep it short and simple) principle mean to you in the context of app development? Or any other principle that you practice?

Code should be well-readable, reusable, well-documented, and tested. A lot of books and articles written about this. The KISS principle is about readability. If a developer can write short and simple code then other developers will spend less time to understand it. Simplifying code makes it easier to read, maintain, and debug. Also, I would highlight more principles: SOLID (actually five design principles aimed at making software designs more understandable, flexible, and maintainable. They include Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle.); DRY (Don’t Repeat Yourself): This principle encourages code reusability. If you find yourself writing the same code more than once, it’s often better to create a function or module that can be reused. Plus, I would add a rule here called The Boy Scouting Rule that states “Always leave the code you are working on a little bit better than you found it”. I took it from Robert C. Martin’s book.

Why do you think many apps fail? From a developer’s perspective, what are the common pitfalls to avoid?

I think the biggest reason of app fails is a lack of market research and unrealistic expectations. From a technical perspective there are a lot of various pitfalls: ignoring questions of scalability, underestimated server burden, technical dept, bad testing, and eventually bad reviews, all these things dragging apps down.

When testing an app, what’s your approach? Does testing include everything from frontend, backend, device compatibility, integration, etc.?

My approach is to keep a mobile app as stable as much as possible and always keep it ready for release. Using a unit, UI, and other tests can be of course automated. In mobile development, it’s also important to test performance, memory usage, and device compatibility.

Are there any tools or frameworks you swear by for comprehensive testing?

As a Mobile Developer, I use XCTest and XCUITest for iOS, and JUnit, Espresso / UI Automator for Android. Also, I like to use Crashlytics for real-time crash reporting, Postman for API testing, and Jest, Mocha, and Chai for Backend Java Script project testing.

How important is user feedback before the official launch? Can you recommend any professionals or groups that businesses should consider for feedback?

Before the official launch, for example in the case of iOS, it’s great to use Testflight with a group of testers who can provide relevant and really important feedback. Even just friends who can test an app in an unexpected way, their feedback will help a lot. It would be also great to have some industry experts who can give specific comments that could be important before the official launch.

For deploying apps, what are your thoughts on server choices? Shared vs. dedicated cloud servers — pros and cons?

Choosing between shared and dedicated servers on GCP should be guided by your app’s resource requirements, security needs, and scalability plans. Shared Cloud Servers, like those offered by AWS’s EC2 or DigitalOcean’s Droplets, are budget-friendly and easy to manage, making them a good fit for small businesses or apps just starting out. However, they can suffer from limited resources and potential security risks due to shared infrastructure. On the other hand, Dedicated Cloud Servers, such as AWS’s EC2 Dedicated Hosts or Azure’s Virtual Machines, provide better performance, scalability, and security but come at a higher cost. These are more suitable for complex, resource-intensive apps that anticipate rapid growth. Your choice should align with your app’s current needs and future scalability.

I prefer Google Cloud Platform (GCP) also offers both shared and dedicated cloud server options, fitting different needs and budgets.

Once an app is live, how do you prioritize updates and patches? Is there a regular schedule or is it based on user feedback and security needs?

I think It’s really useful for a mobile app when a team defines a cadence of releases. I prefer 2–3 weeks, for small updates that could include new features, bug fixes, and other small updates. Based on user feedback, and business initiatives the updates are prioritized mostly together with a product manager.

What are some of the biggest challenges you’ve faced in mobile app development, and how did you overcome them?

My biggest challenge was to create a flexible and scalable API between iOS SDK and Unity using undocumented techniques to bridge these two worlds. Without sufficient information on the internet, I managed to describe a quite detailed iOS API with methods for any kind of use in the Unity project.

From your experience, can you highlight a few key benefits of collaborating with a professional mobile app development company?

From my experience, it was a collaboration with a company that provided a customized SDK (User identification) solution for our app. We didn’t need to make this feature from scratch. The twice-weekly meetings kept everyone aligned and allowed us to discuss problems in real-time. The specialized Slack channel became a hub for quick questions and clarifications, making the entire process more efficient. Eventually, it saves us months of developer time.

To wrap up, what’s your one golden piece of advice for small businesses venturing into mobile app development?

Keep a small and focused full-stack team and hire only senior developers in the beginning
Use external services whenever possible
Use no-code tools (like Retool or Webflow)

Mobile App Development in Small to Mid-Sized Businesses. was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the approximate period of March 21 and 28, we will see a new release of iOS 16.4. About a month a beta version was available for download. I tested this version focusing on the push notification for web apps and I have my personal thoughts about this and I would like to share them with the iOS and Web developers community.

Why are push notifications important for web apps?

First of all, this is a significant improvement for iOS overall. Notifications are equally important for both regular mobile and web applications because they have the same goal — to have contact with the audience. But I think Apple has a plan to spice up the market to make artificial competition with native apps. This diversity will bring a different experience where a user can choose between native and web apps.

Are web apps really a good alternative to native apps?

In the case of mobile applications, then it is too early to say which is better because we will only see this web app integration into the iOS ecosystem and learn statistics. Of course, for now, native apps look more robust and stable. Using native applications gives a different experience compared with web apps. On the other hand, building a web app is a bit easier than native apps, which means startups can build first their web versions before native implementations. Or large companies like Twitter can get more audience to provide two options — web and native.

What would you like to see added to web app capabilities on iOS?

Improving access to native device features such as camera, microphone, and contacts. Also, it will be cool to improve access to persistent data like user defaults. If web apps could be used absolutely offline then they could be on the same level as native apps. Push notifications also can be improved, for example by grouping and prioritizing them. Another important thing is performance, improving this field can make web apps more competitive.

Conclusion

I think all these updates are only a rehearsal — a part of unifying mobile and desktop interfaces — most likely what we will see in the future let’s say in iOS 17 or later. Web apps and native apps — it won’t matter anymore. If to try to predict then it seems we will get a combination between MacOS, iPadOS, and iOS called something like AppleOS or so.

Links

• Release notes: https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-16_4-release-notes
• Web push notifications for web apps: https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/
• iOS 16.4 Beta version: https://developer.apple.com/news/releases/?id=03152023d

iOS 16.4 brings push notifications for web apps — why that’s a big deal? was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my current iOS position, I’m deeply involved in building a framework for iOS games. I wouldn’t write this article if this framework weren’t unusual. What do I mean by that — unusual? Usually, frameworks encapsulate only the source code without dependencies and other libraries, and of course, I don’t mean Foundation and other build frameworks in iOS. I mean the dependencies installed using cocoapods which for some business reason could be included in your framework manually.

Recently I wrote an interesting detailed article/analysis about how to create an iOS XCFramework with cocoapod dependencies, so if it’s your case check this out: https://hackernoon.com/cocoapod-as-xcframework-with-dependencies

In this article, we will build only a manual framework with other frameworks inside statically. I admire it’s a pretty rare case but businesses sometimes dictate their terms where we — developers should implement a workable solution quickly.

Final product

The task is to create a simple framework only for real devices with dependencies that can be installed via cocoapod. Where we could use this framework? In Unity! You can read my article about this here. But let’s move forward and start to create our final product.

Podfile

Assume, we created a new iOS Framework project. I named it MyFramework and in the terminal run pod init in the root of the project folder, so we have Podfile where we can start. Let’s configure it:

platform :ios, '14.0'

source 'https://cdn.cocoapods.org/'
source 'https://github.com/passbase/cocoapods-specs.git'
source 'https://github.com/passbase/microblink-cocoapods-specs.git'

target 'YourFramework' do
  pod 'CropViewController', '2.6.1'
  pod 'Kingfisher', '7.5.0'
  pod 'Intercom', '14.0.6'
  pod 'Frames', '4.0.4'
  pod 'Passbase', '2.7.0'

end

I didn’t use some abstract cocoapods, I took the real ones on purpose to show you the real process which you could repeat by yourself. At the first sight of the list of dependencies, you could say that they are picked randomly. And yes and no, because all these dependencies are different ones, for example:

• Kingfisher — it’s just a piece of source code
• CropViewController — also with source code but with a bundle of the resource
• Intercom is interested to be in this list because it’s an xcframework itself
• Frames dependency is here because it’s a combination of source code and some sub-dependencies inside including xcframeworks
• Passbase is one of the most interesting specimens because to install this guy we need to use specific source paths including an additional source path for Passbase’s dependency called Microblink. All of them are xcframeworks.

Testing all these various dependencies we will create a framework for manual installation.

Resources

If a framework uses resources (images, video, or other files), then we need to prepare a separate target for it and this process looks a little bit like a workaround. Let me describe it step-by-step:

1. Open File / New / Target. Choose macOS and in the Framework & Library section choose Bundle.

2. For now, make sure the resource files belong to this target.

3. Go to Project target / Build phases / Copy Bundle Resources and remove and exclude everything there except the bundle.

4. The last step is not obvious but necessary. Do you remember we created this bundle for MacOS but we need it for iOS? So, go to Build Settings of the framework bundle and change Architectures / Base SDK to iOS.

5. Also in Framework target Build Phases we need to include our bundle as a target dependency.

Build

Xcode has a powerful CLI to make an archive using xcodebuild with a set of flags:

xcodebuild archive \
-workspace MyFramework.xcworkspace \
-scheme MyFramework \
-configuration Release \
-sdk iphoneos \
-archivePath archives/ios_devices.xcarchive \
BUILD_LIBRARY_FOR_DISTRIBUTION=YES \
SKIP_INSTALL=NO \

This simple script creates an archive. Open it with the right mouse button using “Show content” and find a fresh-backed framework in the products.

Now the framework is ready to be tested. You can just drag this framework to your test iOS project structure. Don’t forget to Embed and Sign this framework. Choose a real device where we are going to test our app with this framework.

The result will be not so good. The project will give you an error — Build failed.

The reason is our dependencies are not found, they weren’t included in our framework. So let’s solve this problem.

Including dependencies to a framework

Since we install our dependencies using cocoapod we need to update Podfile. By default, the pods are installed with dynamic linking but we need to install them with static linkage.

platform :ios, '14.0'

source 'https://cdn.cocoapods.org/'
source 'https://github.com/passbase/cocoapods-specs.git'
source 'https://github.com/passbase/microblink-cocoapods-specs.git'

target 'YourFramework' do
  use_frameworks! :linkage => :static

  pod 'CropViewController', '2.6.1'
  pod 'Kingfisher', '7.5.0'
  pod 'Intercom', '14.0.6'
  pod 'Frames', '4.0.4'
  pod 'Passbase', '~> 2.7.0'

end

So the main update of our Podfile is updating this particular line: use_frameworks! to use_frameworks! :linkage => :static

The next step is not very obvious (I would say even questionable) because we need to include all dependencies’ frameworks to our framework literally by copying them from the Products folder of Pods into our project.

If doing this manually, you need to Run the framework project first, then you will get the Products folder with frameworks from each pod including their bundles.

To get there you can right-click on any framework in the Products folder and press Open in Finder.

From each dependency folder, you need to find a folder with a name something like Name.framework, and drag and drop it to your Framework project. By the way, we don’t need to include frameworks’ resource bundles in our project because they will be included automatically.

But, even here we can come across with small nuance. As you remember some of our dependencies are XCFramework, and the folder where supposed to be these frameworks are empty.

Among all the product folders you can find a specific one called: XCFrameworkIntermediates where you can find all frameworks from XCFrameworks.

So, your project structure should look like this:

Another important thing about frameworks from XCFrameworks is — we need to embed and sign them in our Framework.

After all these manual manipulations, you can build your framework again and get the final product which you can test. If you did everything correctly, then your project with the new framework will run successfully and all methods from the framework will work without failures.

Potential problems

Traditionally, instead of a conclusion, which nobody cares about, I think it will be better to list some potential problems and how to solve them. Let’s get started.

Problem 1: Library not loaded.

Basically, it is an error always together with this message:

dyld[17871]: Library not loaded.
'@rpath/MyFramework.framework/MyFramework'

Solution:
One of the most often errors. We are all people and we can just forget to sign the framework.

Problem 2: Error: Compiled module was created by a newer version of the compiler.

In your build script of xcodebuild, you most likely forgot to add this flag: BUILD_LIBRARY_FOR_DISTRIBUTION

Problem 3: Build failed. A client uses the same dependencies which your framework already uses.

Solution:
Briefly: Versions of the dependencies in a framework and in an app should be the same.
Detailed: Let’s say you build your framework with cocoapod Alamofire 5.5.0and a client app will use your framework and Alamofire 6.0.0, so this combination will cause a problem. In other words, you cannot build your app, and you won’t understand what is going on, because the error will be about symbols, or something else.

pod 'Intercom', '2.0.0'
pod 'Alamofire', '5.5.0'

Problem 4: The path to your product is not found (the product folder in the archive is empty)

Solution:
Check flag: SKIP_INSTALL=NO in your build script — it will install your framework in the archive, in other words, your product folder won’t be empty.

Problem 5: Property is not a member type of class MyFramework.MyFramework

.../MyFramework.swiftinterface:6:34: error: 'SomeProperty' is not a member type of class 'MyFramework.MyFramework'
   public var direction: MyFramework.SomeProperty { get set }

Solution:
The best way to avoid this is if the names of modules in a framework are different and don’t coincide with the name of the framework itself. So, if you just started your framework from scratch — keep your public module name different. For example, our framework is called MyFramework.xcframework so the name of your general module could be MyFrameworkMethods

Building iOS framework with dependencies. was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

I think it’s not necessary to start this article with how important to write tests — you know it better than me. Also, I won’t go to dive into the theory of patterns and approaches. My goal is just to show you how easy and quickly you can start writing tests today (or right now if your Xcode project is opened) if you still haven’t started yet.

In order not to turn this article for the sake of the article itself, I will explain why I decided to prepare this small tutorial. Recently I conducted several tech interviews and noticed one curious thing. More and more engineers (even middle and seniors) neglect writing tests. I mean they were really great candidates, but they didn’t write tests at all. So, let this article be here just for those who need to start writing tests right now. Stay tuned.

Prerequisites

1. You use at least Xcode 13
2. You have an existing iOS project
3. You have what to test of course

Create Unit Testing Bundle target

In your existing project we need to create a new target — Unit Testing Bundle.

1. Go to the project navigator and select the project where you want to add a target.
2. In the list of targets press +
3. Find Unit Testing Bundle
4. Press Next.

Name your product. Target to be tested should be your app or framework.

If you don’t see you target in the list of targets, then we need to add it manually using manage targets option.

Quick overview of a template

When you open a file with test you will see XCTestCase template with a few methods. We need only testExample(). Let’s run it using rectangle on the left side of this method.

You will see a green checkmark. Your console log will be filled with information about when the test started, how a lot it takes, and so on. But let’s open Test navigator using CMD + 6. You will see the hierarchy of tests and the same green checkmarks.

All this means — your tests are passed. Let’s make our own.

Create your first Unit test

You testExample method let’s add a following code and run it using triangle.

func testExample() throws {
    let expr1 = "expression 1"
    let expr2 = expr1
    XCTAssertEqual(expr1, expr2, "Expressions are equal")
}

In this implementation, we used a specific assertion which is a part of XCTest framework. Let’s try another example. For that, you can create testExample2().

func testExample2() throws {
    let expr1 = "expression 1"
    let expr2 = "expression 2"
    XCTAssertNotEqual(expr1, expr2, "Expressions are not equal")
}

Since we have several tests you would want to run them all. For that, you can use either Test navigator or the class declaration line.

As you can see XCTest framework provides a lot of asserts for all your general test cases:

// Bool assert TRUE
XCTAssertTrue(expression, "description")

// Bool assert FALSE
XCTAssertFalse(expression, "description")

// Assert that expression is nil
XCTAssertNil(expression, "description")

// Assert that expression is NOT nil
XCTAssertNotNil(expression, "description")

// Assert that an expression is not nil and returns the unwrapped value
XCTUnwrap(expression, "description")

// Asserts that two expressons have the same value or not
XCTAssertEqual(expr1, expr2, "description")
XCTAssertNotEqual(expr1, expr2, "description")

// expr1 > expr2
XCTAssertGreaterThat(expr1, expr2, "description")

// expr1 < expr2
XCTAssertLessThat(expr1, expr2, "description")

// expr1 <= expr2
XCTAssertLessThanOrEqual(expr1, expr2, "description")

// Asserts taht two expressions have the same value within a certain accuracy
XCTAssertEqualWithAccuracy(expr1, expr2, accuracy, "description")

// Asserts that two floating-point values are equal within a specified accuracy.
XCTAssertEqual(49.2827, 49.2826, accuracy: 0.001)

Name your test properly

Let’s say you have a model:

struct SignUpFormModel {
    let firstName: String
    let lastName: String
    let email: String
    let password: String
    let repeatPassword: String
}

Where you would have a method to validate email:

extension SignUpFormModel {
    func isValidEmailFormat() -> Bool {
        return email.contains("@") && email.contains(".")
    }
}

Ok, now it’s time to make a more professional test, but before that to make it more professional let’s think about naming. To name your tests properly is very important to get used to this from the very beginning. Let’s consider this name:

testSignUpFormModel_WhenCreated_EmailShouldHaveValidFormat()

If to break it you can see several parts:

test<Subject>_<Condition Or State Change>_<Expected Result>()

The name starts with test — it’s important to start from this word, otherwise, XCTest won’t recognize your methods (you won’t see this triangle icon). Other parts describe your test almost in detail.

So, if you will make yourself keep using this naming format then your colleagues sooner or later will say thank you in some time.

Create Unit test using Arrange, Act, Assert (AAA) pattern

Okay, we have an empty test, let’s fill it using a simple pattern called Arrange, Act, Assert.

1. Arrange — in other word we can call this step as Given, because you it’s where you arrange your test data.
2. Act can be called When means where you will call your unit — testable method.
3. Assert — or Then. The place where you will assert the result describing this in detail. By the way — don’t be lazy to describe your test well.

func testSignUpFormModel_WhenCreated_EmailShouldHaveValidFormat() {
 
    // Arrange (GIVEN)
    let firstName = "Maksim"
    let lastName = "Kalik"
    let email = "test@test.com"
    let password = "qwerty123"
    let repeatPassword = "qwerty123"

    let signUpFormModel = SignUpFormModel(
        firstName: firstName,
        lastName: lastName,
        email: email,
        password: password,
        repeatPassword: repeatPassword
    )

    // Act (WHEN)
    let isEmailFormatValid = signUpFormModel.isValidEmailFormat()
 
    // Assert (THEN)
    XCTAssertTrue(isEmailFormatValid, "Provided valid email address does not have a valid format")
}

Now you can run your first beautiful test and see how it beautifully fit into the list of other tests.

Wrapping up

Your first unit test (at least using this described format) will be a great contribution to the project you are working on. If you want to see your project from another point of purpose to make it more robust then it’s a good time to start writing tests even if you are working in a startup. Just start from the simple and obvious part of your code then slowly take other more complicated units to test. Good luck!

Links

• https://developer.apple.com/documentation/xcode/testing-your-apps-in-xcode
• https://developer.apple.com/documentation/xctest

Level Up Coding

Thanks for being a part of our community! Before you go:

• 👏 Clap for the story and follow the author 👉
• 📰 View more content in the Level Up Coding publication
• 🔔 Follow us: Twitter | LinkedIn | Newsletter

🚀👉 Join the Level Up talent collective and find an amazing job

Quick start writing Unit tests in Xcode was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Surprisingly for myself, I realized that I have never implemented address autocompletion using only Apple technologies. Before, I had experience only with Google Places SDK and even with the not-so-well-known European GeoDataHub. I found it curious — to know how we can limit ourselves to using only SwiftUI and MapKit to solve a similar problem.

TL;DR

GitHub - maxkalik/address-autocomplete-swiftui: SwiftUI solution of Address autocomplete

MapKit

Before starting let’s briefly describe MapKit — a powerful framework invented by Apple. See documentation:

Display map or satellite imagery within your app, call out points of interest, and determine placemark information for map coordinates.

The framework includes a bunch of useful things. I will list only what we are going to use: the Map itself (MapView for SwiftUI); MKCoordinateRegion — this model will allow showing a particular region on the map; MKAnnotation — another model with coordinates and other data for showing MapMarker on the map, and MKLocalSearch engine which we are going to use to get a list of completions from searchable address. To implement this we need to useMKLocalSearchCompleterDelegate and MKLocalSearchCompleter where we can get results — possible addresses.

Project Overview

The completed task should look like this:

We are not going to ask a user to get the current location of a device hence we will not touch plist configuration at all, I tried to simplify the project as much as possible. Let’s start with a couple of models. The goal is to see how many things we need to implement for this simple application.

So the structure is the following, MVVM with two screens: Content and Map.

Models

Let’s start with a couple of models: AddressResult and Annotation. Both should be conformed to Identifiable protocol because we are going to use them in the collections.

struct AddressResult: Identifiable {
    let id = UUID()
    let title: String
    let subtitle: String
}

struct AnnotationItem: Identifiable {
    let id = UUID()
    let latitude: Double
    let longitude: Double
    var coordinate: CLLocationCoordinate2D {
        CLLocationCoordinate2D(latitude: latitude, longitude: longitude)
    }
}

AddressResult model will be used in the list of results. AnnotationItem collection we will set right in the Map component. But before dive in into this, let's set up our view models first.

Content View Model

Our iOS application is starting from ContentView because we are using SwiftUI, therefore, we need to prepare our first view model: ContentViewModel. The ContentViewModel will be observable because two things need to be published — the value from textfield (searchable text) and results array of AddressResult model.

class ContentViewModel: NSObject, ObservableObject {
    
    @Published private(set) var results: Array<AddressResult> = []
    @Published var searchableText = ""

    private lazy var localSearchCompleter: MKLocalSearchCompleter = {
        let completer = MKLocalSearchCompleter()
        completer.delegate = self
        return completer
    }()
    
    func searchAddress(_ searchableText: String) {
        guard searchableText.isEmpty == false else { return }
        localSearchCompleter.queryFragment = searchableText
    }
}

Some of you can notice searchableText is not marked as private(set). This is because this value is going to be bound. Also, as you can see, here is an initializedMKLocalSearchCompleter. This completer will help to get results using queryFragment. For that, we need to conform to the MKLocalSearchCompleterDelegate:

extension ContentViewModel: MKLocalSearchCompleterDelegate {
    func completerDidUpdateResults(_ completer: MKLocalSearchCompleter) {
        Task { @MainActor in
            results = completer.results.map {
                AddressResult(title: $0.title, subtitle: $0.subtitle)
            }
        }
    }
    
    func completer(_ completer: MKLocalSearchCompleter, didFailWithError error: Error) {
        print(error)
    }
}

We are not going to handle errors at this time, so let me skip this part, we can just print a message. The methodcompleterDidUpdateResults where results are set from the completer’s results. Since our results are published, so we need to the main thread to avoid this warning:

[SwiftUI] Publishing changes from within view updates is not allowed, this will cause undefined behavior

Map View Model

The view models in this project are independent. We are going to observe them using @StateObject. The MapViewModel is pretty simple: two published variables and one method:

class MapViewModel: ObservableObject {

    @Published var region = MKCoordinateRegion()
    @Published private(set) var annotationItems: [AnnotationItem] = []
    
    func getPlace(from address: AddressResult) {
        let request = MKLocalSearch.Request()
        let title = address.title
        let subTitle = address.subtitle
        
        request.naturalLanguageQuery = subTitle.contains(title)
        ? subTitle : title + ", " + subTitle
        
        Task {
            let response = try await MKLocalSearch(request: request).start()
            await MainActor.run {
                self.annotationItems = response.mapItems.map {
                    AnnotationItem(
                        latitude: $0.placemark.coordinate.latitude,
                        longitude: $0.placemark.coordinate.longitude
                    )
                }
                
                self.region = response.boundingRegion
            }
        }
    }
}

Region value as MKCoordinateRegion will be bound with a view and AnnotationItem collection will be used by the Map view itself.

The most interesting part is this getPlace method with the argument as AddressResult. Briefly, this method converts our row address data into the coordinates using MKLocalSearch request!

Our address consists of a title and subtitle. In some cases, subtitle can contain the title, so we need to check first this part to prepare naturalLanguageQuery. Next, it is going to be a task with MKLocalSearch utility. From the response we need two things: MapItem collection and MKCoordinateRegion. From the first one, we will prepare AnnotationItem collection. The second one will be a map region that encloses the returned search results.

Content View

I really enjoy SwiftUI because you don’t need to spend so much time building user interfaces. It means you will spend really about 10 mins just to implement everything — 2 screens including a map.

Our task is simple, we need to prepare just a NavigationView with TextField for query and a List of results. Let’s take a look:

The first screen is when the app is just launched and the textfield is immediately focused on appearing. Also, I couldn’t resist myself to add a clear button to the TextField. So, let’s implement all these views.

struct ContentView: View {
    
    @StateObject var viewModel: ContentViewModel
    @FocusState private var isFocusedTextField: Bool
    
    var body: some View {
        NavigationView {
            VStack(alignment: .leading, spacing: 0) {

                TextField("Type address", text: $viewModel.searchableText)
                    .padding()
                    .autocorrectionDisabled()
                    .focused($isFocusedTextField)
                    .font(.title)
                    .onReceive(
                        viewModel.$searchableText.debounce(
                            for: .seconds(1),
                            scheduler: DispatchQueue.main
                        )
                    ) {
                        viewModel.searchAddress($0)
                    }
                    .background(Color.init(uiColor: .systemBackground))
                    .overlay {
                        ClearButton(text: $viewModel.searchableText)
                            .padding(.trailing)
                            .padding(.top, 8)
                    }
                    .onAppear {
                        isFocusedTextField = true
                    }

                List(self.viewModel.results) { address in
                    AddressRow(address: address)
                        .listRowBackground(backgroundColor)
                }
                .listStyle(.plain)
                .scrollContentBackground(.hidden)
            }
            .background(backgroundColor)
            .edgesIgnoringSafeArea(.bottom)
        }
    }
    
    var backgroundColor: Color = Color.init(uiColor: .systemGray6)
}

I will not go through line by line because, in my opinion, this code is pretty simple. I just wanted to grab your attention on some parts.

• FocusState is used for focusing TextView on appear.
• On receiving value in TextView, it’s needed to wait at least 1 second to get a searchable text except by querying each letter.
• List view. I tested .scrollContentBackground(.hidden) which works only in iOS16 — it helps to hide a content background.
• Using overlay in TextField we can add our ClearButton with bound searchable text (1. for checking if this text is not empty then the clear button will be rendered; 2. for clearing text from the ClearButton component).

struct ClearButton: View {
    
    @Binding var text: String
    
    var body: some View {
        if text.isEmpty == false {
            HStack {
                Spacer()
                Button {
                    text = ""
                } label: {
                    Image(systemName: "multiply.circle.fill")
                        .foregroundColor(Color(red: 0.7, green: 0.7, blue: 0.7))
                }
                .foregroundColor(.secondary)
            }
        } else {
            EmptyView()
        }
    }
}

The Address row is wrapped by NavigationLink with a destination in MapView.

struct AddressRow: View {
    
    let address: AddressResult
    
    var body: some View {
        NavigationLink {
            MapView(address: address)
        } label: {
            VStack(alignment: .leading) {
                Text(address.title)
                Text(address.subtitle)
                    .font(.caption)
            }
        }
        .padding(.bottom, 2)
    }
}

Map View

The second screen is a map itself and this view should show the correct location from the search result.

It’s going to be only one view: Map View. As you remember getPlace method converts addresses into coordinates, so when the view appears we need to update the coordinates: region and annotation items. Eventually, in annotation content, we can prepare the MapMarker. Map view configured with coordinateRegion, annotationItems, and annotationContent arguments. When all data is ready in the view model, the Map view will be updated. As you can see coordinateRegion argument applies a binding value. annotationItems can be just identifiable with coordinate variable inside (latitude and longitude) — it’s used in annotationContent item in closure.

struct MapView: View {
    
    @StateObject private var viewModel = MapViewModel()

    private let address: AddressResult
    
    init(address: AddressResult) {
        self.address = address
    }
    
    var body: some View {
        Map(
            coordinateRegion: $viewModel.region,
            annotationItems: viewModel.annotationItems,
            annotationContent: { item in
                MapMarker(coordinate: item.coordinate)
            }
        )
        .onAppear {
            self.viewModel.getPlace(from: address)
        }
        .edgesIgnoringSafeArea(.bottom)
    }
}

Btw, when you build the project you might see some SwiftUI warnings: Publishing changes from within view updates is not allowed…— which means you probably updated coordinates during view rendering. If you think that you did absolutely right, your states are updated from onAppear, so it can be an issue in Map inside. You can check this article about this issue by Donney Wals.

Wrapping up

Countless applications use Maps. But still few of them use a combination of SwiftUI and MapKit. I was curious to see what we can build if using only Apple technologies. How many lines of code are needed to implement this useful feature. Each year in WWDC you can notice that Apple engineers update MapKit rigorously adding new features especially if it comes to SwiftUI. I used only SwiftUI building Address with an autocompletion feature with Map because I truly believe that this framework is our closest future and UIKit soon will be secondary technology.

Want to Connect?
Don’t hesitate to follow me on Twitter. I appreciate any suggestions or comments regarding my research and articles.

Implementing address autocomplete using SwiftUI and MapKit was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m working on a project where we started classically — UIKit without storyboards, MVVM + Coordinator design pattern. It can be familiar to you especially if you are working for a start-up. All our development process is going really quickly. Sometimes my typical working day I would compare it with a middle distance running. Business waits for new features all the time. At some moment we figured out that we spend a lot of time building new UI features, but our features are not very custom. We waste our time on constraining views, configuring, and conforming to delegates. You know the difference between List and TableView setting up.

One of the best choices was trying SwiftUI. Using this framework I personally wanted to solve the main problem — to deliver features faster, moving screens and views from one place to another without prejudicing the existing codebase.

In the beginning, it was a little bit scary to use SwiftUI for production but eventually, we got a pretty result: we doubled the speed of building our features. This means we free up time for: focusing on logic, unit testing, and UI testing.

So, based on my experience, I would like to share how quickly and easily you can start building new Scenes (Screens) in the MVVM+C design pattern in your UIKit project.

TL;DR

GitHub - maxkalik/uikit-swift-to-swiftui: MVVM+C UIKit project with SwiftUI

Exploring the project

Given: UIKit application with a screen — let’s call it the Home screen with orange background. If we run an application, it starts some custom activity indicator. When UI is ready to use we only have one button — Sign In.

Let’s imagine you got a task. You are asked by some Product Manager or your Team Leader to implement a new feature — a new SignIn Screen. And it should work in this way: On tapping on the Sign In on Home Screen we should present the SignIn screen. We have to add some logic there — to check textfield if it is empty we need to present an alert with an error message.

If all is done by a user correctly— the textfield is filled by name then after some loading process we need to segue to the previous orange Home screen with the updated title of the button and a label above.

Ok. It doesn’t seem like a complicated task and you as a developer decided to implement this whole screen using SwiftUI. Good decision. But, let’s figure out how we are going to integrate our SwiftUI staff.

Looking from an architectural perspective

Firstly, let’s take a look at the project from the coordinator’s perspective. The first start method prepares Home Screen. As you can see for preparing of this module is needed View Model and View Controller. Then this View Controller is just pushed to the stack of the Navigation View Controller. It’s a pretty common preparation process for the modules in iOS Development when using MVVM + Coordinator design pattern.

View Model — HomeViewModel includes a couple of delegates — ViewDelegate and CoordinatorDelegate. ViewDelegate is needed for controlling views on the screen in a particular scene. In this case, it’s a Home Screen, and the view model delegates the responsibility of showing and hiding an activity indicator on the screen. CoordinatorDelegate delegates the responsibility of showing our new screen — The SignIn screen. But how are we going to implement this part if we want to use SwiftUI?

BaseViewController

Ok. If you know the project like the back of your hand you can just start.
But let’s assume at this point you don’t know exactly about the project structure. You are working in a team. You respect each of your colleagues and their work and you don’t want to break the existing structure just because you want to integrate your SwiftUI staff.

So let’s take a look at the view hierarchy. Most likely you will see something like this — The ViewController is inherited by BaseViewControlleror something similar. It’s needed for storing some base view logic (not business logic). In our case, BaseViewController has methods for showing and hiding the Activity indicator.

You most likely already know how to use SwiftUI View in UIKit and why we needUIHostingController. Also, I bet you understand that under the hood UIHostingController is as usualUIViewController as well. And you will be right to push this view controller to the UINavigationController because it freely accepts this controller in its stack.

But we have a requirement — we have to use this exact ProgressView without repeating ourselves. Of course this Progress view we can just reimplement this in SwiftUI but what about reusability? It’s time to remember the DRY principle and all warnings in your head about this. As I said before — we don’t want to break the existing structure.

BaseHostingController

The decent solution is to prepare the sameBaseHostingController as BaseViewController inherited from UIHostingController and somehow from there to use a couple of methods that start and stop the activity indicator.

As you know UIHostingController is theUIViewController. This means we can wrap our two base controllers using a protocol.

This BaseController protocol will be withProgressView and the same base methods as in BaseViewController. And here we go. Conforming this protocol to both — BaseViewController and BaseHostingController we get an opportunity of using the same ProgressView from UIKit and SwiftUI modules.

Having BaseHostingController we can use it in the same way as BaseViewController especially if it comes to View Delegates. We just easily control our loading indicator from this Hosting Controller without breaking the structure of the project.

Even the coordinator didn’t seem to be changed. Only one beautiful method appeared: showSignIn()

Look, how it’s beautifully fitted to the existing MVVM+Coordinator design pattern. AppCoordinators got clean and easy-to-read methods with the same steps for preparing the module to be shown. ViewDelegate from SignInHostingController works in the same way as with BaseViewController.

Wrapping Up

If you are working in a team your code should be predictable and readable for everyone, even though your colleagues don’t know about SwiftUI, but anyway, they will understand how to maintain this structure.

In my personal experience, I use this approach pretty successfully. Almost 70% of the screens of our project today are SwiftUI with UIHostingController. and I guess it’s going to be 100% but then it will be another story about how completely transit your UIKit app into SwiftUI :)

Resources

GitHub repository: https://github.com/maxkalik/uikit-swift-to-swiftui

UIHostingController: https://developer.apple.com/documentation/swiftui/uihostingcontroller

Want to Connect?

Don't hesitate to follow me on Twitter.

I appreciate any suggestions or comments regarding my research and articles.

Integrating SwiftUI into UIKit project was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 1. Launch UIViewController from Unity

I won’t waste your time on a long introduction about the technologies that I will describe here. You most likely already work as an iOS Engineer or Game Developer, which means you probably have some questions regarding the topic of this article. So, let’s get started.

This article is split into two parts. In the first part, you will learn how to launch a simple UIViewController from Unity. We will force C# to understand Swift. In the second part, we will try to expand the usage of Swift in Unity and explore the limitations.

All right, here we go.

Prerequisites

• macOS Monterey
• Xcode 13 (or 14)
• Unity LTS 2021.3
• iOS Device (with at least iOS14 or higher)

iOS Framework

Open Xcode and create a new Swift project — framework.

The name of the project is up to you, I named it SwiftCodeKit. It’s going to be a simple framework with one view controller. We need only three files:

In SwiftCodeKitViewController, let’s create a simple UIViewController — with a button at the center of the view.

In SwiftCodeKit.swift we will collect all our public methods. Having this public class will allow you to test your framework in iOS projects. The first one will bestart(). This method presents our SwiftCodeKitViewController.

The third file SwiftCodeKitBridging.swift will contain a list of public exposed methods with C declaration notation @_cdecl. These methods should be stored only in a non-local scope. First, let’s create a method: startSwiftCodeKitController().

The attribute @_cdecl is not documented. For now, you only have to know that this attribute exposes a Swift function to C. Further, we will experiment a little bit with this attribute and will figure out the limitation.

Building framework

In your Xcode project status of the toolbar choose Any iOS Device (arm64) destination. Yes, we are going to build only for iOS devices, not for Simulators. Now, you need only tap Command + B.

To get our baked framework we need to go to Derived data and take it from there. You should open the Derived data folder from Xcode: Go to Xcode Preferences (cmd + ,), then open Locations, and tap on the arrow at the end of the Derived data path.

In the Derived data folder, find your project and use this path:
Build / Products / Debug-iphoneos / SwiftCodeKit.framework

Unity project

It’s time to set up our Unity project. Open Unity and create a project; I called it UnityClientProject.

In the Unity project, you will find folder assets. Drag your SwiftCodeKit.framework and drop it to the Assets folder.

Regarding UI in Unity, we are going to make a simple button. This button will summon our SwiftCodeKit View Controller. Right-click on Hierarchy, choose UI, and then Button.

Also, in the hierarchy, we have to make another object for our button. I call it ButtonController. In the inspector of the ButtonController, add a component / new script and name it ButtonControllerScript.cs. Open this file.

Actually, we need only one public method: OnPressButton(). But before that, we have to import System.Runtime.InteropServices. This will help us to recognize our methods from the SwiftCodeKit.framework. If you remember, we have only one public function: startSwiftCodeKitController(), so let’s import it using DllImport.

Building Unity project

We are ready to build our iOS project from Unity. Open File / Build Settings and change the Platform to iOS. Then press Build.

After pressing build it will automatically run an Xcode project. This project is generated by Unity and there you will see only one Framework called UnityFramework.

A couple of problems you can stumble upon at this moment: the first one — you have to sign this project and the second one is the bitcode error — this can only happen if you use Xcode 14. It’s not so big deal. Let’s just disable bitcode in this project, and run it again.

On your iPhone, you will see your Unity app. The first blue screen with a button — this is the Unity part and the orange presented screen is your framework!

Wrapping Up

Let’s quickly go through what we did:

1. Prepared a Framework with a public method for iOS and for C# using @_cdecl attribute.
2. Created a simple Unity project with a button at the center.
3. Added our Framework to the assets of the Unity project.
4. Prepared the ButtonController object with C# script where we imported our method using System.Runtime.InteropServices
5. Built an iOS project from Unity.

As you can see these are basic steps that give you an opportunity to understand how it works. In part two (see below) we will try to make this project closer to real usage. We will experiment with @_cdecl attribute and explore the limitations.

Part 2. Exposing Swift Functions to C# in Unity

This article is written in two parts. In the second part, we will experiment with @_cdeclto understand the limitations of interoperability of Swift and C#. Let’s get started.

If you read the first part of this article you should remember the SwiftCodeKitBridging.swift file:

In this file, we store a list of public methods for exposing, using @_cdecl attribute. As you can see we already know how to call some functions from C#. But obviously, it’s not so usable because in real iOS applications we use functions with parameters, our functions return some values, moreover, we use closures, delegates, and so on. How do expose this code to the Unity project?

Let’s resume what we are gonna try today:

• Function with parameters
• Function returns value
• Function with closure

iOS framework update

I prepared a small update of our SwiftCodeKitViewController.

I added two more views: UILabel and UIStepper. Using stepper control we can increment and decrement a value and set it to the label.

It will be enough to experiment with real UI. Let’s take a look at our public class:

As you can see this class was extended with methods that we are going to use in C#. The most interesting part is the Delegates — they are represented by closures. Let’s connect all these methods to our UI. In viewDidLoad, add our first delegate method SwiftCodeKit.swiftCodeKitDidStart?().

Here’s other methods that can be used in extensions:

iOS framework bridging methods

All our public methods should be recognized from C#. I suggest walking through them one by one.

Here’s the function with parameters:

Function returns a value (Double):

The function returns a string. Here you can notice a difference. Specifically for this kind of data, we need to allocate memory and pass our string to strdup() — this method will duplicate the string for UnsafePointer().

OK, now Delegates. As you can see they are functions with escaping closures. But besides escaping closure has some interesting add-on called@convention(c)

There is a short description from docs.swift.org:

Apply this attribute to the type of a function to indicate its calling conventions. The c argument indicates a C function reference. The function value carries no context and uses the C calling convention.

OK, let’s build our updated framework, get this build, and drop it into the Unity project assets folder (see part 1 for how to do this).

Unity ButtonControllerScript update

Our C# script file has only one imported function for now: startSwiftCodeKitController, so it’s time to add the rest of them. We will walk through the same way as we did with Swift methods:

Here’s the function with parameters:

This function returns a value, as shown below:

And Delegates using AOT:

The last thing we are going to do is to update OnPressButton() method where we use all methods from our Swift framework.

Directly from Unity we configured our iOS Controller and used our three delegates. Now, it’s time to build our project. If you followed me correctly and all your methods were recognizable by Unity, your result will look like the following:

The console of Xcode should print something like this:

SwiftCodeKit did start
SwiftCodeKit get value: 10
SwiftCodeKit get version: Swift Code Kit 0.0.1
SwiftCodeKit value did change. Value: 11
SwiftCodeKit value did change. Value: 12
SwiftCodeKit value did change. Value: 13
SwiftCodeKit did finish

Wrapping Up

I always ask the same question every time I finalize a task: How can I make this better? I think this task could be improved endlessly. I’m not an expert with Unity (if you know better, please comment), but I know that we can even build DLL Library with all our functions and eventually just import this build directly to the script.

Also, as an iOS developer using UnsafePointer keep in mind that this memory should be released.

Thanks for reading.

Source Code

GitHub - maxkalik/swift-in-unity: iOS Framework for Unity

Want to Connect?

Don't hesitate to follow me on Twitter.

I appreciate any suggestions or comments regarding my research and articles.

Setting Up iOS Framework for Unity was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m not going to tell you again about Actors from scratch, what is it and how it works. Since Apple has introduced Swift 5.5 there are tons of cool articles about them. If you still don’t use actors then it’s time to take a look. I bet it will come a time when you will change some of your classes to actors.

This particular article is about a specific potential issue while using actors with delegates after updating Xcode with version 14. It sounds a bit trivial but I think it could be useful. Let’s get started.

Before Xcode 14

Let’s assume we have class SomeClass with a delegate:

And SomeViewModel — in there we going to use our SomeClass:

As you can see, we did a primitive manipulation by setting delegate to self and conforming view model with SomeClassDelegate.So, let’s print out some results from it.

let someViewModel = SomeViewModel()
someViewModel.start()

// Printed: some class did start

Ok. Now it’s time to refactor our class with an actor. How it could be (and maybe you have done it already in your project in this similar way):

In the same way, let’s use it in our view model. Of course, since we have a deal with an actor we need Tasks.

After

If you are still using Xcode 13 you probably won’t see any warnings in this implementation. But if you have updated already Xcode with version 14, most likely you will get this error:

At first sight, it’s confusing, especially: “No async operations occur within await expression” when the delegate is an actor’s property. Also, it could be a question — if we await to change a property from outside, why do we see this message about isolation?

In reality, the errors both make sense and look weird a little bit. As we know — the base idea of the actors is to isolate properties. It means you cannot just update property from outside. So, probably, these errors teach us how to use actors properly and the updating of the property delegate should happen only inside of the actor SomeActor.

A reasonable solution is to add an additional method. This method will set the delegate with a new value.

Inside of the Task in view model replace this:

// await someActor.delegate = self
await someActor.setDelegate(self)

Expected result:

let someViewModel = SomeViewModel()
someViewModel.start()

// Printed: some actor did start

Wrapping up

I wouldn’t write this article if the error wasn’t so unexpected. I see already some questions appear in Stackoverflow or in Swift discussions and I asked the same. If this actor-isolated property error is only about teaching us how to use actors properly, why can’t it be only a warning?

Thank you for reading.

Want to Connect?

Don't hesitate to follow me on Twitter.

I appreciate any suggestions or comments regarding my research and articles.

Fixing Swift Actors and Delegate Error on Xcode 14 was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

On the internet, in the Apple documentation, and here on Medium, there is a ton of information about SwiftUI, how to use it from UIKit, and vice versa. But today, let’s consider a not-so-common case in real life that’s useful to reflect on non-standard situations in iOS development.

Task: Show SwiftUI view from Objective-C codebase. Moreover, when an Objective-C model should be observable, the respective SwiftUI should be updated.

Result: When you press the Sign In button from Home, View Controller should be pushed a SwiftUI View with a Title, Text Field, and a button Sign In. On edit TextView and on Press on the Sign In button, the title label should be updated.

TL;DR

GitHub - maxkalik/uikit-objc-to-swiftui: Transition from UIKit Objective-C to SwiftUI

Start-Up MVVM+C Project

Clone the project from the link above. The repository has the start folder, which has an initial project that we are going to use.

This iOS App was developed using MVVM + Coordinator. I agree it’s already a bit complicated to use this architecture to explain how to show SwitUI views and update them from Objective-C, but I would say, it’s more like a real situation where we need to stick to a particular pattern. No worries, we have only one screen at this point.

The structure of the project consists of several entities: AppCoordinator, Protocols, and MVVM Modules. AppCoordinator has only a general App Coordinator. For the protocols, I decided to store there all protocols we will use across the project. And the Modules group has the screens; for now, it’s only one home screen with a black Sign In button.

The Sign In button uses a typical coordinator delegate where from the coordinator we have to prepare our solution of showing SwiftUI Login View. But before implementing SwiftUI View, let’s complicate our task a little bit more. Let’s assume we already have LoginViewModel implemented in Objective-C as well and we are not allowed to refactor it into Swift. Only LoginView should be implemented in SwiftUI.

Okay. Let’s take a look at LoginViewModel. We have three NSString properties.

The name property should store from SwiftUI TextView. The title should be changed on TextView edit. The buttonTitle will be “Sign In,” and the method buttonTap should change the title value. Nothing crazy.

Bridging Swift Files

It’s time to start adding Swift files to our Objective-C project.

Go to File ➝ New ➝ File… ➝ SwiftUI View. This will keep the project structure better when saving this file to the Modules/Login/Views/ folder.

After this, you will be asked about creating Bridging Header, and yes, we need this. Press create.

You will see two files: LoginViewModel.swift and UIKitObjCToSwiftUI-Bridging-Header.h in the Views group.

Initially bridging header after creation will be empty. But we already know that we are going to use LoginViewModel.h. So we need to import this header.

The last step of bridging is to make our Objective-C files see Swift files. So, we need another import for that, and we will do this in AppCoordinator.m. But a bit later.

SwiftUI view and Coordinator Interface

At this moment we don’t use any view models. We just need to show a pure SwiftUI view with dummy data.

To show the SwiftUI view, we need to use UIHostingController which will play the role of UIViewController in Objective-C world, so for that, we need to create an “interface” to wire up AppCoordinator and SwiftUI views.

It’s time to bridge to make Objective-C see Swift. Let’s import our Bridge header right in the AppCoordinator.m.

By the way, don’t be scared. You will notice that autocomplete is not working for this header. The last part of this file should be -Swift.h. If you are not sure about that, check:

Build Settings ➝ Swift Compiler — General ➝ Objective-C Generated Interface Header Name

Let’s use all these pieces in the AppCoordinator so the (void)showLogin method will be updated:

Run build. If you have done it all correctly, you will see a SwiftUI view after tapping on the Sign In button from the Home View Controller.

Objective-C ViewModel and ViewModel Interface

We need to make our view model visible in the SwiftUI view, and the title of the Login View should be updated. An Implementation will be a little bit similar to Coordinator interface but with some additional enhancements.

To unify our “observable” solution, we need a couple of protocols: ObservableNSObject and ObservableNSObjectDelegate. Here’s the code:

The trick is to use these protocols for conformance of all Objective-C modules, which will be used in SwiftUI and the viewModelDidUpdate method. They will do this for each update of properties or methods in the view model.

@interface LoginViewModel : NSObject <ObservableNSObject>

In LoginViewModel.m, update these methods:

Since we prepared the view model to be updated, let’s create our view model interface, as shown below:

The main trick is to update the published viewModel using ObservableNSObjectDelegate. Let’s update our LoginView using this view model interface. I called it observable.

Of course, we need to update Coordinator interface. As you can see, the SwiftUIViewModelInterface is like middleware between the Objective-C view model and SiwftUI View.

The AppCoordinator showLogin also should be updated with the LoginViewModel. Of course, ideally, it will be cool to see the SwiftUI object, but Objective-C sees only the UIKit stuff.

That’s it. Run build, and you can see how it works. You can find the result in final folder of the project repository: https://github.com/maxkalik/uikit-objc-to-swiftui/tree/master/final

Wrapping Up

In my opinion, the best part of this task is the non-standard situation, and I’m sure you most likely won’t be encountered this. But the question of using SwiftUI in Objective-C exists, and why wouldn’t you try to answer it?

I call it — an uncomfortable task. It means this kind of task confuses you, and you don’t know exactly how to make this at the beginning. They force you to think out of the box, which will make you more professional.

Want to Connect?

Don't hesitate to follow me on Twitter.

I appreciate any suggestions or comments regarding my research and articles.

Updating SwiftUI Views From Objective-C Using MVVM was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.