DEV Community

EmpowerApps.Show

SwiftUI - The Good, the Bad, and the Benefits

Video

Related Episodes

Related Links

Sponsors

BrightDigit
  • Specialize in helping businesses build apps for iPhone, iPad, Mac and Apple Watch
  • 10 years of experience developing for a variety of Apple platform
  • Helping dev shops which lack experience with Apple platforms and Swift
Contact me if you need help today.
We have an opening for sponsors
  • Do you have a product or service which can target our ever growing community of developers as well as technology and business leaders? 
Contact me today if you are interested in sponsoring or go to our Patreon page.

Experience and Example Projects

Why SwiftUI Now?

  • Single Source of Truth
  • Declarative vs Imperative Programming
  • Functional Reactive Programming
  • Terminology of SwiftUI and Apple

Why not SwiftUI?

  • Older Operating Systems
  • Using Special UIKit Views and Controls
  • Requires Very Stable App with Good Documentation

Workarounds for SwiftUI

  • Preprocessor Directives and Attributes
  • UIViewRepresentable and UIViewControllerRepresentable

When SwiftUI is Ideal

  • Simple UI
  • Apple Watch
  • Cutting Edge Audience
  • Internal Projects
  • Brand New Apps
  • Cross Apple Platform

Social Media

Email
leo@brightdigit.com

Twitter
BrightDigit - @brightdigit
Leo - @leogdion

LinkedIn
BrightDigit
Leo

Instagram - @brightdigit
Patreon - empowerappshow

Credits

Music from https://filmmusic.io
"Blippy Trance" by Kevin MacLeod (https://incompetech.com)
License: CC BY (http://creativecommons.org/licenses/by/4.0/)

Transcription

Leo Dion (Host): Welcome again to another episode of empowerapps.Show. Thank you for joining me. I'm the host, Leo Dion. This is the BrightDigit podcast where I talk about Swift development, development in the Apple ecosystem, and  just overall updates, changes in ways that managers, CTOs and developers can stay current and up to date with new things coming out when it comes to Swift and Apple products. 

[00:00:36] Today, I'm going to be talking a little bit more about SwiftUI -  the good, the bad, and the benefits. Specifically, I want to talk about my experience and examples of work that I've been doing in SwiftUI over the last few months, and then we'll be getting into why Swift UI is here, why Apple introduced it in 2019 we'll then be talking about why SwiftUI is not really a good use case in a lot of examples. I'll be talking about some workarounds about how to get around that if you still want to use Swift UI. And then we're getting into  when and where Swift UI is the ideal use and what apps or maybe  devices, where Swift UI really makes a lot of sense. 

[00:01:21] So I want to talk a little bit about my experience and examples of where I've been using Swift UI.

[00:01:27] So back in June, I actually did a workshop, and while it was the same month as WWDC, a couple of weeks actually afterwards, I ended up using UI kit for it.  I called it PeoPart because that's the random name generator - what it came up with. Essentially, it's a list of blog posts and comments that you can see on an iOS app.

[00:01:50] I use UIKit for this example. Because at the time I really didn't want to jump into SwiftUI with new developers and risk that. But I will say that with this application I am slowly migrating over to SwiftUI. So the sample app actually available for you on GitHub and they will share a link for folks later in the show  notes.

[00:02:16] But this is a example that I want to see what it'll do and what it will take to convert a UIKit app over to Swift UI and see what exactly happens when I do that. 

[00:02:29] he other example is a app that I'm using or a building for my local coding community. Lansing codes where people in Lansing can see what events and what meetups are taking place.

[00:02:43] It uses the Firebase backend and Web API that Eric, my colleague had built for the local community and uses combine, obviously along with Firebase. It uses Swift UI and I think it's a really great example of where I'm taking a fairly simple app, brand new, basically new app and building it into a iPhone app in this case. 

[00:03:09] Lastly, you probably heard, I've been working on an app called HeartTwitch ,an independent watch app. They use a Swift UI and Vapor as the backend, and the idea of this app is that live streamers can share their heart rate right from their Apple watch and then take that sharing to a web browser window.

[00:03:27] Then use something like OBS for live streaming to share that video. This is a great example of using Swift UI. It's a brand new app. It's Apple watch. It makes a lot of sense because we're talking about streaming data. And so, this is one example where I think that Swift UI works out really well, and that is the Apple watch.

[00:03:46] So you're probably wondering why is Swift UI now? And I think there's a few good reasons. We did an episode back in June with René Cacheaux and Josh Berlin from raywenderlich.com to talk about iOS app architecture and René had some really strong opinions about the issues with storyboards specifically this idea of single source of truth.

[00:04:09] What are your recommendations or your personal styling? 

[00:04:12] René Cacheaux (Guest): I would not recommend anyone using Interface Builder, especially in large teams. 

[00:04:17] Leo Dion (Host): Yes. 

[00:04:17] René Cacheaux (Guest): That's one of the opinions that I do have. It's mostly because with interface builder. You don't have a source of truth. Everything that you put in your storyboard or your nib file is subject to change by the code underneath it.

[00:04:30] And so when you're looking at the storyboard itself and your kind of tweaking the layout and you're taking the constraints and stuff like that, there's nothing stopping the code underneath of completely changing that. And so when there's bugs and stuff, sometimes it's really hard to figure out the root cause, cause you can't just look at the storyboard that's not enough. 

[00:04:46] Leo Dion (Host): He said the problem with storyboards as well with coded applications. If you're doing two of the same thing, then you run into the issue where your UI is not going to look like what you expect it to look like when you build the Storyboard in Interface Builder as opposed to coding. and this can run into issues because you don't have a Single Source of Truth for how your user interface is going to work out.

[00:05:14] What is exactly Single Source of Truth. what Wikipedia says is it's the practice of structuring information models and associated data schema such that every data element is mastered or edited in one place. In other words, you have one central location where data is, as data is added or entered or edited.

[00:05:35] The view automatically updates that accordingly. And what this comes down to is what's called reactive programming or functional reactive programming. And we talked a little bit about this with Jason in our Swift UI episode. Jason has a lot of years of experience building a user interface and reactive programming, reactive frameworks have been around, even back when, Objective-C was the only way to develop an app. And Jason talked about this and how reactive programming is supposed to work. 

[00:06:06] Jason Anderson (Guest): So we all sat down and we looked at it and we started incorporating that into the work that we're doing. It's particularly nice because a lot of the apps we were developing at the time were very heavy with network updates.

[00:06:18] A lot of JSON API requests  that were dependent upon each other. So, you know, you would set up maybe a, an operation queue that you would have to have something before you get to the next and try to create these dependencies. But you know, that code can become a little bit difficult to manage long-term.

[00:06:37] But then when he started showing me how these streams, as they're called on the reactive cocoa world. Basically streams of data that you can subscribe to. We can observe this object. You can subscribe to the data that's coming across and you can manipulate on the fly to get it to what you need. And as those data pieces are coming across, you can filter them based on specific criteria.

[00:07:00] You can map them into other objects, you can trigger new network calls based on the results. It became very easy to tie in a lot of that dependency logic into a single network call, where before we would have, you know, a delegates and operation cues and things just strung out throughout the app. Now we have one simple change function that has that logic kept in one place.

[00:07:24] So it was, it was kind of nice to keep that altogether there, so it was much easier to maintain. 

[00:07:29] Leo Dion (Host): There's some really interesting examples and places where reactive programming has already been used. We see this when it comes to a lot of the JavaScript libraries out there. I think Angular kind of does a Reactive thing - even ReactJS does a bit and VueJs. 

[00:07:46] They all kind of have this idea of having a central place where data is stored and used and reacted to and kind of like a two way binding sort of way. I had some experience with this actually when I used to do a Silverlight development. Yes. How many of you remember SilverLight? 

[00:08:05] The idea is we're shifting away from Apple's suggested pattern of model-view-controller where you have a central controller that listens to model changes and updates the view. And now what we have is a view model-model-view pattern.

[00:08:22] The idea being is that there is a view model, which is a conversion of that model into a data model that the view will use in order to show what is going on. For instance, like you might have a list of people, but that list of people is not just going to have that data object for people, but it might also have some other metadata that you want to display on the screen or view model, which will say things like, what color to show or what font to say, and things like this will be stored in a view model so that the view can update it accordingly.

[00:08:56] Some of the components that are used in reactive programming had been translated over to Combine and Swift UI. And there's some specific terminology that's been used. 

[00:09:05] For instance, we have the idea of a Publisher. So one example is where you're downloading data from a URL, you'll have a Publisher that will have that data or error based on how the status of that network requests went.

[00:09:19] And then you might use functional programming to then map that data and using JSON decoder to a set of people instances or blog content. And then you also have the ability to take errors and be able to map those into, say, an empty list of people. Because in some cases, you may not want to show an error - you may want to just want to show an empty list. Um, so that's the idea of a publisher. It's a stream of events that you then are using. Functional programming can map to specific data or data instances. 

[00:09:53] We also have the idea of a subscriber. A subscriber is something that listens in to a publisher and updates accordingly.

[00:10:02] So when it comes to like functional programming, a lot of your functions are kind of subscribers in a way. The most common subscriber that we see, especially with SwiftUI is the idea of observable objects. So for instance. you create a class, which is your view model, which listening listens into updates of models based on data from a URL.

[00:10:25] The object model does whatever mapping needs to take place and then updates the view model accordingly. We also have like an EnvironmentObject, States, ObservableObjects, things  like this. Depending on how you want that data used throughout the view hierarchy. But the essential idea is like this Observable or Observed object that's then used within Swift UI.

[00:10:48] I think the biggest benefit, what we will see with SwiftUI is we can finally say goodbye to Storyboards. I think Storyboards have gotten as far as they can get essentially. And the biggest problem with Storyboards is that you're  constantl  dealing with a really complex set of user interfaces.

[00:11:13] And I think it also introduced, instead of using UI to build your user interface, we can finally have what's called declarative programming brought into Swift. So before a lot, if you do a coded UI, for instance, you're doing a lot of imparative programming and creating that user interface. Here we're using declarative programming.

[00:11:33] Where we can do things that we've commonly seen when it comes to HTML. So instead of saying, print out paragraph, print this out and this font print, animate this thing accordingly. We're using declarative programming as a way to basically have almost wysiwyg almost declarative way of seeing how of UI is structured using code. 

[00:12:03] So you just put in a paragraph within a div, you don't have to say print paragraph, begin print paragraph and things like this. It's all looks according to how your code looks. Another issue that we see with Storyboards is when we're doing a development within teams. So Alex had a really great point about how storyboards kind of have their own limitations.

[00:12:30] Alex Bush (Guest): There are, there are trade offs for one approach and another, and at some point it breaks down, right? Or. In some cases it doesn't make sense. And specifically I'm talking about, let's say storyboards don't make a breakdown on scale. When you have. I don't know, more than 20 people, let's say working on the app, but then it does make sense to do it right away as you're a one or two people team.

[00:12:55] Leo Dion (Host): Yes

[00:12:57] When it comes to working with teams, I think we see the biggest issue when we're merging different storyboards together or multiple people are working on a single storyboard, as I often suggest, if you're going to do storyboards, make them as small as possible and use storyboard references.

[00:13:11] But in the end working on a team and working with storyboards can be a real challenge. The other benefit that we see with Swift UI is that Apple now has a way to build cross-platform applications that is cross platform within Apple's ecosystem using Swift UI. I don't know how many of you remember Catalyst, but we talked about this in our episode with Daniel Jalkut where we talk about Mac development and how Catalyst kind of ran into certain limitations.

[00:13:44] Daniel Jalkut (Guest): No, it's funny. I had another snap reaction to that during the keynote, and it was basically, I think I tweeted something like. Apple has announced and deprecated a technology all in the space of one keynote, which was basically like: Hey, there's this brand new exciting technology we have that you can adapt your iOS apps to the Mac and you should not use it you should use this new Swift UI. That's not what they said, literally, but..

[00:14:11]Leo Dion (Host):  So can you do a Mac app was Swift UI, but not as necessarily Catalyst? 

[00:14:16] Daniel Jalkut (Guest): Absolutely. Yeah. Swift UI is a native technology on and that, just to clarify, that's the big promise of Swift UI is that it is a native technology on all Apple platforms.

[00:14:27] Leo Dion (Host): Okay. Yeah, 

[00:14:28] Daniel Jalkut (Guest): so it's kind of funny. It means that there are two ways to write a Mac app with Swift UI. 

[00:14:34] Leo Dion (Host): Right? Right. Because you could go to the Project Catalyst route and have basically one bundle essentially, that will work on both iOS and macOS or you can just do a native Mac app and still use Swift UI 

[00:14:49] Daniel Jalkut (Guest): Right or more precisely do a native Swift UI app and have it run on the Mac on iOS, the watch, or the TV. 

[00:14:55] Leo Dion (Host): Right, right. 

[00:14:57] But now, Swift UI allows us a truly cross-platform way to build a Mac app, a watch app and iPhone or iPad app or tvOS app as well. And this goes back to our stuff about HTML. Now we have kind of this way of using almost like a media queries to be able to specify how certain OSes will look in certain ways, using preprocessor directives or things like that as well.

[00:15:26] So why might you not want to use Swift UI? I think if you're using an app that's fairly old and it still supports older operating systems, I think you're probably better off sticking with UIKit or whatever framework you're using. There's just no need and no desire to move things to Swift UI because there's nothing in there the user will really see when it comes to that. 

[00:15:53] So in that case. I think that you probably can stick with UIKit 

[00:15:59] And if your audience tends to be use older devices or uses older operating systems, there's no need to move to Swift UI. There's no benefit to the user in that case. 

[00:16:10] Another problem we see is the lack of documentation. I think this has been a really big challenge. There's a great website that provides kind of some information about some of the issues with lack of documentation when it comes to Apple stuff. I think that can be a real challenge with something that's only been around for six months to a year. You may also require UIKit in a lot of ways.

[00:16:33] First of all, you might have like a third party dependency to UIKit. You're  using some CocoaPod that has some UI widget that uses UIKit and that case it can be a real uphill battle trying to use Swift UI in that case. There's also UI widgets that are just simply missing from Swift UI that we have in UI kit.

[00:16:51] One of the biggest ones I can think of is UICollectionView. Especially with some of the updates we have: data sources and diffable data. It makes a lot sense to stick with UICollectionView in a lot of ways because of all the features that it gives us with UIKit and a lot of robust stuff that they've added over the last few years.

[00:17:13] It makes sense to just go with UICollection and not try to hack something together necessarily in Swift UI. 

[00:17:20] So you're probably wondering, well, how do I still use Swift UI if I have an older application because there are work arounds to get around this. There are things like preprocessor directives.

[00:17:32] You can say that only a newer operating systems have access to certain features that are built on SwiftUI. There's also the ability to interface between UIKit and SwiftUI. For example, when you have a application that is UIKit based and you want to bring in something from Swift UI. We have UIHostingController on iOS.

[00:17:53] Now, UIHostingController is the iOS version of that, but there's one for WatchKit as well as AppKit. And that  allows you to, use a Swift UI element within a UIKit. So that's a one great example. 

[00:18:10] The other thing is that, let's say you will need to bring in something from UIKit to your SwiftUI app.

[00:18:16] In this case, you want to use something like UIViewRepresentable or UIViewControllerRepresentable, which allows you to do that. I don't know how many times I've used a activity indicator from UIKit in order to show a busy like for instance, I'm downloading a URL or making a URL request.

[00:18:35] I'll often times need to make a activity indicator from UIKit and bring that over to SwiftUI.

[00:18:42] So then the question is, when is Swift UI ideal? What is the use case where SwiftUI it makes a lot of sense. I think if your UI is fairly simple, you probably could just stick with using Swift UI. In that case, it makes a lot of sense.

[00:18:56] And an example of this is like that Lansing codes app that I built. Or, for instance, an app that just uses a table views. Why don't I  just use a List in Swift UI? It makes sense and it will work out great if you're willing to work within the limitations of Swift UI, it actually can work with you as opposed to against you.

[00:19:14] And of course that makes sense. If your devices fairly simple, like an Apple watch. I think any Apple watch app, it makes sense to switch over to Swift UI. At some point. Switch UI was built out of the Apple watch UI team, so it makes a lot of sense. 

[00:19:29] The other thing is, are you willing to deal with unstable API and docs?

[00:19:33] If you're willing to deal with that and deal with the challenges and limitations that come up with that, then it's probably okay to just go to Swift UI and if you're starting with a new project and any sort of new application than maybe going with SwiftUI makes a lot of sense. 

[00:19:47] If you're going to start from scratch, you may as well start using Swift UI, especially if you're thinking about migrating to other operating systems within the Apple ecosystem.

[00:19:56] And if your audience let's say people who are really technically inclined, like developers or folks who already are using the latest operating system, then it makes sense to go with Swift UI. In that case, you're willing to deal with whatever issues and be able to deal with the limitations that Swift UI has. There's a great article by Gui Rambo, which I'll link the notes.

[00:20:17] Where he talks about how Swift UI is ready in a lot of cases, and maybe if your audience is the right fit, maybe it's the right time to switch over to using Swift UI, especially if you're starting a new project or something on the Apple watch. So we have a lot of great episodes you might want to catch up on.

[00:20:33] We talk a little bit more about Swift UI and some of the new stuff that came out in WWDC. We have our episode and video that I did about Swift UI and 2020 trends. We also have the episode with Daniel Jalkut on Mac development. We talked about Swift UI and reactive programming with Jason Anderson and then Apple Watch with Gary Sabo.

[00:20:52] And if you're interested more on app architecture, we have a René Cacheaux and Josh Berlin from raywenderlich.com who talked about iOS app architecture and their great book on learning how to do iOS app architecture the right way. You can learn more and catch up with more articles and episodes on my business website brightdigit.com.

[00:21:13] As well as the podcast website. Empowerapps.show. Thanks again for joining me. I look forward to talking to you again on our next episodes.

★ Support this podcast on Patreon ★

Episode source