Under the Radar

247: Different, But Not Worse


00:00:00   Welcome to Under the Radar, a show about independent iOS app development.

00:00:04   I'm Marco Arment.

00:00:05   And I'm David Smith.

00:00:06   Under the Radar is usually not longer than 30 minutes, so let's get started.

00:00:09   We're gonna stick with that forever, huh?

00:00:11   Forever.

00:00:12   Yeah, we can't say never.

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:00:57   Like the drag to dismiss on that, like all sorts of stuff like that.

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:22   And so I have finally reached a point where I'm happy to say that I'm getting it.

00:01:28   And I'm far from mastering it, and I haven't built that much yet.

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:01:58   So there's a lot to do there.

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:36   Okay, I'm sure there's a reason I haven't gotten to it yet.

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:50   You just deal with the SwiftUI color, and it does that for you.

00:02:54   You know, it abstracts that away on the different platforms.

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:01   You just deal with color scheme from SwiftUI, and it deals with that.

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:16   So there's all this stuff like that.

00:03:19   And by the way, this is not an announcement of overcast on the Mac.

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:29   It's probably not going to be worth it.

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:42   So that's why I did that.

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:03:47   So anyway.

00:03:48   So that being said, my SwiftUI journey is going fairly well.

00:03:54   It's going to be very long.

00:03:57   I can tell already this is going to take a very long time.

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:07   So that's where I am.

00:04:09   That's great to hear.

00:04:11   And I think it's unfortunate that it is difficult to get to that place.

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:23   And it's just sort of walking through a field of wildflowers with a gentle breeze.

00:04:29   It's just lovely.

00:04:31   It's like, no, this is difficult.

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:47   So fair enough. It's difficult.

00:04:49   But it's definitely encouraging.

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:15   It is doable, obviously, because this is very similar to the journey that I went on.

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:29   And I spent a lot of time going down.

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:05:41   that was the reality.

00:05:43   For me, that was the development of WatchSmith.

00:05:45   That app was my first ever four-way into proper, big, detailed SwiftUI work.

00:05:50   I had done some stuff on the watch, but those are so...

00:05:55   It's such a constrained environment. It was lovely to kind of get my feet wet,

00:05:58   but to actually try it was when I was building WatchSmith.

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:10   and SwiftUI can be opinionated and can be frustrating.

00:06:17   It can be.

00:06:18   I mean, you know me. That's the way I tend to talk about things.

00:06:21   But when it works, it's great.

00:06:25   And so it has enough going forth that, at least for me, it nudges you along.

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:42   and that, yeah, it'll take time and it'll work. It'll be a difficult thing.

00:06:45   But the reality is if Overcast is going to exist in the next 13 years,

00:06:51   then this is in some way the path that Apple is pushing us towards.

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:14   and keep having my app be healthy and up to date and somewhat future compatible,

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:28   I am almost equally unfamiliar with modern UI kit stuff as I am with SwiftUI.

00:07:35   And if I'm going to pick one of these paths to invest a bunch of time in learning,

00:07:39   I think SwiftUI is the wiser one to pick right now. Like in this year, right now,

00:07:44   if I'm going to invest a whole bunch of new time in learning something very new,

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:54   Yeah, I mean, that's... A, I think you're 100% right.

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:32   because otherwise you're having to juggle two different systems and keep them in sync

00:08:36   and be able to reuse your code between things. It just makes sense at this point.

00:08:41   Yeah, and I think also, as indies, we don't have the luxury, usually,

00:08:48   of being able to really get into the nitty-gritty on every single bit of our UI code

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:50   especially if you are working by yourself, then I think that's even more important.

00:09:54   Yeah, absolutely.

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:43   This is cumbersome and time consuming and error prone.

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:06   plus PayPal, Uber, Plaid, GE, Reddit, Atlassian, and more.

00:11:11   Visit about.sourcegraph.com to learn more.

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:25   Our thanks to Sourcegraph for the support of this show and Relay FM.

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:12   that we sort of get everything exactly how we want to do it.

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:41   going to something like SwiftUI. And his concern was that at a certain point,

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:52   and then it ends up feeling something kind of like that is a compromise.

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:27   Whenever I get feedback like this, and I love getting feedback that makes me think,

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:38   and am I comfortable and okay with those changes?

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:23   and how pretty attractive is your design.

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:49   or if that's cross-platform to Android or Windows or who knows what.

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:08   potentially is a trade-off with some of the other axes.

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:39   The famous project management pentagon.

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:53   but the reality is that's always going to be the choice.

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:07   Like I want it to be easy to use and easy for me to build and maintain.

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:23   and then there's one at the bottom. And for me that works.

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:16:55   and have it be something that they immediately understand how it's going to work.

00:16:59   And if it's for them, awesome. If it isn't, that's fine.

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:14   I need to be pragmatic about being able to work on it.

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:02   And that 20% is huge for me in terms of ease of implementation.

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:35   or we have to kind of make compromises and changes and adaptations to fit the tools.

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:18   and at that point, you're out of our wheelhouse. I can't help you.

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:02   And so as I'm building on SwiftUI so far, and again, I'm still in the very early days,

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:45   And that's the kind of thing I'm trying to avoid doing.

00:21:48   What I would like to see instead is, what can I do with SwiftUI?

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:21:59   there were certain elements that you couldn't easily custom style.

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:09   And the things you couldn't style, you just left them as system behavior.

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:16   Beauty doesn't have to mean super custom everything.

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:26   And in fact, that's actually the expected pattern in many cases.

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:44   Whereas on iOS, you see that all the time.

00:22:47   Although it's becoming less and less common, I think that's probably a good thing.

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:22:58   But I think SwiftUI is very much able to achieve great, beautiful, polished apps.

00:23:06   There are just certain areas that it won't let us touch.

00:23:09   And I think that's okay for what it gives us in the other areas of all these tradeoffs.

00:23:15   It is so much easier for us to implement.

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:35   And it's one thing that I've been terrible at with Overcast.

00:23:38   I have basic support for larger fonts but it's not as good as it could be by far.

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:14   And that's fine. That's generally better. That will make a better app.

00:24:17   A better app is one that doesn't break in more circumstances.

00:24:20   And so if your app breaks when you have a very large font, that's not a good design.

00:24:24   Even if it looks pretty when it's smaller.

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:44   Because it lets us get more done with less time and less code.

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:12   We're more nimble and we can do things faster and everything like that.

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:22   we have more time to work on that stuff.

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:55   That just results in different design decisions.

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:13   is that you end up with something that is different but not necessarily worse.

00:26:16   And in many ways, it's better in other categories or better in different ways than --

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:29   I've been working on a big redesign to my editor there.

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:38   which for the WidgetSmith editor and the WatchSmith editor was this kind of --

00:26:41   you had these cards that you would tap on and they would kind of pull up and down,

00:26:45   but it was very much this slightly skeuomorphic -- they're almost like index cards with headers on them.

00:26:50   And it was a design that at the time I thought was like -- it looked cool,

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:08   because all the cards just like collapsed on themselves and it didn't work.

00:27:12   And so I've been redesigning it, and I've been redesigning it for --

00:27:16   very much optimizing for accessibility, localization, and ease of use.

00:27:19   Like those axes are where I am super pushing out on,

00:27:22   and the new editor is not as beautiful, I don't think.

00:27:25   I think it looks nice, it's attractive, but it's very much more just like --

00:27:29   it's very plain and gets the job done.

00:27:31   And I feel good about that.

00:27:33   I feel good about that because it is different,

00:27:35   and it's worse insofar as it isn't necessarily as beautiful, but it is better in something else.

00:27:39   And I think sometimes just feeling --

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:27:53   that it's a different set of trade-offs and understanding that you always are --

00:27:57   everything is a trade-off.

00:27:58   Like you can't have your K to D to 2.

00:28:00   You can't have both things because that's just not the reality of life.

00:28:05   You're going to always be sort of having to weigh and balance all of these things.

00:28:09   It can be the tension between how I spend my time,

00:28:12   it can be the tension between how long it spends to build things,

00:28:15   how reliable it is, how many bugs there are,

00:28:18   how flexible it is into the future, into the past.

00:28:21   There's so many things that you're always trying to balance.

00:28:23   And ultimately, it's like none of those is right and none of those is wrong.

00:28:27   They're just different, and they have different trade-offs that you're balancing with.

00:28:31   And I feel pretty good about where I'm lying on that spectrum now,

00:28:35   that I feel good about putting my emphasis into ease of use and implementation,

00:28:40   and that's where I'm spending my area on that graph.

00:28:44   And I feel good about that.

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:03   It's been freeing. It's been nice.

00:29:04   It's been something that, in the end result, is something that is somewhat attractive,

00:29:08   but that's not my focus, and that's okay.

00:29:11   And I think that's a good lesson that I've learned for myself,

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.

00:29:25   Spend that in a place that you can get the biggest outcome from,

00:29:29   rather than worrying about living up to some abstract standard that you are putting on yourself

00:29:34   or feel like other people are putting on your development and your products.

00:29:38   Thanks for listening, everybody, and we'll talk to you in two weeks. Bye.

00:29:43   [BLANK_AUDIO]