00:00:43 ◼ ► But I think now we can take a step back and have more of our personal impressions and thoughts from coming out of WDC and what we're excited about and interested in and what our summer might look like, I think.
00:01:14 ◼ ► And the basic idea is it spikes up really high at first as everyone gets all hyped about some new technology or thing, and then it crashes down super low as everyone realizes that that technology cannot solve all the world's problems and isn't as good as we all thought it might be or doesn't pan out the way we thought it would.
00:01:42 ◼ ► And I think WDC... We follow that same cycle throughout the summer. And honestly, maybe the whole year where WDC keynote happens and they show off all this amazing stuff and our hype goes through the roof because we're so excited because they just gave us this great big marketing presentation and we're super excited about all this new stuff exactly the way they want us to be.
00:02:18 ◼ ► And we kind of get, "Oh man, this new API looks cool but it turns out I can't use it." Or it turns out it has these limitations that make it hard for me to make useful work out of or whatever.
00:02:28 ◼ ► And then as the summer goes on we start realizing, "Wait a minute, now with this other stuff we can do this, this, and this and actually here's all these little smaller improvements that we didn't really quite see up front."
00:02:44 ◼ ► And so I think right now we should be kind of coming down from the peak as we're seeing now we should be at the part of, "Okay, these new APIs maybe didn't give us everything we needed or didn't give us everything we wanted."
00:03:06 ◼ ► Yeah, and I just looked up what you were saying. It's the Gartner hype cycle and it starts with a technological trigger, then the peak of inflated expectations, then followed by the trough of disillusionment, followed by the slope of enlightenment leading to the plateau of productivity.
00:04:03 ◼ ► That's fine. That was great. I enjoyed it. I loved riding that peak up. And then yes, followed by the period of actually kind of wading through the announcements, actually getting into the weeds of, "Okay, what does this actually mean? What can I actually do?"
00:04:17 ◼ ► And then I would say there weren't that many massive disappointments for me in terms of the things that were announced. But there definitely was certainly some learning that had to happen.
00:04:35 ◼ ► For the way that I tend to plan, I think about it as, "By September 1st." The way that I do my planning is I want to plan things out such that by September 1st, they're done, with the assumption that sometime in early September, the final beta, the iOS 16 and watchOS 9 and all those will actually be released.
00:04:56 ◼ ► And so if I'm ready on September 1st, that's a good milestone. And then I usually have a week or two of extra slack there that I can use as I need to or to adapt to if there's new announcements that come out there.
00:05:40 ◼ ► I can tell from experience that if you are in Apple's sweet spot in terms of the things that they're going to be promoting, the things that when they have their big iPhone event, which is probably one of the most widely watched keynotes they do in a year,
00:06:01 ◼ ► So for me, obviously, it's like lock screen widgets is huge in terms of it's a big marquee feature. I think it's fun and interesting in terms of I like the way they've gone about doing it.
00:07:37 ◼ ► and have much higher overlap in terms of, you know, you now have complications and they're even built technically the same way, you know, complications in your lock screen, complications on your Apple Watch,
00:08:19 ◼ ► Yeah, I think this WVDC, the more I look at, you know, the actual SDKs and watch the videos and look at some of the APIs, the more I realize that what Apple delivered for me is not necessarily what I would have asked for,
00:08:36 ◼ ► but it's what I probably needed. And in the sense that what they delivered for me is a relatively quiet summer. One that I have a few new things that I want to adopt, which I'll get to in a second,
00:10:37 ◼ ► That's great like that. And that's the kind of thing that will help me migrate towards more modern APIs and take advantage of more modern features as I, you know, bring this huge code base forward and or try to at least.
00:10:49 ◼ ► Meanwhile, all the like big headlining APIs that are there in the new version are mostly things that I either can do very quickly and in like a fairly shallow way or don't need to do at all.
00:12:09 ◼ ► But yes, one row of those, the middle of the lock screen will continue to be open space from a widget's perspective. I think things can slide up there in terms of live activities and notifications and things, but we can't put anything there.
00:12:21 ◼ ► It's only that sort of the very thin one above and then the medium sized row below. Right. And so because that's all it is, frankly, I don't think a lot of people are going to find it useful to have overcast there.
00:13:18 ◼ ► It's not really I don't think it's the kind of app that you really need that for. And then I want to do the share with you API, because that's you know, I have a lot of messages sharing that goes on in my app.
00:14:30 ◼ ► Yeah. And I think that's, I mean, that sounds great. I think it's certainly, especially I think the perspective that you're taking with that sounds very sort of helpful to setting yourself up for success in the future.
00:15:28 ◼ ► Yeah. And like that's a little bit of a pressure. But I think if you're overcast, lock screen widgets were just essentially play this podcast, play this play the next item in this playlist or resume or something.
00:15:48 ◼ ► Like could be interesting. But beyond that, you don't need to go to go too far down that road because there's not that I think there's just much there that that would make sense for your app.
00:16:09 ◼ ► Like, you know, like the way live activities are apparently going to work. If I could do that kind of thing with the smaller widgets on the lock screen, then I could have a few a few other ideas and a few other little values I can provide to my customers.
00:16:38 ◼ ► If your company is growing, onboarding new developers will be a common occurrence, but it's a big undertaking each time. One of the biggest challenges for new hires is get them up to speed with the project their new team is working on.
00:16:56 ◼ ► Developers know knowledge is most useful when it's findable. Centralization is helpful, but given that most companies store knowledge in at least two different locations, how do you make knowledge accessible to those that need it?
00:17:44 ◼ ► Visit about.sourcegraph.com to learn more. That's about.sourcegraph.com to find out why some of the biggest tech companies in the world use Sourcegraph and to see what it can do for yours.
00:18:03 ◼ ► So something too that I think is worth just sort of touching on in terms of strategies for the summer. I think it's sort of talking through a little bit of the way that I think I've found to be a productive way to approach adopting new iOS features.
00:18:42 ◼ ► Starting by taking your app, especially if you have a larger code base, and just opening it up in the new version of Xcode and starting to code, in my experience will often lead to a lot of cumbersome work or things that you end up fighting the tool in a way that is not productive.
00:19:03 ◼ ► And so instead, what I found to be much more helpful is to create a lot of sort of little temporary projects to explore whatever the new API is, to explore and understand how it works, to potentially pull in some of the library code from your app to get a sense of how it might work in your app.
00:19:22 ◼ ► But to be able to explore it in a way that you aren't running into the things that always drive me crazy, where there's weird deprecation warnings or issues with, and sometimes you even have things where your project won't build in the latest version of Xcode until you do this big refactor, or you need to make some changes to the way that your frameworks are linked, or there's some fragile part of your project that gets broken by this change.
00:19:48 ◼ ► Eventually you're going to have to deal with that, though often sometimes those even just go away, that the new Xcode, like beta 3 or 4, is just better in a way that you are setting yourself up for more success and productivity to just sort of wait to do that grand merge, that grand refactor to deal with that.
00:20:07 ◼ ► Instead, if you just set your deployment target to iOS 16 in a brand new project and explore the feature, make sure you understand it really well, make some mistakes that you then won't make with your actual kind of big project, I find that to be very productive.
00:20:21 ◼ ► And that's the approach that I take. I've been doing it so far this year. The only thing I do is, for once, I will open up all my projects in the new version of Xcode and just do a clean build, just to get a sense of if there's some horrible thing down the road that I need to be planning for.
00:20:37 ◼ ► But otherwise, then it's like close those, create a bunch of new projects. So I have a bunch of projects that are just for me to explore how the lock screen widgets work or to explore how the new sleep stages stuff works or trying out some of the new SwiftUI features.
00:20:52 ◼ ► I try and do these in these small little projects. And then probably halfway through the beta cycle is when I'll start really starting to plug those back into the main projects. And that's just something that I've found to be very good for productivity.
00:21:07 ◼ ► I mentioned here in case that is helpful to someone else who is finding themselves frustrated by adopting these new features. And also it makes it easier. I mean, you can obviously manage this with your source control, but I try not to touch my main code branch of the app, such that I'm going to continue probably to need to do bug fix and minor releases over the course of the summer.
00:21:29 ◼ ► And while technically you can have two separate source trees that you're working on, cognitively I find that to be really complicated and confusing. And then you have to manage pulling the code from one to the other.
00:21:53 ◼ ► And so, anyway, just a little pro tip. I don't know how you handle it, Marco. I think you have a slightly different code base situation to what I have in terms of I have multiple apps in all kinds of different stages of code and you just have one. But I don't know if finding strategies like that is helpful as well.
00:22:08 ◼ ► Yeah, I mean, I think I do what is fairly common, which is I create an iOS 16 branch of my app and I will do any things I need to do there where I need to build with the iOS 16 SDK. So that way I can still have the main branch where if I need to issue an update before the app store will accept builds from the new Xcode, which is generally before we have a GM, so most of the summer, then I can do that.
00:22:34 ◼ ► But usually, I've been fortunate that usually I have not needed to issue many updates throughout the summer. So usually, unless there's some major thing that I can work around early in the summer for the new betas, usually I get to just leave it and just do all of the work I'm doing in the beta branch.
00:22:53 ◼ ► The downside of that is that I can't release any of that work until we have a GM. So if there are things that actually affect other customers, things I want to get issued throughout the summer, sometimes I've got to deal with manually backporting only that changeback and everything. So it's not a great system, but that's usually at least what I do.
00:23:13 ◼ ► That being said, I've been really slow in these past years to adopt the latest APIs and things. So oftentimes I will experiment with them throughout the summer, or I'll do that branch and I'll spend a few days making some feature with the new stuff, then quickly realize, "Eh, this isn't that important right now."
00:23:32 ◼ ► And then I'll just go back to working in my main branch and do all the updates there. I have stuff going on this summer where I'm also doing some server improvements and I'm trying to both improve performance of server stuff and also reduce the amount of server stuff that is on my plate directly.
00:23:50 ◼ ► Throwing more stuff to CDNs or S3 or whatever the case may be. I'm going to have to do minor changes to the app and things like the sync protocol to talk to a different server in a different way or something.
00:24:04 ◼ ► So that's the kind of thing that doesn't need any of the new stuff and I want to get that out quickly. Meanwhile, if the new stuff is going to be a little less important for me to get here, then this summer I haven't yet created that branch because my app builds just fine and there's no major deprecations I need to worry about yet.
00:24:35 ◼ ► It's interesting, WBC usually derails everyone's plans and it creates new plans. In cases like you this summer where you have a lot of relevance to the APIs that got changed and improved, that makes sense. But as I mentioned earlier, this summer's releases don't really derail my plans much.
00:25:07 ◼ ► I think I should just keep doing mostly that because I still have a long way to go on that. And as you mentioned earlier, setting myself up more for future success as things change more in the future, that's more important to me right now.
00:25:22 ◼ ► To keep going on the path I was already going on than to jump head first into the betas and start using all these cutting edge features that I really don't have much use for this particular year.
00:25:36 ◼ ► And I think there's definitely some wisdom in that. And I will certainly throw out the note of caution that I have made the mistake many times of adopting, trying to force new features into my app where they didn't really make sense in this sort of vague feeling that, well, if I do that, then magic will happen, I guess.
00:25:56 ◼ ► That lots of people will download it or it'll get featured in the app store or something like that will happen. And very often I've just sort of created legacy support weight that I have to carry around for a while.
00:26:08 ◼ ► Where there's these parts of my app that aren't particularly used, aren't particularly important, but just sort of I did because I kind of wanted to make it happen and wanted to say that, you know, whatever I use, I support focus filters or whatever that is.
00:26:23 ◼ ► Did you make an iMessage app? I made several iMessages. I did a whole lot of work with iMessage that I now sort of, I think it's still in, I don't think I've pulled it out anywhere, but I'm not sure if anyone's ever used it.
00:26:37 ◼ ► But that's definitely something, one of those, an example of just being very thoughtful of just trying to force it into your app. If there's a new feature that you think will make your app demonstrably better, that you, when you think about it, got you excited.
00:26:51 ◼ ► Awesome. Like it is definitely obviously benefit. I can tell from experience, it is beneficial to be ready on day one. If you have an idea or a feature that is like really in the sweet, you know, sort of like that sweet spot of like it's new and interesting and you're taking, you know, finding a cool use for it.
00:27:07 ◼ ► But just trying to force it to happen and especially trying to force it to happen in a compressed timeframe is not necessarily the wisest thing. And I'm saying that as someone who's tried that and done it a lot of times that instead, it's much better to, if it's a feature that isn't that time critical, then you can push it out.
00:27:26 ◼ ► Let it be something that if all, you know, that comes out a bit later in terms of it's more of a technical, like adopting some new SwiftUI feature or something like that. Like don't feel like if it isn't a major user facing feature, adopting it on day one is kind of irrelevant that you don't worry about.
00:27:42 ◼ ► It's like, oh, wow, but now that I can do this cool thing in SwiftUI, I'm going to take advantage and do that by September. It's like you have any amount of time you want for that. It's only really the major like marquee iOS 16 features that are going to get any amount of benefit from being there day one.
00:27:56 ◼ ► And I think for those, it's like make sure you have a compelling case. Make sure that when you saw that feature, you were genuinely excited. Because when I look back at all of my regrets, like I think about things like the iMessage App Store, some of the features that even I sort of like I tried to build some things with
00:28:11 ◼ ► like the with iPad drag and drop in the day, I was trying to invent uses for these features when they came. But it's like I was a solution in search of a problem rather than knowing a problem that was benefit from the solution. And I think being aware of that and being careful can save you a bunch of wasted work that you can instead, you know, put towards actual things.
00:28:32 ◼ ► So in your case, like it sounds great to give there's a few little things that Overcast will benefit from and the rest. It's just like using the summer to be continued to like be reducing the weight that you have to carry going forward and benefiting from you.
00:28:46 ◼ ► It's like dropping support for iOS, older iOS versions, if that's appropriate, like awesome. Doing that just like streamlines your yourself going forward rather than necessarily adding on more weight that you have to carry around, which sometimes I'm guilty of doing.
00:29:00 ◼ ► Exactly. Well, thank you very much for listening, everybody. I hope you have a wonderful, you know, next couple of weeks of summer going through all this stuff. I hope you are in the slope of enlightenment or the plateau of productivity. And if not, I hope you get there soon. Thank you for listening and we'll talk to you in two weeks. Bye.