247: Different, But Not Worse
29:44 Share

Welcome to Under the Radar, a show about independent iOS app development. I'm Marco Arment. And I'm David Smith. Under the Radar, it's usually not longer than 30 minutes, so let's get started. We're going to stick with that forever, huh? Forever. Yeah, we can't say never. All right. So, I have been doing a ton of SwiftUI work since our last episode, since...

You kind of convinced me and I kind of convinced me and mostly you kind of convinced me to, you know, keep diving into SwiftUI. 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. And I have finally reached the point where I have a framework in place that I'm actually motivated to work within. Yeah.

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, like the drag to dismiss on that, like all sorts of stuff like that. My theme system, being able to override dark mode and tint colors programmatically at runtime and have everything update, 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? 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? And so I have finally reached a point where I'm happy to say that I'm getting it and I'm

I'm far from mastering it, and I haven't built that much yet. And I have a ton. 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. 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. There's so much underlying work to do to make all my data models observable, make the audio engine observable, all that stuff.

so that there's a lot to do there but i i have a good working prototype of the interface and i'm happy with where it is on uh on iphone and ipad and actually last night i even got it running not well but running natively on mac um because nice this is one of the little things about swift ui that i that i i'm i've been pleasantly discovering that

So much about it is also available on Mac without code change. Now, there are some little annoying things. Like, you know, I try to place toolbar items and I go, oh, actually, you can't place toolbar items in the navigation leading configuration on Mac. Okay, I'm sure there's a reason I haven't gotten to it yet. There's a few things like that that you just, you know, you got to kind of if-def out for Mac. But...

There's a lot of the underlying work to do things like you don't have to deal with UI color and then NS color on Mac. You just deal with the SwiftUI color, and it does that for you. It abstracts that away on the different platforms. You don't have to deal with whatever the dark mode API is on the Mac because it's not UIKit. You just deal with color scheme from SwiftUI, and it deals with that. So there's things like that that are actually nicer. Font management, all that stuff is actually nicer to use.

doing it through SwiftUI than trying to have, like, shared code between UIKit and AppKit. So...

there's all this stuff like that and by the way this is not an announcement of overcasting the mac i i given how different it it looked when i when i ran it on for the first time last night i'm not sure i'm going to even go that route it's probably not going to be worth it but it was at least nice i at least wanted you know any of my like new baseline framework that i'm writing i wanted that to at least be easily cross-platform and not unnecessarily call into ui kit for anything so that's that's why i did that but

I'm probably not going to make a full-blown Mac app. I'm probably going to use Catalyst at best. So anyway, so that being said, my Swift UI journey is going fairly well. It's going to be very long. I can tell already this is going to take a very long time. But I am finally starting to stay motivated and enjoy it and want to come back to work on it. So that's where I am.

I think that's great to hear. And I think it's unfortunate that it is difficult to get to that place. It is unfortunate that it isn't the kind of thing that there is this easy, obvious on-ramp that was straightforward and it's just sort of walking through a field of wildflowers with a gentle breeze. It's just lovely. It's like, no, this is difficult. This is...

you know, a fundamentally restructuring of the way that you both build things and think about things and, you know, are transitioning a set of skills that you developed over the last, you know, like 13 years in a different direction. So fair enough, it's difficult, but it's definitely encouraging. And it's, you know, I think when I was trying to push you in this direction, this is what I hoped would eventually be happening. That it's the kind of thing that knowing that it would be difficult, knowing that there is this

very rough phase but knowing that it is possible to come out the other side in a way that will at least be sort of workable will not you know you that it won't have just sort of broken your spirit and you just like rage quit ios development and run away like right it's you know it it it is doable obviously like because this is very similar to the journey that i went on that the first time i was doing you know swift ui stuff it was very frustrating and was you know hard for me to

wrap my head around and I spent a lot of time going down a lot. The amount of SwiftUI work that I would do, discover that I was doing it entirely the wrong way or in a way that in the end didn't quite work and I needed to throw it out and start again, that was the reality. For me, that was the development of Watchsmith. That app was my first ever foray into proper, big, detailed SwiftUI work. I had done some stuff on the watch, but those are so...

it's such a constrained environment. It was lovely to kind of get, get, get my feet wet, but to actually try it was, you know, it was when I was building Watchsmith and it was very much the sense of like, wow, like it's, it's hard and it's difficult because it's requires a totally different new way of thinking. And there's a lot of,

And SwiftUI is very – it can be opinionated and can be frustrating. Can be. It doesn't do – sure. I mean, you know me. That's the way I tend to talk about things. But it has – when it works, it's great. And so it has enough of that – it has enough going for it that at least for me, it sort of nudges you along. And so it's great to hear that you sort of are coming out of this, if not –

loving SwiftUI, at least feeling comfortable with using it. From now, you have a path that you can continue to walk down. It'll take time and it'll be a difficult thing, but the reality is if Overcast is going to exist in the next 13 years, then this is in some way the path that Apple is pushing us towards. And

you know, be sort of in the future, this, the time you spend, you know, this summer and fall is going to, you know, pay off a lot of dividends into the future, I suspect. Oh, absolutely. I mean, the way I feel now, and we talked about this before, so I'll be quick. But the way I feel now is that, you know, not only is this, you know, the way forward, if I'm going to keep doing this as a career and keep having my app be healthy and up to date, and somewhat future compatible, but

When I look at the modern UI kit advances and changes and deprecations and new classes and new ways of doing things, I am almost equally unfamiliar with modern UI kit stuff as I am with SwiftUI. And if I'm going to pick one of these paths to invest a bunch of time in learning, I think SwiftUI is the wiser one to pick right now. In this year, right now, if I'm going to invest a whole bunch of new time in learning something very new...

I think I'd rather do SwiftUI than try to figure out all of the changes in UIKit over the last few years.

Yeah, I mean, that's – A, I think you're 100% right. I think UIKit is going to be supported for a long time into the future because it's very important to Apple. But I don't – it just doesn't seem to be the area that is going to be getting the most attention. It's going to be getting all the new features, like the number of new system-level things that are SwiftUI only. Obviously, the main one that I'm thinking of is WidgetKit itself.

are those only going to grow? It is only going to be a thing that you're going to have to use SwiftUI in some parts of your app, and then at some point it becomes like, well, then just use it in as many places as you can because otherwise you're having to juggle two different systems and keep them in sync and be able to reuse your code between things. It just makes sense at this point. Yeah, and I think also as indies,

We don't have the luxury, usually, of being able to really get into the nitty-gritty on every single bit of our UI code and really hand-polish every screen. Most apps are more complex than what an indie can do for that, especially in this world where we have...

so many facets of our app that people expect to be there that are more work for us. So things like widgets or a watch app or an iPad and Mac or things like that. There's so many things that we are expected to have in our apps now that

We kind of need the option that puts us, no pun intended, on rails. We need the option that takes away some of the things we can do but makes it way, way, way faster and easier for us to do it and maintain it over time. And 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, but for all of its faults and frustrations, SwiftUI, once you are into it and once you get over some of those hurdles...

I think is the faster option and the more time efficient option for indies especially if you're working by yourself then I think that's even more important yeah absolutely

We are brought to you this week by Sourcegraph. So you've hired a brilliant developer. That's great. Now you have to get them onboarded. If your company is growing, onboarding new developers is a common occurrence, but it's a big undertaking. One of the biggest challenges for new hires to get up to speed with a project their new team is working on. This can be tricky if the code bases your developers are working in are already large. So Sourcegraph makes it easy to move fast, even in those big code bases. We

We know, as developers, knowledge is most useful when it's findable. Centralization is helpful, but given the fact that most companies store knowledge in at least two different locations, how do you make knowledge accessible to those who need it? Sourcegraph is a code intelligence platform. It gives developers what they need to drive their own learning over time and in different situations. Without Sourcegraph, you have to rely on asking colleagues or reviewing documentation that might be out of date. This is cumbersome and time-consuming and error-prone. So

So with Sourcegraph, every developer can search across millions of repositories to find specific code, saving time for themselves and everyone else. So when questions do come up, you know it's just the big stuff that's worthy of the extra time. Sourcegraph was created to make developers' lives easier. Today, they work with leading companies across every industry, including three out of five of the top tech companies, plus PayPal, Uber, Plaid, GE, Reddit, Atlassian, and more. Visit about.sourcegraph.com to learn more.

That's about.sourcegraph.com to find out why some of the biggest tech companies in the world use Sourcegraph and to see what it can do for yours. Or to click the link in our show notes, let them know you heard about them from us. Our thanks to Sourcegraph for the support of this show and RelayFM. So after our discussion, this is sort of from the last episode of talking about SwiftUI, and I think certainly especially in the discussions you've had on ATP recently about the difficulty you've been having with SwiftUI, I think...

So some feedback we got, and I think it was best summarized by – I think we were mentioning something by Ben Packard on Twitter. And he talked about how he had a concern that sort of the difficulty of SwiftUI and the work that we're doing there and having to in some ways adapt our development process and adapt our design to SwiftUI rather than it kind of being the other way around. 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, that we sort of get everything exactly how we want to do it. And very much in the imperative UIKit world, you can make something look and behave to a large degree exactly how you want it to be because you have hooks into everything and you have control over every pixel, everything. Once you start getting into the really deep, low-level stuff in UIKit, you can be doing stuff with layers 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 going to something like SwiftUI. And his concern was that at a certain point, it's like, are we just sort of accepting, you know, sort of 90% of what we want because we want to get the advantages of SwiftUI and then it ends up feeling something kind of

like that is a compromise and that, you know, I think he, so certainly in Ben Packard's example, he was talking about that. He started being an Apple developer because he cared about the, the quality and the design and very much that ethos of, uh, you know, sort of really polishing things to get them perfect. And he worries that if we keep accepting this and it kind of, that it would, whether there'll be the sort of the slow slide away from quality compared to, uh, to like it. And, uh,

I think that's a really interesting discussion for us to have here because I think that is just the reality is like whenever I get feedback like this, and I love getting feedback that makes me think, and this was definitely that kind of a thing of...

is SwiftUI changing my designs? And if so, in what way? And am I comfortable and okay with those changes? And as is very often the case, if you listen to Under the Radar for any amount of time, when I hear about something like this, I tend to try and think of, okay, well, how could I generalize this question? How could I make a mental model that I can help me to rationalize and think this through? And for me, what it came down to is the sense that whenever we're designing something, whenever we're building something,

There are a lot of kind of competing axes that we can optimize for or focus on or put our effort and energy behind. And in this case, like when I think about design objectives, what are sort of the guiding principles we can have? I kind of imagined that you could have like a five – if you imagine sort of like a five-axis spider graph.

And one of the axes is beauty and how sort of pretty, attractive is your design. Another axis might be the ease of use in terms of the usability and how straightforward and obvious it is to your users. And another axis might be the ease of implementation. So how easy it is for me to build and to maintain and to actually do the creation side.

Another axis might be the portability of this design. You know, how well would this work on different platforms, whether that's iPhone, iPad, Mac, or if that's cross-platform to Android or Windows or who knows what.

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? And, you know, a design that works well in those, that is very easy to make accessible and is easy to localize potentially as a trade-off with some of the other axes. And it's like the reality I find is certainly as, you know, as an independent developer, a small team is like, there's no, I only have a certain amount of area that I can put onto that graph.

That, you know, on each of those axes, I can choose how far I want to go. And sort of the shape that results is of a fixed area that I can't optimize for all of those things at once. And, you know, sort of push them all out to the extreme. I only have so much energy. I only have so much time. The famous project management pentagon. Yeah, exactly. And it's like the reality of that is it's like, so I need to decide where am I going to trade off? And

I think it's important for those choices to be, you know, to some degree is conscious and intentional, but the reality is, is it's always, that's always going to be the choice. And I think that's, you know, it's like for me recently, I,

ease of use and easy ease of implementation, um, are probably my two primary things that I'm focused on. Like I want it to be easy to use and easy for me to build and maintain after that is probably beauty and accessibility, um, are probably the next two. And then portability is my lowest. 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. And then you sort of one at the bottom. And, um,

For me, that works. Like for me, that kind of prioritization, that consideration seems to work pretty well. That I, you know, and 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. 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. Every user I get, I need to make the most of their experience of trying the app and have it be something that they immediately understand how it's going to work. And if it's for them, awesome. If it isn't, that's fine. 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. 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 i need to be pragmatic about being able to work on it and that's where for me swift ui has been huge in terms of simplifying the amount of time it takes to maintain things now that i'm you know very proficient with swift ui i can get a lot done quickly and maybe it isn't as beautiful maybe it isn't as polished or under sort of everything is under my control as it would be if i was building all these things in ui kit but i can certainly say like at one point i i had

The main editing screen in Watchsmith, I had actually built in UIKit before I wrote it in SwiftUI, and they have very similar end results, and the SwiftUI version is maybe 20% of the code of the UIKit version.

just in terms of the amount of stuff that I was able to kind of get for free, or it's just kind of built in and natural in that environment. And it's like that 20% is huge for me in terms of ease of implementation. And, you know, in this case, visually they were identical and from a user experience, they were identical, but, but, you know, from an ease of implementation perspective, switch UI has been a huge boon for me there. So anyway, it's like, that's, that's the way that I find these trade-offs and, and,

I certainly get that going down and choosing a tool like, you know, SwiftUI is, does I think lean itself to push us away from maybe some of the beauty or some of the kind of beauty in the sense of if we have a vision for something, being able to implement it exactly to that vision that we can get close to it. We have to kind of make compromises and changes and adaptations to fit the tools. But, you know, the ease of implementation trade off for there, like for me, it works great. And it's something that I feel very comfortable with.

Yeah, I mean, this is a great way to look at it. This, you know, the spider chart slash project management pentagon of these five things. I love this. I'll make it the art for this for this episode so people can look at it as they're listening. But what I what I like about this is like, you know, what makes a good app or a great app is not just beauty 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? I feel like if you're optimizing for portability, you're probably using some kind of web thing like Electron, and at that point, you're out of our wheelhouse. I can't help you. But I think some of these things will still apply in the sense that...

When you're making an app for certain requirements, you make different decisions. Microsoft has to care a lot about things like localization. I don't. My app is not localized. When you're working with a large team, you have to have different priorities versus when you're an indie or something in the middle.

And certain markets for certain apps will value these things differently. So certain markets, for instance, don't really care that much about beauty and care much more about things like how cheap can I get this? Or how easy is this for me or my staff or whatever to use? And so there's all sorts of different trade-offs here. And what I like about SwiftUI so far is that

When I look at my app, 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 either wasn't satisfactory to me or I wanted to polish it up and make it look custom and nice in some way. And so I have so much UI code in my app that is mostly there for customization of appearance or behavior.

And SwiftUI, the walls are much, much more frequent that you hit, and they're much taller walls that you can't overcome. 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. And so as I'm building on SwiftUI so far, and again, I'm still in the very early days, and I'm sure I'm going to go up and down this roller coaster numerous times over the next year it's going to take me to do this. 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 and there are certain things you just can't do and that's that's the walls i'm talking about like

There are certain types of customizations or behaviors or looks that SwiftUI will basically not let you do. 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. And that's the kind of thing I'm trying to avoid doing. What I would like to see instead is,

what can I do with SwiftUI? On ATP, I talked about the example of in the early days of web design, when web browsers, there are certain elements, especially around forms, there were certain elements that you couldn't easily custom style. 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, and the things you couldn't style, you just left them as system behavior.

That's what I want to do with SwiftUI, and I think that's the path forward for great SwiftUI apps. Beauty doesn't have to mean super custom everything.

Beauty can mean you do a really great job with what you have and you leave other things to system default behavior. And in fact, that's actually the expected pattern in many cases. Like on the Mac, for instance, you don't see a lot of Mac apps with custom fonts being used. There's a reason for that. Custom fonts look weird on the Mac. That's not considered the norm. You don't see everything being like an AppKit style interface but with a different font. Whereas on iOS, you see that all the time.

Although it's becoming less and less common. I think that's probably a good thing. So even what qualifies as beauty changes by different platforms, and it changes with the times and with different needs and everything. But I think SwiftUI is very much able to achieve great, beautiful, polished apps. There are just certain areas that it won't let us touch. And

I think that's okay for what it gives us in the other areas of all these trade-offs. It is so much easier for us to implement. It does, generally, it does localize well, and it does generally provide better accessibility accommodations, especially with things like large text settings and bold text and contrast settings and everything. Maintaining a really, really great UI kit design when you have a very large font is difficult. And it's one thing that I've been terrible at with Overcast. I have...

basic support for larger fonts, but I don't have... It's not as good as it could be by far. And...

as I'm writing things in more modern APIs, especially with SwiftUI, that just becomes so much easier. 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. Like if you know the text is only ever going to be one size and you know that, you know, the caption on this line is always going to only fit on one line, you know, you can do certain other things in the design that if things have to be reflowable or expandable, that, you know, you have to make different decisions.

And that's fine. That's generally better. That'll make a better app. A better app is one that doesn't break in more circumstances, right? And so, you know, if your app breaks when you have a very large font, that's not a good design, even if it looks pretty when it's smaller. So anyway, all that is to say, I think SwiftUI is definitely, you know, a different set of trade-offs on this Pentagon, for sure. However, I think it's better for...

modern development and probably for indie development because it lets us get more done with less time and less code 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 you know that way like you know when when next time apple adds something like a new system theme or a new color scheme or dark mode or whatever like 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 you know we're more nimble and we can do things faster and everything like that and you know then when they do things that are more on the feature side like widgets or you know siri intent support or stuff like that we have more time to work on that stuff so i think all of that all of those factor in and it makes it it makes it very clear that indie developers generally don't have the luxury of

super polishing custom UIs, especially with lower level APIs like UIKit or AppKit. We don't have that luxury most of the time. And so doing something where if SwiftUI can get us there, it can get us 90% there in 10% of the time and code, that's generally the option we should take. And that doesn't need to result in sloppy apps. That just results in different design decisions.

Yeah. And I think that final thought of the, it's just different, it isn't necessarily worse, is I think the – maybe it's just me rationalizing my behavior, but it feels very much like that's just the end result, is that you end up with something that is different but not necessarily worse. And in many ways, it's better in other categories or better in different ways than –

I've gone through this big redesign of Widgetsmith that's going to be coming out in this fall iOS 16 update. I've been working on a big redesign to my editor there. And a lot of this is...

Coming from a place where I realized that the old design that I did, which for the Widgessmith editor and the Watchsmith editor was this kind of – you had these cards that you would tap on and they would kind of pull up and down. But it was very much this slightly skeuomorphic – they're almost like index cards with headers on them. And it was a design that at the time I thought was like – it looked cool. And I thought it was sort of very much emphasizing the kind of like the beautiful side.

But I found that in practice, it was limiting my ability for things like accessibility and localization because it just didn't scale at all if you wanted to do the very large dynamic type sizes because all the cards just like collapsed on themselves and it didn't work.

And so I've been redesigning it and I've been redesigning it for, you know, very much optimizing for accessibility, localization and ease of use. Like those axes are where I am super pushing out on. And the new editor is not as beautiful. I don't think I think it's, it's, it looks nice. It's attractive, but it's, it's very much more just like it's very plain and gets the job done. And I feel good about that. I feel good about that because it is different and it's worse insofar as it isn't necessarily as beautiful, but it is better in something else. And,

And I think sometimes just feeling... One of the skills I think I've picked up as I've been a developer for longer is being okay with that sense that...

Seeing things as different but not necessarily worse. That it's a different set of trade-offs and understanding that you always are – everything is a trade-off. Like you can't have your kegadita too. You can't have both things because that's just not the reality of life. You're going to always be sort of having to weigh and balance all of these things. It can be –

the tension between how I spend my time. It can be the tension between how long it spends to build things, how reliable it is, how many bugs there are, how flexible it is into the future, into the past. There's so many things that you're always trying to balance. And ultimately, it's like none of those is right and none of those is wrong. They're just different, and they have different trade-offs that you're balancing with. And it's like I found I feel pretty good about where I'm lying on that spectrum now, that I feel good about putting my emphasis into ease of use and implementation,

And that's where I'm, you know, that's where I'm spending my area on that graph. And I feel good about that. And that's different. And I think, but the reality is, is like, I've found that the last, you know, the last sort of maybe year, year and a half that I've been, that's been my primary focus. And I've been worrying less about the,

kind of just like conventionally attractive part of my app development, maybe it's been freeing. It's been nice. It's been something that in the end result is something that is, you know, it's sort of somewhat attractive, but that's not, that's not my focus and that's okay. And I think that's a good lesson that I've learned for myself. And I hope that other people can sort of benefit from just hearing me discuss going on this journey, that it's like, just understand that you only, you are a finite person with a finite sense, you know, a finite amount of time and ability to,

It's like spend that in ways that you can get the biggest outcome from rather than worrying about sort of living up to some abstract standard that you are sort of putting on yourself or feel like other people are putting on your development and your products. Thanks for listening, everybody, and we'll talk to you in two weeks. Bye.