00:00:14 ◼ ► Alright, so I have been doing a ton of SwiftUI work since our last episode, since you kind of convinced me,
00:00:23 ◼ ► and I kind of convinced me, and mostly you kind of convinced me to, you know, keep diving into SwiftUI.
00:00:28 ◼ ► And I've gone through a lot of trials and tribulations and a lot of trial and error and a lot of other metaphors that contain the word "trial."
00:00:37 ◼ ► And I have finally reached the point where I have a framework in place that I'm actually motivated to work within.
00:00:46 ◼ ► You know, because what I tried to do first was the hardest part, which is navigation, split view, and my now playing screen animation kind of things.
00:01:00 ◼ ► My theme system, being able to override dark mode and tint colors programmatically at runtime and have everything update.
00:01:06 ◼ ► All of that stuff, that's what I was tackling for this handful of weeks here, because I wanted to see, like, can I get the hard stuff in place?
00:01:15 ◼ ► Can I get things like my theme system up and running so that I can actually build other simpler things and have it match the rest of the app, and so on.
00:01:34 ◼ ► And I have a ton, like, you know, right now I'm doing all this in a little prototype app, so it's not part of my main app, so it's just using sample data and everything else.
00:01:41 ◼ ► And so I have a ton of integration work to do once I want to move this into the main app and actually have it be functioning on real data and a real audio player and things like that.
00:01:51 ◼ ► There's so much underlying work to do to make all my data models observable, make the audio engine observable, all that stuff.
00:02:00 ◼ ► But I have a good working prototype of the interface, and I'm happy with where it is on iPhone and iPad.
00:02:11 ◼ ► And actually, last night, I even got it running, not well, but running natively on Mac.
00:02:17 ◼ ► Because this is one of the little things about SwiftUI that I've been pleasantly discovering that so much about it is also available on Mac without code change.
00:02:27 ◼ ► Now, there are some little annoying things, like I try to place toolbar items, and I think, "Oh, actually, you can't place toolbar items in the navigation leading configuration on Mac."
00:02:39 ◼ ► There's a few things like that that you just, you know, you gotta kind of if-dev out for Mac.
00:02:42 ◼ ► But there's a lot of the underlying work to do things like, you know, you don't have to deal with UI color and then NS color on Mac.
00:02:56 ◼ ► You don't have to deal with whatever the dark mode API is on the Mac, because it's not UIKit.
00:03:04 ◼ ► So there's things like that that are actually nicer font management, you know, all that stuff is actually nicer doing it through SwiftUI than trying to have shared code between UIKit and AppKit.
00:03:21 ◼ ► Given how different it looked when I ran it on the first time last night, I'm not sure I'm going to even go that route.
00:03:30 ◼ ► But it was at least nice. I at least wanted any of my new baseline framework that I'm writing, I wanted that to at least be easily cross-platform and not unnecessarily call into UIKit for anything.
00:03:43 ◼ ► But I'm probably not going to make a full-blown Mac app. I'm probably going to use Catalyst at best.
00:04:01 ◼ ► But I am finally starting to stay motivated and enjoy it and want to come back to work on it.
00:04:16 ◼ ► It is unfortunate that it isn't the kind of thing that there is this easy, obvious on-ramp that was straightforward.
00:04:33 ◼ ► This is a fundamentally restructuring of the way that you both build things and think about things.
00:04:40 ◼ ► And transitioning a set of skills that you developed over the last 13 years in a different direction.
00:04:50 ◼ ► I think when I was trying to push you in this direction, this is what I hoped would eventually be happening.
00:04:57 ◼ ► It's the kind of thing that knowing that it would be difficult, knowing that there is this very rough phase,
00:05:03 ◼ ► but knowing that it is possible to come out the other side in a way that will at least be sort of workable.
00:05:09 ◼ ► It won't have just broken your spirit and you just rage quit iOS development and run away.
00:05:20 ◼ ► The first time I was doing SwiftUI stuff, it was very frustrating and it was hard for me to wrap my head around.
00:05:31 ◼ ► The amount of SwiftUI work that I would do, discover that I was doing it entirely the wrong way,
00:05:36 ◼ ► or in a way that in the end didn't quite work and I needed to kind of throw it out and start again,
00:06:02 ◼ ► And it was very much the sense of like, wow, it's hard and it's difficult because it requires a totally different new way of thinking
00:06:30 ◼ ► And so it's great to hear that you are coming out of this, if not sort of loving SwiftUI,
00:06:36 ◼ ► but at least feeling comfortable with using it, and that from now you have a path that you can continue to walk down
00:06:55 ◼ ► And in the future, the time you spend this summer and fall is going to pay off a lot of dividends into the future, I suspect.
00:07:04 ◼ ► Oh, absolutely. I mean, the way I feel now, and we've talked about this before, so I'll be quick,
00:07:08 ◼ ► but the way I feel now is that not only is this the way forward if I'm going to keep doing this as a career
00:07:19 ◼ ► but when I look at the modern UI kit advances and changes and deprecations and new classes and new ways of doing things,
00:07:47 ◼ ► I think I'd rather do SwiftUI than try to figure out all of the changes in UI kit over the last few years.
00:07:58 ◼ ► I think UI kit is going to be supported for a long time into the future because it's very important to Apple,
00:08:05 ◼ ► but it just doesn't seem to be the area that is going to be getting the most attention,
00:08:09 ◼ ► is going to be getting all of the new features. Like the number of new system-level things that are SwiftUI only,
00:08:16 ◼ ► obviously the main one that I'm thinking of is WidgetKit, are those only going to grow?
00:08:22 ◼ ► They're only going to be a thing that you're going to have to use SwiftUI in some parts of your app,
00:08:27 ◼ ► and then at some point it becomes like, well, then just use it in as many places as you can,
00:08:53 ◼ ► and really hand polish every screen. Most apps are more complex than what an indie can do for that,
00:09:01 ◼ ► especially in this world where we have so many facets of our app that people expect to be there
00:09:09 ◼ ► that are more work for us, so things like widgets or a watch app or an iPad and Mac or things like that.
00:09:15 ◼ ► There are so many things that we are expected to have in our apps now that we kind of need the option
00:09:22 ◼ ► that puts us, no pun intended, on Rails. We need the option that takes away some of the things we can do,
00:09:28 ◼ ► but makes it way, way, way faster and easier for us to do it and maintain it over time.
00:09:32 ◼ ► I think SwiftUI is better at that than UIKit. For all of its faults, and again, I don't know it that well so far,
00:09:39 ◼ ► but for all of its faults and frustrations, SwiftUI, once you are into it and once you get over
00:09:44 ◼ ► some of those hurdles, I think is the faster option and the more time-efficient option for indies,
00:09:56 ◼ ► We are brought to you this week by Sourcegraph. So you've hired a brilliant developer, that's great.
00:10:01 ◼ ► Now you have to get them onboarded. If your company is growing, onboarding new developers is a common occurrence,
00:10:06 ◼ ► but it's a big undertaking. One of the biggest challenges for new hires is to get up to speed
00:10:10 ◼ ► with the project their new team is working on. This can be tricky if the codebases your developers are working in
00:10:14 ◼ ► are already large. So Sourcegraph makes it easy to move fast, even in those big codebases.
00:10:20 ◼ ► We know, as developers, knowledge is most useful when it's findable. Centralization is helpful,
00:10:25 ◼ ► but given the fact that most companies store knowledge in at least two different locations,
00:10:28 ◼ ► how do you make knowledge accessible to those who need it? Sourcegraph is a code intelligence platform.
00:10:33 ◼ ► It gives developers what they need to drive their own learning over time and in different situations.
00:10:39 ◼ ► Without Sourcegraph, you have to rely on asking colleagues or reviewing documentation that might be out of date.
00:10:46 ◼ ► So with Sourcegraph, every developer can search across millions of repositories to find specific code,
00:10:51 ◼ ► saving time for themselves and everyone else. So when questions do come up, you know it's just the big stuff
00:10:56 ◼ ► that's worthy of the extra time. Sourcegraph was created to make developers' lives easier.
00:11:01 ◼ ► Today they work with leading companies across every industry, including three out of five of the top tech companies,
00:11:14 ◼ ► That's about.sourcegraph.com to find out why some of the biggest tech companies in the world use Sourcegraph
00:11:20 ◼ ► and to see what it can do for yours. Or click the link in our show notes to let them know you heard about them from us.
00:11:29 ◼ ► So after our discussion, this is sort of from the last episode of talking about SwiftUI,
00:11:35 ◼ ► and I think this is only especially in the discussions you've had on ATP recently about the difficulty you've been having with SwiftUI.
00:11:41 ◼ ► I think some feedback we got, and I think it was best summarized by, I think we were mentioned something by Ben Packard on Twitter,
00:11:50 ◼ ► and he talked about how he had a concern that the difficulty of SwiftUI and the work that we're doing there
00:11:58 ◼ ► and having to in some ways adapt our development process and adapt our design to SwiftUI rather than it being the other way around,
00:12:06 ◼ ► rather than it being that we have this design, we have exactly how we want it to be, and we just make it that way,
00:12:15 ◼ ► And very much in the imperative UI kit world, you can make something look and behave to a large degree exactly how you want it to be
00:12:24 ◼ ► because you have hooks into everything, and you have control over every pixel, everything.
00:12:30 ◼ ► Once you start getting into the really deep low-level stuff in UI kit, you can be doing stuff with layers,
00:12:35 ◼ ► and you can be doing stuff in view to layout, and all those kinds of things that you really have full control that you lose
00:12:45 ◼ ► it's like, are we just sort of accepting 90% of what we want because we want to get the advantages of SwiftUI,
00:12:57 ◼ ► And I think in Ben Packard's example that he was talking about, he started being an Apple developer
00:13:02 ◼ ► because he cared about the quality and the design and very much that ethos of really polishing things to get them perfect.
00:13:13 ◼ ► And he worries that if we keep accepting this, whether there will be the slow slide away from quality compared to UI kit.
00:13:21 ◼ ► And I think that's a really interesting discussion for us to have here because I think that is just the reality.
00:13:31 ◼ ► and this was definitely that kind of a thing of, is SwiftUI changing my designs, and if so, in what way,
00:13:41 ◼ ► And as is very often the case if you've listened to Under the Radar for any amount of time,
00:13:45 ◼ ► when I hear about something like this, I tend to try and think of, okay, well, how could I generalize this question?
00:13:49 ◼ ► How could I make a mental model that I can help me to rationalize and think this through?
00:13:53 ◼ ► And for me, what it came down to is the sense that whenever we're designing something, whenever we're building something,
00:14:00 ◼ ► there are a lot of kind of competing axes that we can optimize for or focus on or put our effort and energy behind.
00:14:08 ◼ ► And in this case, when I think about design objectives, what are sort of the guiding principles we can have,
00:14:13 ◼ ► I kind of imagined that you could have a five-axis spider graph, and one of the axes is beauty,
00:14:27 ◼ ► Another axis might be the ease of use in terms of the usability and how straightforward and obvious it is to your users.
00:14:34 ◼ ► Another axis might be the ease of implementation, so how easy is it for me to build and to maintain
00:14:40 ◼ ► and to actually do the creation side. Another axis might be the portability of this design,
00:14:45 ◼ ► you know, how well would this work on different platforms, whether that's iPhone, iPad, Mac,
00:14:54 ◼ ► And then the other sort of the fifth axis that I can kind of think about is, is this design good for things like accessibility and localization?
00:15:02 ◼ ► And, you know, a design that works well in those cases, that is very easy to make accessible and is easy to localize,
00:15:12 ◼ ► And it's like the reality I find is certainly as an independent developer or a small team is like,
00:15:19 ◼ ► I only have a certain amount of area that I can put onto that graph, that on each of those axes I can choose how far I want to go,
00:15:27 ◼ ► and sort of the shape that results is of a fixed area that I can't optimize for all of those things at once,
00:15:34 ◼ ► and sort of push them all out to the extreme. I only have so much energy, I only have so much time.
00:15:42 ◼ ► Yeah, exactly. And it's like the reality of that is, so I need to decide where am I going to trade off?
00:15:48 ◼ ► And I think it's important for those choices to be, to some degree, conscious and intentional,
00:15:57 ◼ ► And I think that's, you know, it's like for me recently, ease of use and ease of implementation are probably my two primary things that I'm focused on.
00:16:10 ◼ ► After that is probably beauty and accessibility are probably the next two, and then portability is my lowest.
00:16:16 ◼ ► Like if I was going to kind of rank those out, I have sort of two sets of things that are roughly equal to their peer,
00:16:27 ◼ ► Like for me, that kind of prioritization, that consideration seems to work pretty well.
00:16:33 ◼ ► But I, you know, probably if I'm thinking of it, really it's like for me the number one thing I tend to optimize for is ease of use.
00:16:41 ◼ ► I want my apps to be easy and intuitive, because if they aren't, I don't have the marketing resources to kind of make up with that in volume.
00:16:50 ◼ ► I need every user I get, I need to make the most of their experience of trying the app,
00:17:02 ◼ ► But I don't want it to be that people are bouncing out of my app because they don't understand it or don't know how it works.
00:17:07 ◼ ► So ease of use is number one, and then ease of implementation, sort of number two, in the sense of like I need to be able to continue working on this.
00:17:16 ◼ ► And that's where for me SwiftUI has been huge in terms of simplifying the amount of time it takes to maintain things.
00:17:23 ◼ ► Now that I'm very proficient with SwiftUI, I can get a lot done quickly, and maybe it isn't as beautiful, maybe it isn't as polished,
00:17:31 ◼ ► or sort of everything is under my control as it would be if I was building all these things in UIKit.
00:17:36 ◼ ► But I can certainly say, at one point, the main editing screen in WatchSmith, I had actually built in UIKit before I wrote it in SwiftUI.
00:17:45 ◼ ► And they have very similar end results, and the SwiftUI version is maybe 20% of the code of the UIKit version,
00:17:56 ◼ ► just in terms of the amount of stuff that I was able to get for free, or it's just kind of built in and natural in that environment.
00:18:06 ◼ ► And in this case, visually, they were identical, and from a user experience, they were identical.
00:18:10 ◼ ► But from an ease of implementation perspective, SwiftUI has been a huge boon for me there.
00:18:14 ◼ ► So, anyway, that's the way that I find these trade-offs, and I certainly get that going down and choosing a tool like SwiftUI does, I think,
00:18:23 ◼ ► lean itself to push us away from maybe some of the beauty, or some of the kind of beauty in the sense of,
00:18:29 ◼ ► if we have a vision for something, being able to implement it exactly to that vision, that we can get close to it,
00:18:39 ◼ ► So, the ease of implementation trade-off there, for me, it works great, and it's something that I feel very comfortable with.
00:18:46 ◼ ► Yeah, this is a great way to look at it, this spider chart/project management pentagon of these five things.
00:18:52 ◼ ► I love this. I'll make it the art for this episode so people can look at it as they're listening.
00:18:57 ◼ ► But what I like about this is, what makes a good app or a great app is not just beauty,
00:19:05 ◼ ► or is not just a certain degree of UI polish. It's all of these things. A great app, I mean, portability. Who cares about that?
00:19:14 ◼ ► I feel like if you're optimizing for portability, you're probably using some kind of web thing like Electron,
00:19:23 ◼ ► But I think some of these things will still apply, in the sense that when you're making an app for certain requirements,
00:19:31 ◼ ► you make different decisions. Microsoft has to care a lot about things like localization.
00:19:35 ◼ ► I don't. My app is not localized. When you're working with a large team, you have to have different priorities,
00:19:43 ◼ ► versus when you're indie or something in the middle. And certain markets for certain apps will value these things differently.
00:19:51 ◼ ► So certain markets, for instance, don't really care that much about beauty, and care much more about things like,
00:19:58 ◼ ► "How cheap can I get this?" or "How easy is this for me or my staff or whatever to use?"
00:20:05 ◼ ► So there's all sorts of different trade-offs here. What I like about SwiftUI so far is that when I look at my app,
00:20:15 ◼ ► it is tons and tons of UI code. And much of the reason why there's so much UI code is that the stock behavior of UIKit
00:20:25 ◼ ► either wasn't satisfactory to me, or I wanted to polish it up and make it look custom and nice in some way.
00:20:32 ◼ ► And so I have so much UI code in my app that is mostly there for customization of appearance or behavior.
00:20:40 ◼ ► And SwiftUI, the walls are much, much more frequent that you hit, and they're much taller walls that you can't overcome.
00:20:49 ◼ ► However, a certain degree of customization is way easier, way faster, way less code, and way more maintainable with SwiftUI than it is with UIKit.
00:21:07 ◼ ► and I'm sure I'm going to go up and down this rollercoaster numerous times over the next year, it's going to take me to do this.
00:21:14 ◼ ► But one thing that SwiftUI, I think, is very good at is getting you a decent amount of beauty and customization and polish without a ton of code, necessarily.
00:21:27 ◼ ► And there are certain things you just can't do. And that's the walls I'm talking about.
00:21:31 ◼ ► There are certain types of customizations or behaviors or looks that SwiftUI will basically not let you do.
00:21:38 ◼ ► And if you want to overcome those, that's when you have to start diving into UIKit or rewriting certain views or controllers in UIKit.
00:21:51 ◼ ► On ETP, I talked about the example of in the early days of web design, when web browsers, there are certain elements, especially around forms,
00:22:02 ◼ ► And so what web designers did at that time was, you just dealt with it and you just did the best job you could with the things that you could style.
00:22:12 ◼ ► That's what I want to do with SwiftUI. And I think that's the path forward for great SwiftUI apps.
00:22:20 ◼ ► Beauty can mean you do a really great job with what you have and you leave other things to system default behavior.
00:22:29 ◼ ► Like on the Mac, for instance, you don't see a lot of Mac apps with custom fonts being used.
00:22:33 ◼ ► There's a reason for that. Custom fonts look weird on the Mac. That's not considered the norm.
00:22:38 ◼ ► You don't see everything being like an app kit style interface but with a different font.
00:22:50 ◼ ► So even what qualifies as beauty changes by different platforms and it changes with the times and with different needs and everything.
00:23:09 ◼ ► And I think that's okay for what it gives us in the other areas of all these tradeoffs.
00:23:19 ◼ ► It does generally localize well and it does generally provide better accessibility accommodations.
00:23:25 ◼ ► Especially with things like large text settings and bold text and contrast settings and everything.
00:23:29 ◼ ► Maintaining a really, really great UI kit design when you have a very large font is difficult.
00:23:43 ◼ ► And as I'm writing things in more modern APIs, especially with SwiftUI, that just becomes so much easier.
00:23:50 ◼ ► And to do that, again, going back to the project management pentagon, to do that, you do lose some of the potential beauty you can create.
00:23:59 ◼ ► If you know the text is only ever going to be one size and you know the caption on this line is always going to only fit on one line,
00:24:05 ◼ ► you can do certain other things in the design that if things have to be reflowable or expandable, that you have to make different decisions.
00:24:26 ◼ ► So anyway, all that is to say, I think SwiftUI is definitely a different set of trade-offs on this pentagon for sure.
00:24:35 ◼ ► However, I think it's better for modern development and probably for indie development.
00:24:48 ◼ ► And therefore we are able to do more things our customers expect in other areas, like features, functionality, breadth of platforms and platform feature support.
00:24:58 ◼ ► That way, when next time Apple adds something like a new system theme or a new color scheme or dark mode or whatever,
00:25:05 ◼ ► next time they do something like that, it doesn't have to make us stop adding all features to our app for an entire year as we get used to it.
00:25:15 ◼ ► And then when they do things that are more on the feature side, like widgets or Siri intent support or stuff like that,
00:25:24 ◼ ► So I think all of those factor in and it makes it very clear that indie developers generally don't have the luxury of super polishing custom UIs,
00:25:37 ◼ ► especially with the lower level APIs like UIKit or AppKit, we don't have that luxury most of the time.
00:25:43 ◼ ► And so doing something where if SwiftUI can get us there, it can get us 90% there in 10% of the time and code,
00:25:51 ◼ ► that's generally the option we should take and that doesn't need to result in sloppy apps.
00:25:58 ◼ ► Yeah. And I think that final thought of the "it's just different, it isn't necessarily worse" is I think the --
00:26:07 ◼ ► maybe it's just me rationalizing my behavior, but it feels very much like that's just the end result,
00:26:21 ◼ ► I've gone through this big redesign of WidgetSmith that's going to be coming out in this fall iOS 16 update.
00:26:31 ◼ ► And a lot of this is coming from a place where I realized that the old design that I did,
00:26:45 ◼ ► but it was very much this slightly skeuomorphic -- they're almost like index cards with headers on them.
00:26:54 ◼ ► and I thought it was sort of very much emphasizing the kind of like the beautiful side.
00:26:59 ◼ ► But I found that in practice it was limiting my ability for things like accessibility and localization
00:27:04 ◼ ► because it just didn't scale at all if you wanted to do the very large dynamic type sizes
00:27:35 ◼ ► and it's worse insofar as it isn't necessarily as beautiful, but it is better in something else.
00:27:42 ◼ ► maybe it's -- one of the skills I think I've picked up as I've been a developer for longer
00:27:47 ◼ ► is being okay with that sense that seeing things as different but not necessarily worse,
00:28:46 ◼ ► And that's different, but the reality is I've found that the last year, year and a half,
00:28:53 ◼ ► that's been my primary focus, and I've been worrying less about the conventionally attractive part of my app development, maybe.
00:29:15 ◼ ► and I hope that other people can benefit from just hearing me discuss going on this journey,
00:29:19 ◼ ► that it's like just understand that you are a finite person with a finite amount of time and ability.