Under the Radar

48: Late Bloomers


00:00:00   Welcome to Under the Radar, a show about independent iOS app development. I'm Marco Arment.

00:00:05   And I'm David Smith. Under the Radar is never longer than 30 minutes, so let's get started.

00:00:09   Today we want to talk about a topic that is near and dear to me. It is coming late to

00:00:14   things, being late bloomers to new technologies or new techniques or new abilities, things

00:00:19   like interface builder use, things like view controller containment, basically things that

00:00:25   I either didn't do early on or that I minimally used early on or just never even gave a shot

00:00:32   and that I later and more recently have come to realize, oh, this is actually useful or

00:00:38   even maybe now it's useful. Maybe it wasn't that useful in 1.0, but maybe now it has become

00:00:44   more useful over time as Apple has made these things better. This happens to me all the

00:00:48   time. My default reaction to new technologies coming by is I probably don't need that because

00:00:56   much of the time that's true, but that attitude makes it hard to find those times when it's

00:01:02   not true and it often makes me come late to things. Now the benefit of coming late to

00:01:05   things, any of the issues that 1.0 brought, those have probably been worked out or you

00:01:10   will have heard from a bunch of people like this technology or this thing is not worth

00:01:14   using, but the ones that are worth using, by the time you come late to them, yeah, you've

00:01:18   missed some time of potential improvements and efficiencies and everything, but when

00:01:22   you get there, it's really awesome and easy to use and the tools are better and everything's

00:01:27   more stable. It isn't all bad being a conservative curmudgeon like I am about new technologies.

00:01:33   Are you that way at all?

00:01:35   Yeah, so I'm a very strange person in terms of I have these two different mindsets when

00:01:40   it comes to new technologies. So at WVDC, Apple announces, "Here's the whole new

00:01:45   set of stuff that is now available for Apple developers." And I get really excited and

00:01:53   look into and very often start using totally new technologies, things that weren't possible

00:02:00   before that are now possible. And I'll be one of the first people in the world to run

00:02:04   down that and try and use it and see where all it's in. Often it's kind of half broken

00:02:09   and the beta period's really tricky, but I like that part of the development cycle

00:02:12   and enjoy it.

00:02:14   But whenever Apple introduces something that is a replacement or extension to something

00:02:19   existing—and so this is a pattern that I've seen Apple do many times. I started developing

00:02:26   on iPhone OS 2.2, I think was the first OS version that I was building against, which

00:02:32   is way back in the day. And you see what it took to build something then, and now so much

00:02:39   of the stuff that we would write custom frameworks for or have to do ourselves is now just built

00:02:45   into the system. There are all these things that are a problem that we had to solve manually

00:02:51   or directly before, and then Apple comes along and says, "Enough people are doing this.

00:02:56   We should probably create a system method for doing this that'll be more stable and

00:03:00   almost certainly more better resilient against iOS changes." When iOS 9 goes to iOS 10,

00:03:10   Apple's going to make sure that collection view still works correctly, whereas if I've

00:03:15   had my own custom collection view class, suddenly I'm the one who has to go in and make all

00:03:19   the changes to make sure that it works nicely on the new OS. And so Apple is rightfully

00:03:24   so, expanding and expanding the universe of things that we can do.

00:03:29   But I always struggle with the feeling of if I have an existing solution for something

00:03:34   that kind of works and that I'm familiar with, it's a really hard sell to tear down

00:03:41   everything that I built and then replace it with Apple's thing. And especially, like

00:03:45   you said, early on, because in that early phase is when there's the most bugs, and

00:03:51   then you can have the really bad feeling of regret where it's like, "Oh, I should

00:03:55   just go back to doing it the way that I used to do it, because I knew that I knew at least

00:03:58   where all the problems were. If there was a bug, I could fix it." And that was a mindset

00:04:03   that's a very easy trap to get into.

00:04:05   But on the flip side, I definitely look at some of these things, and I wonder if I'm

00:04:10   missing out. And history maybe has shown that in some ways I'm missing out, in some ways

00:04:15   I'm not. Obviously, the best thing is when you see a technology fly by, you don't embrace

00:04:20   it, and then it ends up dying. Like iCloud Core Data Sync, for example, as a technology

00:04:26   that when it came out, I was like, "Ooh, that is interesting. I use Core Data, and

00:04:30   I sync data to a server. I wonder if this would be cool." And I kind of poked around

00:04:36   a little bit, but never really went down that road, because I had an existing infrastructure.

00:04:40   Turns out, that was a great situation. I think that was officially killed this last summer.

00:04:46   And if I'd gone all in on that, I would have been in a world of hurt.

00:04:51   But on the flip side, if I had seen CloudKit when it came out and went in on that, that's

00:04:57   a technology that seems to be ascendant, that seems to be on its way up. And so at this

00:05:04   point, this part of me is like, "Huh, maybe I should be using that. Maybe that would be

00:05:07   a wise thing for me to be using." And having the benefit of time makes that choice a lot

00:05:13   easier, I think. And so there is certainly a benefit to if a technology is being replaced

00:05:20   or improved upon, that I think you can be more conservative. That if it's something

00:05:24   totally new, then just go for it and try it. And if it doesn't work, well, what have

00:05:30   you lost? But having been a bit more conservative when it's something that is just an extension,

00:05:37   for me anyway, feels like the right approach.

00:05:39   It also, it helps to, as you mentioned, catching things when they're ascendant. That really

00:05:45   helps with keeping up with Apple, basically. Keeping up with the new devices that launch,

00:05:51   new OS capabilities. Apple makes it easy on you if you kind of follow their guidelines.

00:05:57   If you kind of take the tracks they lay out for you. They pave out a way that they want

00:06:02   you to do things. Whether it's the language choice, in this case now it's Swift. Whether

00:06:07   it's things like using Interface Builder, using storyboards, using adaptive layouts.

00:06:13   All these things, Apple makes things easy to do things their way. And then generally

00:06:19   speaking, if you do things their way, you will have less friction or things will be

00:06:24   easier for you in the near future as they introduce new technologies, new devices, things

00:06:28   like that. And you don't have to do things their way. But if you don't, you're generally

00:06:34   setting yourself up for more work.

00:06:36   Like for me, one of the biggest things about that was when they brought an adaptive layout

00:06:41   for the iPad. That changed a lot of things for a lot of people because if you had, first

00:06:47   of all, if you had a separate iPad app and an iPhone app, that broke everything because

00:06:51   all of a sudden, well now your iPad app kind of has a reason to have the entire iPhone

00:06:55   app with it so that it can run in skinny mode on the sidebar. And if you were doing things

00:07:00   in a basic way with a typical UI split view controller, things like that, then things

00:07:07   were easier for you. But if you were away from the Apple way, you had more work to do.

00:07:13   >> Yeah, and I think too, it's an interesting point about how Apple tends to strongly sort

00:07:18   of telegraph where they're going with their announcements that this is a pattern that

00:07:22   we've seen many times where Apple introduces a, they solve a problem where they make something

00:07:30   easier that either that fall sometimes when it's, I remember when they first changed

00:07:37   the size of the iPhone, like that was the year that we got auto layout, if I remember

00:07:41   right. And like they do those kinds of moves where they can, because obviously they know

00:07:46   what their roadmap is for the next six months, for the next year, for the next two years,

00:07:51   and they can look forward to what that's going to be and start preparing the ground

00:07:57   for what's going to make development on that platform the best now. And so there's

00:08:03   definitely a wisdom in looking at what are these new technologies and extensions that

00:08:09   they're adding to the frameworks that what is, like, start asking yourself, well, what

00:08:13   could this mean? Like they started adding the size classes and there's, I always remember

00:08:18   it, there was in the first size class WVDC session where there's like, they have the

00:08:22   quadrant of like the compact and wide. And so they have like, this one is this, you know,

00:08:29   these devices fall in this category, these devices fall in this category, these devices

00:08:32   fall in this category, and this category, we don't actually have any devices that

00:08:37   fall into that category yet. And obviously, like superficially, you could say like, huh,

00:08:41   you know, that's just the way it fell out. It's like, no, Apple is actually telling

00:08:43   us that, I think in that case, it was the...

00:08:46   I believe it was the the six plus in landscape, which which has I believe it has the the normal,

00:08:52   which is like iPad size, horizontal class and the compact vertical class.

00:08:56   Yeah, exactly. Like those types of things, like Apple is telling you something there.

00:09:01   And so being aware of it, even if you're not going to adopt the new technology, it's

00:09:05   probably a good thing to be kind of suspicious when they start changing things to see like,

00:09:09   what could this mean down the road? Because they're not going to waste their time just

00:09:13   adding, adding stuff for no reason.

00:09:16   Yeah, I mean, one of the things for me that so to get into some specific examples here,

00:09:20   one of the things for me in this area was view controller containment or having child

00:09:25   view controllers, basically, and implementing your own parent view controllers. And, you

00:09:29   know, for I think for most iOS developers, you've seen, you know, kind of view controller

00:09:34   bloat disease, it is so easy to have tons of code in view controllers, because that's

00:09:40   kind of just where everything falls. And I know there's different models, there's like

00:09:43   MVVM and stuff. I haven't really gotten into any of those yet, so I can't really speak

00:09:46   to them. But every iOS developer has seen the massive view controller syndrome. And

00:09:51   one of the things that helps that a lot is by making child view controllers. So like,

00:09:56   you know, like in Overcast, you know, I'll have like different panels and everything.

00:09:59   And rather than having like, on the now playing screen, there's like the effects panel, rather

00:10:03   than having that be part of the now playing view controller, that is its own view controller

00:10:07   that can be presented or stuck in various places. You know, just using the stock stuff,

00:10:11   using things like popovers and split views and navigation, of course, you know, all these

00:10:15   things, page view controllers, using all those things can get you very, very far. But one

00:10:18   of the biggest things I've done recently, I started making my own parent view controllers

00:10:22   also now. One of the things I did was I have replaced UI split view controller with my

00:10:28   own custom version of something that does fairly similar things, but does them kind

00:10:32   of more my way. Because when I was looking at Overcast code, I have spent so much time

00:10:38   and there was so much like hacky, weird like configuration and exception code, things like,

00:10:43   you know, intercepting trait collection changes and weird things like that, all to get UI

00:10:48   split view controller to do what I wanted. The amount of code I have to just bend this

00:10:53   existing component to my will is so much and so fragile and so hacky, I can actually make

00:11:00   my own split view equivalent controller that just does things the way I want them, the

00:11:03   way I want it to, with actually far less code, like by a mile. Because the built-in components,

00:11:09   they have all these limitations in place that, you know, Apple thinks they should be designed

00:11:13   this way, but the reason, one of the reasons that's necessary is because like they have

00:11:17   all these different options and how you can configure them. They have to work on all these

00:11:20   different ways. They can't make as many assumptions as you can. They can't rule out certain options

00:11:24   that you won't use. So like in their implementations, they're never going to accommodate everything,

00:11:29   but at the same time, they have to be like so complex to accommodate all the things they

00:11:32   do manage to encompass. When you make one for yourself, you can do anything you want

00:11:39   and only what you want. And that's incredibly powerful. And you know, writing everything

00:11:43   yourself is not always the best solution. That's not always a good use of time. But

00:11:47   in cases like this, like I've been fighting with UI split view controller and various

00:11:51   like adaptive layout things for over a year now and it's just like this, I don't need

00:11:56   to do this. Like why am I doing this when I can just write my own? And so I took one

00:11:59   day and like let me see if I can write my own in one day. And sure enough, of course

00:12:02   it was easier than I ever imagined because the view control containment stuff is very

00:12:07   mature now. It's been around for a while. I think what, since I was like five or six.

00:12:12   It's kind of old, right?

00:12:13   >> Six, I think, yeah.

00:12:14   >> Yeah, so it's been around for a while. So all this stuff was very, very easy to do.

00:12:18   I also made a custom UI page view controller. It basically didn't, I wanted to do some

00:12:24   custom gesture and view handling that it just was not capable of doing without tons of hacks.

00:12:29   So I just made my own. And the one I made is not as good as theirs for general purpose

00:12:34   use. But for my use, it's way better and it really is not that much code. And it's

00:12:40   more of like basically removing times where you have to really hack with UIKit. Because

00:12:45   UIKit's so complex, there's so much there that it has to do. And so much of my time

00:12:50   designing interfaces in the past has been fighting UIKit to just try to customize something

00:12:55   the way I want it. And over time it's become easier, but there's still places where you

00:12:59   have to do it. Especially around new technologies like adaptive UI and stuff like that when

00:13:04   those things kind of come out. And so to get yourself out of the business of hacking UIKit

00:13:09   is so freeing and so good for your overall code health and technical debt. I highly recommend

00:13:15   it. And one of the biggest ways to do that is view controller, basically using view controllers

00:13:19   properly and not trying to hack the existing ones if they don't fit your needs.

00:13:22   Yeah, but I think what you're speaking there is such this strange tension that when you

00:13:27   are looking at these new technologies, because the base building blocks in iOS are overall,

00:13:34   I would say, really, really good. Like the number of things that you can build with just

00:13:38   a scroll view is immense. Like, I mean, one of my favorite talks that we already see,

00:13:43   I don't know if they did one this last year, but previously it had always been like, what's

00:13:47   new in UI scroll view? And they would build these really sophisticated interactions that

00:13:53   were just a scroll view at the end of the day. And it's that strange tension where

00:13:59   if you use a page controller, it's like you can get that first thing working really

00:14:05   quickly, but you'll start to run out of runway. And it's a question, I suppose,

00:14:11   of how much control you want to have and how much you want to be responsible for all the

00:14:16   weird edge cases, all the strange issues that are going to happen, I suppose, either way.

00:14:22   If you use UI page controller, there's just going to be some issues that you just can't

00:14:27   work around. And you're just like, oh, well, it just doesn't work the way I like it to

00:14:31   in this particular situation. So then you're like, okay, let me just build my own. And

00:14:35   now, of course, the important thing I think for me is to say is when you do that, it's

00:14:40   good to be sort of cognizant and keep your eyes open for what you're taking on when

00:14:46   you do that. Because, you know, Apple's engineering teams are no, you know, like, they're

00:14:52   not they're no slouches, like they are really good at what they're doing. And it takes

00:14:56   a lot of engineering work to build the UI page controller, for example, like, that's

00:15:01   not just a simple thing they threw together in a day. And so if you're going to replace

00:15:05   it, you probably need to be aware that you're it's going to be a lot more work than you

00:15:08   think and there's going to be weird edges and problems that you're going to have to

00:15:13   run into. Like I remember this with activity plus plus, where it has this kind of custom

00:15:20   animation where it starts off with the rings. And if you tap it, like the rings unfurl and

00:15:25   turn into the bar graph, which is this kind of cool animation that I thought of. And I

00:15:30   was like, Oh, I really want to build this. And I started to see if I could build this

00:15:33   with UI view animation, because I would far prefer to do it with some kind of built in

00:15:39   mechanism. And in the end, I couldn't, because just it was just too complicated of a thing

00:15:44   to get performance and to get to look right. And so I ended up just building it myself

00:15:49   using like raw core graphics that I, you know, I do the animation of each frame of that animation

00:15:56   and draw it to you just like, I'm just essentially just drawing that to a bit a bitmap and displaying

00:16:02   it each frame, which is great. It looks just how I want it. But it means there's all

00:16:07   kinds of weird issues and performance problems and compatibility things between different

00:16:12   platforms that if I was just using UI view, animation just wouldn't happen. And so for

00:16:19   me, the trade off was worth it. Like I couldn't do it the other way. But I kind of wish that

00:16:23   I was able to use this do so do it the other way. And I think that's something when I

00:16:26   think of these new technologies that Apple puts out like, there's this, I definitely

00:16:30   always have that tugging sense of Oh, man, I wish I could just use whatever it is, I

00:16:34   wish I could just use auto layout, I wish I could just use size classes. But then as

00:16:39   soon as I hit that edge, I have such this tension of just saying like, Oh, I'll throw

00:16:43   my hands up and walk away, which is perhaps a bit childish.

00:16:45   Well, but you know, it's you have to always be defensive of your time, like when you're

00:16:49   when you're trying out something new, or when you're thinking about rewriting a system

00:16:52   component for your own use, like is very easy to fall into a time hole here, and just burn

00:16:58   tons of time doing something that actually isn't productive. Part of the the judgment

00:17:02   of when to do that and when not to just comes with doing it wrong for a number of years

00:17:05   and eventually gaining that wisdom. And part of it is kind of just luck. You know, a lot

00:17:09   of times you can't really tell what's going to be good, you see your time upfront. But

00:17:12   you know, that's the risk you take with new stuff.

00:17:14   Our sponsor this week is Braintree go to Braintree payments.com slash radar. By next year, maybe

00:17:21   even next week, there could be a whole new way to pay for things. Maybe it will be the

00:17:25   next Bitcoin or the next Apple pay, or maybe even both. Fortunately, Braintree is full

00:17:30   stack payment platform is easily adaptable to whatever the future holds. So you can adapt

00:17:36   easily to if you use Braintree in your apps, you can accept everything from pounds to PayPal

00:17:40   to whatever the next big innovation is from any device with just one integration. And

00:17:45   when that new payment method comes out, all you have to do is update a few lines of code.

00:17:49   No late nights, no complicated recoding, no stress about staying ahead of the curve. Braintree

00:17:54   is here to help you find out more at Braintree payments.com slash radar. That's Braintree

00:18:00   payments.com slash radar. Thank you very much to Braintree for sponsoring our show.

00:18:05   One of the things that I was thinking about with this topic, though, is it's something

00:18:09   that I wrote that I you run into if you are behind the times, like I'm very often behind

00:18:15   the way you're like Apple has this new technology, this new approach that they're recommending,

00:18:19   and I'm late in adopting it. The thing that I always noticed too, is that you'll start

00:18:23   to run into that can be really annoying is suddenly all the documentation, all the example

00:18:28   code, all the things that you see on Stack Overflow suddenly don't work for you anymore.

00:18:35   You have to not only not only have you built your own approach, like you even if it's not

00:18:40   like you're just going down the road of like doing something custom, like if you just have

00:18:43   old code, then suddenly you have this new thing that Apple has put out, they're pushing,

00:18:47   and that's where all their focus is going. Suddenly, that's where all the documentation

00:18:51   is written for and the example code they publish will use that new thing. There's not a lot

00:18:56   of great examples and it becomes harder and harder. The biggest example is probably Swift.

00:19:00   I remember there was this transition period where all of a sudden, all the answers on

00:19:05   Stack Overflow for questions I had about the new technologies, where all the example code

00:19:12   was just written in Swift or in people's little snippets. That can become really awkward

00:19:18   and is probably a good reason to try and adopt some of these things with some urgency, just

00:19:24   to not be supposed to fall behind to a degree that you just can't work out what to do.

00:19:28   Or perhaps moreover, you're wasting time. I remember sitting there wasting time trying

00:19:33   to translate the Swift code into Objective-C and then trying to work out how to then take

00:19:40   that concept and apply it into my own app. But I have to do this level of indirection,

00:19:44   whereas if my app was in Swift, I could be like, "Oh, I see what they're doing there.

00:19:48   I can build it for myself now." That's something that I think takes a lot of experience

00:19:53   to realize that you're not just running into technical issues. You're running into

00:19:58   educational and learning issues as well.

00:20:01   - Oh yeah, but that's just par for the course as things move on and new things come in.

00:20:06   Part of the cost of sticking with old stuff is that everyone else moves on, it seems.

00:20:13   That isn't everyone, that's how it seems when you're searching for help or documentation

00:20:17   or looking for where Apple's attention is going. Once the new thing comes out, all

00:20:21   those people move on to it. If you are lagging behind or you're sticking with the old thing,

00:20:25   that's just part of the cost of doing business.

00:20:28   - Oh sure, but it's a weird feeling when you're... In some ways, I love that I have

00:20:35   apps on the App Store that have existed for years. It's a very classic issue in software

00:20:42   engineering of dealing with legacy code, that you have things that work that you go back

00:20:48   to.

00:20:49   It's a crazy feeling when you go back and look at code and run blame in Git. You see

00:20:54   this code was written back in 2009 or 2010, and you're like, "What was I doing? Why

00:21:00   did I have this strange exception?"

00:21:04   So often, you run into this situation where you were coding around an iOS bug in iOS 5

00:21:12   that you no longer need to code around. At some point, you have this weird cycle where

00:21:17   you're coding around a bug that then gets resolved, and then your code, your fix starts

00:21:22   to actually be the bug and cause the problem because you're doing stuff that is counter

00:21:28   to what the modern approach is.

00:21:29   - That's probably why it's so hard to be a UIKit engineer.

00:21:33   - Yeah. I definitely don't envy that team where they do this really cool, amazing work,

00:21:41   but the number of having it work across all the different devices and all the different

00:21:45   things and having an iOS...

00:21:47   The other thing that's kind of crazy is the way they approach with binary compatibility.

00:21:52   You can still run an iOS 4 app on iOS 10. It'll probably be a little bit broken and

00:21:59   janky, but they do a lot of work to keep things forward, which is perhaps another...

00:22:04   Like I was saying earlier, but another reason why being... I keep telling myself to be less

00:22:10   of a curmudgeon about the new stuff because I'm probably wasting a lot of time that...

00:22:16   Apple is paying engineers to do this work, and then I'm just walking past them and saying,

00:22:20   "No, no, I'll do it myself. I'll take care of this myself," where that's probably an

00:22:25   inefficient use of my time.

00:22:27   - Yeah. All right, so let me give a few examples of some of the more recent things that I've

00:22:32   been working with in the last few weeks doing Overcast 3.0. In the last few versions, I've

00:22:36   made extensive use of KVO, Key Value Observing, and this has been helped tremendously by the

00:22:41   Facebook, the FBKVO controller. It is a fantastic open source component. I highly recommend

00:22:47   that anybody using KVO or curious about KVO do it with the FBKVO controller. Don't do

00:22:52   the raw calls because they're full of bug potential, and the Facebook one avoids a lot

00:22:56   of that and is very nice to use.

00:22:58   Generally, this is, in very short terms, a way to have some code notified whenever a

00:23:05   certain value of a different object changes. I think this is what reactive cocoa is all

00:23:12   about mostly. It's basically, and please forgive me if that's wrong, but basically having views

00:23:19   and controls basically update themselves based on values that change, and also similar to

00:23:24   what OS X did with bindings, which never made it to iOS, but honestly, having used them

00:23:29   very briefly, I think they're kind of cool. I know there's potential issues, but they

00:23:32   can be pretty cool.

00:23:35   Where I've been moving basically is moving, rather than having a view controller that

00:23:40   has a stock UI switch and having the view controller manage the state of that UI switch

00:23:45   and be notified when the switch is toggled to go change a value, to assign it the value

00:23:49   when it's loaded or when the value changes, moving all of that into a custom subclass

00:23:54   of UI switch or whatever the control is and having the control manage itself. That takes

00:24:00   tons of code out of the view controllers and makes way more reusable components, way easier

00:24:06   if you're into testing, it's way easier to test these things also, and it really eliminates

00:24:10   tons of potential weirdness and bugs and edge cases. One of the screens that I just made

00:24:16   uses a table view that has a couple of switches and buttons in it. In the old way of me doing

00:24:20   these things, I'd either not monitor for underlying changes, like if a change gets synced over,

00:24:25   that would change one of those switches or buttons, or I'd monitor from the view controller

00:24:29   and if any of those values change, I'd just call table view reload data and just reload

00:24:34   the entire table. And that sucks, if you can avoid doing that, you should. And I don't

00:24:39   need to reload a whole table to change the value of one switch where the underlying data

00:24:43   happened to change during that view's presence on screen. I can just subclass that switch

00:24:48   and just have, rather than having a whole bunch of plain UI switches in the table view,

00:24:53   the one that has the rotation setting, that's now an OC rotation switch. And now I can,

00:24:58   in my table view, when I'm making the cell, I can just say accessory view equals OC rotation

00:25:03   switch. And the switch itself, in its code, it watches the value, it adds itself as a

00:25:10   target and has its own target implementation of like, here's, I'm going to change this

00:25:14   value now, and basically making these components self-contained. And where this really shines,

00:25:21   not only cleaning up your view controllers and code reuse and testability and everything

00:25:24   else, where this really is awesome is another bad word that I didn't use for a long time,

00:25:31   interface builder. I recently started using interface builder to design some of my main

00:25:36   screens, as well as I started using IB designable components. And this is a thing where you

00:25:43   can implement a couple of methods and put a couple annotations on your files, just look

00:25:46   up IB designable, you can basically make custom controls appear correctly in interface builder.

00:25:52   So if you need to draw things custom on a button or style it a certain way or whatever

00:25:58   else, you can do all that and have that show up in interface builder, rather than just

00:26:01   having a big empty white view or like an unstyled button or something like that. Using that,

00:26:07   basically I'm trying to get as much code as possible out of view controllers, because

00:26:11   again, that's kind of like a bad technical debt, bug potential kind of written area.

00:26:15   So just try to make smaller view controllers, and a big thing with that is using interface

00:26:20   builder as much as possible. Interface builder is not like a panacea, but if you do my approach

00:26:25   of having self-contained components that manage themselves, and if you take advantage of things

00:26:30   like IB designable, a lot of things become easier. For instance, portrait and landscape

00:26:35   differences with auto layout. Again, I'm also using auto layout now in interface builder.

00:26:40   That had a really-- - Shocking.

00:26:41   - Yeah, that's like, I thought I'd never do that, but one day I just kind of plowed through

00:26:46   it, I'm like, you know what, I'm gonna learn how to do it, and then I can decide whether

00:26:48   I really need to use it or not. And it turns out, yeah, it's not easy or intuitive, but

00:26:54   neither is anything else about interface builder. And once you figure out, oh, you have to like

00:26:58   right drag from itself to itself, like weird, all the little weird things you have to do

00:27:03   to make interface builder work correctly, most of which are totally undiscoverable,

00:27:09   once you figure those out, auto layout in interface builder really isn't that bad. It's

00:27:13   not easy, but it actually can be more productive in some case, depending on what you're doing.

00:27:19   And so, you know, basic things like if you're gonna have a difference between a portrait

00:27:22   and landscape layout, it makes it so much easier to do that. In fact, my one wish for

00:27:26   it is that I wish that the size classes were more granular, more like CSS. Like I would

00:27:33   love to be able to say, if the width of this view is less than 300 points, then change

00:27:39   this condition, rather than just being like, if this is horizontal or vertical, compact.

00:27:44   You know, the size classes that we have now are very coarse, and I would like things to

00:27:48   be more powerful, more like what CSS does with like media queries and stuff. But other

00:27:53   than that, I have had fantastic luck in my recent redesign and cleanup of this code.

00:28:01   Basically using stuff that's new to me that is not new to anybody else in iOS development.

00:28:06   I'm still not using storyboards, but-- - You're not going crazy.

00:28:10   - No, no, I mean, that would be crazy. But I have found it really, like these things

00:28:15   make so many things easier. Like as I mentioned, like the self-contained buttons and things,

00:28:20   that makes it easier to implement custom themes, 'cause I have all the controls that have a

00:28:24   themable property. I have them monitor for appearance changes in my Appearance Manager

00:28:30   class, and then they can just redraw themselves. Makes it easier to support dynamic text that

00:28:33   way also, 'cause I had a little trick in my app where my appearance did change notification.

00:28:40   I just mapped it to the system's text category size did change notification. So basically

00:28:46   all my handling, like if you, if either you switch into or out of dark mode in Overcast,

00:28:51   or if you go and change system font size, it does the same thing. So all my labels can

00:28:55   redraw themselves, everything can resize itself. I can do this without this kind of technique,

00:29:00   and without these kind of technologies. For many years I have, but it just makes it so

00:29:03   much easier and more reliable to do it this way, and it makes the code a lot more manageable.

00:29:08   And it does make it easier to take advantage of new technologies that Apple introduces

00:29:11   going forward. And so that's, that's I think where most of the value is here. So, you know,

00:29:15   I guess maybe I'll probably have to try Swift pretty soon, but maybe I don't go crazy there

00:29:20   either. We'll see.

00:29:21   - Not yet. Just, you know, one step at a time.

00:29:23   - Yeah.

00:29:24   - We'll slowly, slowly walk down this road.

00:29:26   - Yeah, exactly. All right, well we're out of time this week. Thank you very much everybody

00:29:29   for listening, and we will talk to you next week.

00:29:32   - Bye.

00:29:32   [BLANK_AUDIO]