ObservableObject, @Published, and Protocols with SwiftUI, UIKit, and Cuckoo

How to use Combine and protocols in any view

ObservableObject was introduced as part of Apple®️’s Combine framework and is foundational to data flow in SwiftUI. Extending protocols with ObservableObject, however, is not as straightforward. In this article, we explore patterns for leveraging protocols with ObservableObject in both SwiftUI and UIKit and the challenges encountered along the way.

ObservableObject usage in SwiftUI

Let’s take a look at the typical usage of ObservableObject in SwiftUI. For our example, we create an ObservableObject that handles fetching pricing data.

For our example view, we display the price, if we have it; otherwise, we display a fallback message. We provide a button to initiate the pricing request for demonstration purposes.

Defining a protocol extending ObservableObject

Let’s see how we could leverage a protocol for the PricingProvider.

This looks good, but we are missing a very key characteristic of an ObservableObject. We need at least one @Publishedproperty or we need to explicitly call self.objectWillChange.send() so that our object can notify subscribers of its updates. Without these, our views will never display an updated price, as shown below.

@Published properties and protocols

Let’s try adding the @Publishedproperty requirement to our PriceRequesting protocol.

Property wrappers cannot be used inside protocols, unfortunately. Without this, we cannot enforce implementation of a publisher. There are ways around this though. @Published wraps our property with Published<Value>, so we can expose some values for these in our protocol.

Now our view works as expected, receiving updates from PricingProvider, while satisfying the publisher requirements of our protocol. Note that _price exposes the Published<Price?> value and $price exposes the publisher.

Using an extended ObservableObject protocol in SwiftUI

Now that our protocol is defined, let’s try and use it in our SwiftUI view.

Because ObservableObject uses Self for its objectWillChange property, we cannot declare it as a type directly. We can work around this though. In order to continue to leverage @ObservedObject, we can make PriceView a generic type.

Another option would be to decouple our protocol from ObservableObject altogether. Since we exposed Published<Price?>.Publisher in our protocol, we technically do not need to extend ObservableObject.

We will, however, need to update our view to explicitly subscribe to the publisher we defined in our protocol since we can no longer use @ObservedObject.

In order to keep our price updated in the view, we need to create a @State variable for this data. We use .onReceive(_:perform) to explicitly subscribe to price updates and update our internal @State variable to trigger a re-render of our view.

Using an extended ObservableObject protocol in UIKit

Below is the UIKit implementation of our simple pricing view. As with our SwiftUI example, we will start off using the ObservableObject implementation directly instead of our extended protocol.

Unlike SwiftUI, there is no built-in mechanism in UIKit for subscribing to updates. Since we always have to explicitly subscribe to a publisher in UIKit, it’s rather simple to update this code to leverage the PriceRequesting protocol instead of the ObservableObject implementation.

Mocking ObservableObject with Cuckoo

Now that we know several options for leveraging protocols via extendingObservableObject or utilizing Published<Value>, let’s see if they are easily mockable with Cuckoo.

Apparently, they are not. In fact, it’s not currently possible to mock protocols extending ObservableObject in Cuckoo. At the time of writing this, there is an open issue for it. If we want to use Cuckoo to mock our protocol, we have to decouple.

Let’s try again.

It turns out this new “Cannot specialize a non-generic definition” error is due to both the Foundation and Combine frameworks having a Published type. All of the mocks generated by Cuckoo end up in a single GeneratedMocks.swift file, so if you are using Foundation in another mocked file, then this error will occur.

There are a couple of options for working around this. We could be explicit in referencing Combine in our protocol.

Alternatively, we could type erase our publisher via AnyPublisher. To enforce implementation of a publisher in our protocol, we really only need to require a Publisher property and do not need to require a property for the published value (Published<Price?>).

Key Takeaways

• @Published property wrappers are not allowed in protocols. Use AnyPublisher or Published<Value>.Publisher to enforce a publisher implementation.
• Use the _ and $ prefixes to access the value and publisher of an@Published property.
• If you extend ObservableObject, be prepared to make the controllers and/or views (UIKit or SwiftUI) requiring it generic with where clauses.
• You can bypass extending ObservableObject altogether and just require an AnyPublisher in your protocol.
• SwiftUI views can achieve the same functionality as @ObservedObject by using a combination of @State and .onReceive(_:).
• Unlike SwiftUI, subscribing to publishers in UIKit via a protocol or an ObservableObject implementation is done the same way.
• If you want Cuckoo to mock your protocols, then your protocols can’t extend ObservableObject (yet). See Cuckoo issue.
• If using Cuckoo, beware of Published<Value> in your protocols due to conflicts with the Foundation framework. Save yourself the trouble and use AnyPublisher.

Thanks for reading. 😄

Learn more about technology at Expedia Group

ObservableObject, @Published and Protocols with SwiftUI, UIKit and Cuckoo was originally published in Expedia Group Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to bring the two together

In my Lessons in SwiftUI blog post, I covered some of the differences between SwiftUI® in iOS 13 vs iOS 14. In iOS 14, we get LazyVStack and LazyHStack, which give us the performance benefits and functionality of UICollectionView in UIKit. In the Vrbo™️ (part of Expedia Group™️) iOS app, we use UICollectionView all over the place including the discovery feeds on the home screen, search results, trip boards, etc. Until we deprecate support for iOS 13, these UICollectionViews will be sticking around. There is also a strong possibility that we will be in a hybrid state of UIKit/SwiftUI for a while, so deprecating our use of UICollectionView is not likely to happen all at once even after we drop support for iOS 13.

Can we use SwiftUI inside UICollectionView?

Yes…technically. :)

If you’re looking to start leveraging SwiftUI immediately while still using UICollectionView, it is possible. One approach is to use SwiftUI Views as the content for your UICollectionViewCell, which is what I'm going to cover in this post. I will warn you though, it might not always make sense to do this.

SwiftUI View inside UICollectionViewCell

Let’s first take a look at how to add a SwiftUI View to your UICollectionViewCell.

This is the SwiftUI View we will be working with for our example:

Adding the View

Next, we embed the SwiftUI Card inside a UICollectionViewCell.

Integrating with UICollectionView

Configure UICollectionView

Here’s a basic UICollectionView setup to render the cell above. To start, we’ll hard-code the number of cells (we will update this later).

So far, so good.

UIHostingController Setup/Cleanup

I covered UIHostingController in Lessons in SwiftUI, but I didn't cover it's usage outside of a UIViewController, which is what we're doing here. UIHostingController is a subclass of UIViewController and is how we use SwiftUI inside UIKit. Typically, when we add UIViewControllers to the hierarchy, we don't just add its UIView as a subview, but also add the actual controller as a child of the UIViewController. If we don't do this, we may run the risk of some unwanted side effects...memory leaks, views mysteriously disappearing, etc. So while the code above technically works and has been verified to not have any memory leaks, this may or may not cause other unintended issues. To err on the side of caution, let's go ahead and add it to the stack.

Here, we’re adding some helper methods to properly add and remove the UIHostingController in our UICollectionViewCell.

Now, our parent UIViewController can add the UIHostingController as a child.

Lets verify clean up happens when we navigate away from the parent UIViewController.

Sweet. 😄

Passing Data

Up to this point, we’re rendering a SwiftUI View for our UICollectionViewCell content and we're properly setting this up. Now we need to start passing our SwiftUI View some data, so that each cell's content is different.

First, let’s update our SwiftUI View to accept some data.

I have gone ahead and made CardContent a protocol here instead of a struct. In the Vrbo iOS app, the data providing the content for these cards is coming from a variety of backend services. We use cards like these for showing recommended properties, recently viewed properties, search results, properties on a trip board, etc. Making this a protocol allows all of these existing data models to simply conform to the protocol instead of creating new data models.

We have a new problem now though. We need the parent UIViewController to provide data to our UICollectionViewCell, but we won't have this data on initialization.

We need to refactor our code a bit to account for this.

A few things to note:

• embed(in parent: UIViewController) has been updated to also accept the data for our card.
• Instead of setting up UIHostingController and adding the view on initialization, we've now moved this logic to the embed() method.
• If the UIHostingController has already been initialized, we update the host's rootView with a new Card instead of spinning up another UIHostingController and having to re-add the view to the cell.
• We’re no longer using constraints to layout the SwiftUI Card. This isn't required, but is another alternative to laying out an embedded SwiftUI View.

Our last step is to pass the data from our parent UIViewController to the cell, so we’ll add some fixture data for our example and then update our UICollectionViewDataSource methods to pass this data along.

We can optimize this even further and make a SwiftUICollectionViewCell so that this is reusable.

Now we can make MyCollectionViewCella subclass of SwiftUICollectionViewCell.

And then update our parent UIViewController to call our new .configure() method.

let item = items[indexPath.row]
cell.configure(with: item, parent: self)
// cell.embed(in: self, withContent: item)
return cell

Alright! Here’s what we’ve got in our UI now.

Layout Considerations

We’re getting pretty close here, but have a couple of things we could improve in the UI. For instance, we want our images to be the same size, so that the content under each image also lines up with the rest of the cards.

The first thing to note is that we’re sizing our cells via the UICollectionViewDelegateFlowLayout, so our SwiftUI Card needs to support its parent container determining its size.

In its current form, our SwiftUI Card doesn't do a very good job of adapting to its size. Our images run the risk of being skewed.

Luckily, this is a common issue when resizing images inside a container with a specified size that we have already solved. :) We’re going to apply our .fitToAspectRatio() modifier so that our Card is more adaptable to its container. For details about the .fitToAspectRatio() modifier and resizing images in SwiftUI, check out Resizing Images in SwiftUI.

Our images are now the same size, but our cards are not all aligned. Our SwiftUI Card can vary in height due to the title .lineLimit() being able to span up to 2 lines.

By default, SwiftUI Views are centered vertically to their container, which is what is happening here. To ensure our content gets aligned to the top of our UIViewCollectionCell, we need to add a Spacer().

Nice. :) This is looking good now.

Caveats

So far so good, right? Let’s add a button to our SwiftUI View.

Do not use @State

Remember that UICollectionViewCell gets reused for performance? For this reason, we need to make sure that our embedded SwiftUI Views do not hold any @State, as it could get wiped out as soon as the cell is no longer visible.

Here, you'll notice we lose the heart state of the first cell.

If your cell needs state, move this logic up higher in the View hierarchy by leveraging @EnvironmentObject.

Using @EnvironmentObject will ensure your cell gets its state every time it's reinitialized.

Beware UICollectionViewDelegate and SwiftUI Buttons

When we are showing a property card in the Vrbo iOS app, we typically present that property’s details once you tap on the card.

In our example, we would leverage the UICollectionViewDelegate to achieve this.

Let’s see what happens with this hierarchy in conjunction with the didSelectItemAt method of the UICollectionViewDelegate:

// View Hierarchy

UICollectionViewCell
  -> SwiftUI View - (Property Card)
     -> SwiftUI Button - (Heart Button)

Not what we want at all! We expect the heart button to be toggled and not to be taken to the property details view, but instead we get both since the didSelectItemAt delegate method is also getting called.

This is what happens when we use a UIButton instead in conjunction with the didSelectItemAt method of the UICollectionViewDelegate.

// View Hierarchy

UICollectionViewCell
  -> SwiftUI View - (Property Card)
  -> UIButton - (Heart Button)

This is the behavior we want. The heart should be toggled when tapped and you should only be taken to the property details when the card is tapped.

What are our options for handling interactivity in a SwiftUI View embedded in a UICollectionViewCell?

• Don’t hook into the didSelectItemAt UICollectionViewDelegate method if you're integrating a wrapped SwiftUI View. You could implement your own didSelectItemAt delegate method. SwiftUICollectionViewCell could even implement such a delegate out of the box if needed.
• Don’t bother with an embedded SwiftUI View if your UICollectionViewCell content has a lot of interactive elements AND you also need to hook into the didSelectItemAt UICollectionViewDelegate method.
• Define a UIButton inside of UICollectionViewCell and position it above your SwiftUI View, as we did above.
• Just wait until your app deprecates support for iOS 13 and then replace your UICollectionView with a 100% SwiftUI LazyStack solution.

Conclusion

While it’s technically possible to use SwiftUI inside of a UICollectionViewCell, whether you choose to do so will likely depend on your use case and whether it makes sense given the caveats. These are some questions you might ask yourself before attempting a SwiftUI/UICollectionView integration:

• Is my app close to deprecating iOS 13? If so, maybe you can wait until that happens and implement a SwiftUI LazyStack solution.
• Does my cell content have interactive elements? If so, are you okay with implementing some workarounds if you also need to leverage UICollectionViewDelegate.

Thanks for reading!

SwiftUI with UICollectionView was originally published in Expedia Group Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to resize images to any aspect ratio without distortion

In the Vrbo™️ (part of Expedia Group™) iOS app, we’ve recently converted some of our existing UIKit views over to SwiftUI and encountered issues when resizing images. The problem arises when we need to resize an image to a certain size and maintain the aspect ratio without skewing.

We initially encountered this while working on Vrbo’s iOS 14 Widget, when we needed the image to be a perfect square, and again when building a SwiftUI version of one of our property cards. We display property images on nearly every screen in the app and at varying sizes depending on the context, meaning it was important to solve this problem in a scalable way.

iOS Widget

Property Card

The Road to Resizing

Starting from scratch, this is what you get when you render an Image in SwiftUI without any modifiers.

// original size: 338 x 360
Image("bungalows")

Now things are going to start getting weird. First, we explicitly set the size via .frame().

// try to override size
Image("bungalows")
    .frame(width: 100, height: 100)

Note: the blue square is there to indicate where the frame is. This wouldn’t be visible in the UI.

Since nothing happens when you set the .frame() explicitly, let’s see what applying the .clipped() modifier gets us.

// this sorta works
Image("bungalows")
    .frame(width: 100, height: 100)
    .clipped()

Better….but our image just got cropped and was not resized. SwiftUI has a .resizable() view modifier, so what happens when we use that instead?

Image("bungalows")
    .resizable()

Not what we want, but at least the image is resized now. By default, the resizingMode is .stretch, which is what we see above, but you could also set this to .tile.

// .stretch is default
Image("bungalows")
    .resizable(resizingMode: .tile)

The image looks better, but this is still not what we want. Let’s try explicitly setting the .frame() again, but this time in conjunction with the .resizable() modifier.

// specify an exact size
Image("bungalows")
    .resizable()
    .frame(width: 338, height: 200)

It’s skewed! That’s not going to work. Let’s try to resize by aspect ratio.

// use aspect ratio + .fit to resize
Image("bungalows")
    .resizable()
    .aspectRatio(4/3, contentMode: .fit)

Using .fit still gets us a skewed image. Instead, let's try using .fill

// use aspect ratio + .fill to resize
Image("bungalows")
    .resizable()
    .aspectRatio(4/3, contentMode: .fill)

Well that went wrong. We’re going to need to try something different…or Rectangle.

// let the trickery begin
ZStack {
    Rectangle()
        .fill(Color(.gray))
	.aspectRatio(4/3, contentMode: .fit)
            
    Image("bungalows")
}

ZStack is how we stack things on top of each other in SwiftUI. The Rectangle is exactly the size we want our image to be. Can we make our image the same size as the Rectangle?

// getting closer...
ZStack {
    Rectangle()
        .fill(Color(.gray))
	.aspectRatio(4/3, contentMode: .fit)
            
	Image("bungalows")
	    .resizable()
	    .layoutPriority(-1) // special sauce
}

We can! We’re giving .layoutPriority() to the Rectangle so that it is dictating the size instead of the Image. But now our image is skewed again! We need to fix that.

// Come on!!!
ZStack {
    Rectangle()
        .fill(Color(.gray))
	.aspectRatio(4/3, contentMode: .fit)
            
    Image("bungalows")
	.resizable()
	.aspectRatio(contentMode: .fill) // fix skewed image
	.layoutPriority(-1)
}

Note: the blue square is there to indicate where the Rectangle is. This wouldn’t be visible in the UI.

One last modifier and we’ve got this! We’re bringing .clipped() back!

// Yes!
ZStack {
    Rectangle()
	.fill(Color(.gray))
	.aspectRatio(4/3, contentMode: .fit)
            
    Image("bungalows")
	.resizable()
	.aspectRatio(contentMode: .fill)
	.layoutPriority(-1)
}
.clipped() // magic

The Solution

Now that we finally have a working solution, we need to make this reusable so that we never have to go through this again.

Let’s convert this to a ViewModifier so that we can apply it to any Image.

A few things to note about the final solution:

• We added an AspectRatio enum for the most common usages in the Vrbo iOS app. This solution supports both our predefined aspect ratios as well as a custom aspect ratio.
• .resizable() was moved to the Image extension. .resizable() can only be applied to an Image, so it cannot be applied inside of the ViewModifier, which expects Content that could be any type of View.
• .aspectRatio(contentMode: .fill) was replaced with its shortcut modifier, .scaleToFill()
• We set the Rectangle fill color to be .clear instead of .gray. The only time the Rectangle would ever show would be if the image failed to render. For the Vrbo iOS app, we typically combine this modifier with other modifiers for providing a fallback state. However, this modifier could be expanded to support a fallback image or a fallback color.

Usage

Image("resorts")
    .fitToAspectRatio(.square)

Image("resorts")
    .fitToAspectRatio(.fourToThree)

Image("resorts")
    .fitToAspectRatio(.threeToFour)

Image("resorts")
    .fitToAspectRatio(1.5)
    .clipShape(RoundedRectangle(cornerRadius: 8))

Now, no matter the size of a container View, our image will always render to our desired aspect ratio without becoming distorted. Thanks for reading!

Learn more about technology at Expedia Group.

Resizing Images in SwiftUI was originally published in Expedia Group Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Getting started with SwiftUI in Vrbo iOS apps

With the second major release of SwiftUI®, we can now use it to build an entire app for multiple Apple® platforms. After the announcements at WWDC 2020, it was clear that we needed to bring SwiftUI capabilities to the Vrbo™️ (part of Expedia Group™) iOS apps as soon as possible. Here are some of the lessons we’ve learned.

SwiftUI == Less Code

The code speaks for itself; here’s an apples to apples comparison of how to implement the simple view below in SwiftUI versus UIKit.

SwiftUI Implementation

UIKit Implementation

The code above leverages SwiftUI view modifiers added to Vrbo’s internal UI library. The UIKit equivalents to these SwiftUI view modifiers are many times larger in terms of lines of code.

SwiftUI in iOS 13 != SwiftUI in iOS 14

Just because some functionality or component exists in UIKit, does not mean that there will be an equivalent in SwiftUI. UIPageViewController, UIProgressView and others did not have a SwiftUI equivalent until iOS 14 and there are a few that still don’t (UISearchController, UIImagePickerController, etc.)¹. A complete list of UIKit components and their SwiftUI counterparts can be found here.

Until our app drops support for iOS 13, we likely won’t be able to leverage all of the new SwiftUI capabilities highlighted at WWDC 2020.

Lazy Stacks

Specifically, we need to keep our UICollectionViews around while we support iOS 13. Their replacements, LazyVStack and LazyHStack, give us the same benefit of a UICollectionView by only creating children when needed for performance. Until then, we can likely use SwiftUI Views inside of the collection view cells, but not for the collection view itself.

SwiftUI does not replace UIKit

At first I thought SwiftUI was a replacement for UIKit, but it is not. SwiftUI leverages UIKit. It is not an API written completely on top of UIKit though. For example, VStacks and HStacks do not render UIStackViews under the hood², but in some cases portions of UIKit are used.
For example, SegmentedPickerStyle leverages UISegmentedControl from UIKit and there are likely other examples where SwiftUI is dependent on some part of UIKit.

Composition order of view modifiers matters

In UIKit, we use class properties to apply styles. We use ViewModifiers to apply styles in SwiftUI and applying them in a different order may have different results.

In the example above, we applied the background color modifier before our size modifiers. We need to flip the order of these to ensure our background color fills the entire size of the button.

Order matters when it comes to duplicate view modifiers as well. With view modifiers, the first application of a modifier takes priority over any subsequent applications.

View modifiers can be applied to several Views at once

I could definitely see a use case where we apply some sort of.textBase() modifier at a very top level View…maybe even an entire module or entire app.

Keep logic separate from SwiftUI Views for unit testing

At the time of writing, there doesn’t seem to be an easy way to inspect views in unit tests without digging into internals (directly or via an external library). We can work around some of this though. By keeping the View logic in its own object, we can unit test that object instead of the View. Let’s look at this in practice with buttons.

We primarily use four styles of buttons in the Vrbo iOS app. Each of these button styles supports different sizes, each style has an inverse version of itself, buttons can have icons or not and we support dark mode too, so we have quite a few variations.

In SwiftUI, the method for styling buttons is the .buttonStyle() view modifier, which accepts a ButtonStyle. Internally, we have a single ButtonStyle that handles all of our variations and we’ve moved all of the view logic for these to a ButtonViewModel.

struct ButtonViewModel {

    // MARK: Config

    let iconMode: ButtonIconMode? // .iconOnly
    let inverse: Bool
    let size: ButtonSize // .large, .medium, .small, .extraSmall
    let type: ButtonType // .primary, .secondary, .link, .overlay
    
    // ...
}

Our ButtonViewModel derives most of its values for the View from the above configuration models as demonstrated in the code snippet below.

Buttons can also have the following states:

The isEnabled property lets us know whether the button is disabled and the isPressed property lets us know if the button is being pressed. We reflect these states in our UI based off of these properties as well as the configuration models.

Here’s how we use this ViewModel in our ButtonStyle.

Now, we can unit test the ViewModel without needing to instantiate a SwiftUI View. Here are some examples of unit tests.

What about SwiftUI and UIKit together?

Like a lot of other apps, Vrbo is and will be in a hybrid state of SwiftUI and UIKit for a little while. How that looks is still taking shape, but Apple provides mechanisms for interoperability.

SwiftUI inside of UIKit

You can wrap SwiftUI Views inside UIViewControllers via UIHostingController, which is how we can start using SwiftUI immediately in our existing apps. It is a definite path forward.

UIKit inside of SwiftUI

You can also wrap UIViews and UIViewControllers inside of SwiftUI Views via UIViewRepresentable and UIViewControllerRepresentable. When I was experimenting with SwiftUI initially, I rewrote several portions of the Trip Boards UI while still leveraging existing UIViews in a few places.

The example above was done for proof of concept purposes, but as we move forward with SwiftUI it will be interesting to see what use cases there are for wrapping like this. My initial thought was that it might make sense to work from the inside out, where you convert your innermost UIViews to SwiftUI views first, resulting in a more one-directional approach. When using a hybrid approach, it can quickly become like the movie Inception³ where it’s a View / UIView / UIViewController within a View / UIView / UIViewController instead of a dream within a dream.

Since SwiftUI Views are more performant than UIViews⁴, it may also make sense to go ahead and convert existing code to SwiftUI versus wrapping existing UIKit code.

// One-directional approach

- UIViewController
    - UIHostingViewController
 	- SwiftUI View
 	    - SwiftUI View
 	    - SwiftUI View

// Hybrid approach

- UIViewController
    - UIHostingViewController
        - SwiftUI View
            - SwiftUI View
            - SwiftUI View
        - UIViewControllerRepresentable
            - UIViewController
                - UIView
 	            - UIHostingViewController
    		        - SwiftUI View

SwiftUI Previews did not work

I think one of the most exciting features of SwiftUI is Previews. It is like hot reloading for web development (it’s actually probably closer to live reloading vs hot reloading). Prior to this, Interface Builder was the mechanism for “previewing” views without building the app, but these were not truly a preview of how the UI would look. Previews also go a step further and allow you to have multiple instances for various states of your UI. So you could have a preview of your view for dark mode, light mode, iPhone or iPad, side-by-side while you’re developing!

I was super stoked for these, but then when it was SwiftUI play time…they didn’t work.

Local Environment

There are a few of requirements for SwiftUI Previews:

• Xcode 11+
• macOS Catalina
• Have iOS 13 or later set as your Deployment Target for your Debug configuration

I met all of these requirements for my local environment, but Previews still did not work in the Vrbo iOS app or for our internal UI library, UIToolkit. So what was up?

Naming Collisions

In both projects, there were naming collisions that were causing SwiftUI Previews to not work. You cannot have a struct/class/enum/protocol that is the same name as your project. These were the fixes:

Another alternative would have been to rename the project instead of the object names.

Project Configuration

After implementing the above fixes, Previews were still not working in the Vrbo iOS app (No!!!). The reason for this may be less common, but the Vrbo iOS app is modularized, so the app is broken up into several frameworks. The app is also still using Carthage for some dependencies. There was an error that one of our dependencies could not be loaded. Previews were looking for these in the wrong place based on our Build Settings. We needed to update the @rpath to look for frameworks in the Carthage build directory for each of our frameworks.

While there is a lot more to dive into with SwiftUI, I hope that these initial learnings have been helpful.

Thanks for reading! ☺

Sources

[1] https://fuckingswiftui.com/#uikit-equivalent-in-swiftui
[2] https://wwdcbysundell.com/2019/swiftui-relationship-to-uikit-appkit/
[3] Inception movie https://en.wikipedia.org/wiki/Inception
[4] https://www.hackingwithswift.com/books/ios-swiftui/why-does-swiftui-use-structs-for-views

Lessons in SwiftUI was originally published in Expedia Group Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.