Under the Radar

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]