THE OMNI SHOW

Brent Simmons: You're listening to the Omni Show. Get to know the people and stories behind the Omni Group's award-winning productivity apps for Mac and iOS. Music.

SFX: [MUSIC PLAYS]

Brent Simmons: I'm your host, Brent Simmons. Today we are talking about WWDC 2019, what we thought about it, and what it means for us and our apps. In the studio with me today is Ken Case, Tim Wood and Tim Ekl. Say hello, Ken.

Ken Case: Hello, Ken.

Brent Simmons: Say hello, Tim the Older.

Tim Wood: Hello, Tim the Older.

Brent Simmons: Say hello, Tim the Younger.

Tim Ekl: Hello, Tim the Younger.

Brent Simmons: The problem with two Tims — for a while, I thought it might be great to have “Tim the smart” and “Tim the smarter.” That opened a whole new can of worms nobody wanted to deal with. So, we're going with older and younger. Anyway, the big takeaway for us is, obviously we have to do OmniFocus for Playdate. I just wondered how's that going? Making progress?

Tim Wood: You get one action.

Brent Simmons: You get one action, turn the crank?

Tim Wood: Yep.

Brent Simmons: Get another action. First we have to port Swift to the Playdate I suppose.

Tim Wood: You have to wait a week for your next action.

Brent Simmons: Or get a new action every Monday. That sounds good. Other than that, I guess Apple had some announcements. Ken, let's start with your big takeaways.

Ken Case: Sure. When I came out of the keynote on Monday, there were three big things that stood out in my mind that are mostly not at all related to each other. The first was about the Mac Pro hardware. Of course, the Mac Pro hardware is awesome just because the geek in me would love to play with it. But, whether or not I actually decide that's a reasonable thing for me to get, I think the Mac Pro existing as the top end of our platform now makes a big difference for the customer base that's out there. That we're no longer in a situation where people grow to the limits of the Mac, and then they need to do more, and discover they can't do it on a Mac, so they need to go find some other platform, and now they're shuffling off to a different platform where it's harder for them to be a part of this community or to be our customers.

Ken Case: So, I think that's going to be a big deal in the long run, and it's really nice to see Apple hitting it pretty hard this year.

Brent Simmons: I love that it sets a way outer bound limit for what the Mac's expected to do.

Ken Case: Yeah. It's probably going to be a while before I can justify one and a half terabytes of RAM on any Mac that I have.

Brent Simmons: Sure, right.

Ken Case: Prices might have to come down a little bit. Number two for me was SwiftUI. I think that is going to be a huge change for developers for all of Apple's platforms, and a change for the better, of course.

Brent Simmons: Yeah.

Ken Case: A lot less code, a lot less... There was something that Steve Jobs used to say about NeXTSTEP and OpenStep, about how the lines of code that are the least buggy are the ones that you never have to write. So, if we can reduce the amount of code that's being written to build these apps, we can make our apps more solid, we can extend the feature sets, the expectations of feature sets across more platforms, across more dialogs, and so on in there, it's something Tim pointed out to me is — Tim the Older — as we were talking about this stuff on Wednesday, it's going to be a great move.

Ken Case: But the third thing that I had to think about was, what are we actually going to have to worry about this summer? Neither of those things are things we have to worry about immediately. So, number three was what are the things that we are now expected to do this summer to be good platform citizens? Those mostly center around iOS, and thinking specifically about multi-document support, being able to have say two OmniGraffle diagrams side by side, or in different spaces, sort of side by side with different apps or different things, those pairings.

Brent Simmons: I wasn't sure how that worked. I thought I heard someone say something about multiple instances of the app, or is it really just, as I would expect, you have two different document controllers?

Tim Wood: They've ended up splitting up some of the application lifecycle into a new class called UIWindowScene. So, rather than running actually two copies of your app, you get to manage window scenes, and that will help you persist state about scroll position and things like that, and a bunch of the things about, “ah this got deleted, or renamed,” I think end up going through there. The obvious way we hoped it would end up working, I think is what they ended up with.

Brent Simmons: Good. Another big thing for this summer would be Dark Mode on iOS.

Ken Case: Yeah. I think having done that last year, at least we have some practice. I don't think it will be a huge burden, but it is, as we discovered last year, there are a lot of details to go through to find every control that needs to be tweaked for the new colors.

Brent Simmons: We do have a home-built dark mode for OmniFocus.

Ken Case: For three of our apps.

Brent Simmons: For three of our apps.

Ken Case: Three out of four.

Brent Simmons: Okay, well all right.

Ken Case: Have dark modes in them, OmniGraffle was the outlier.

Brent Simmons: Okay.

Ken Case: So, that will make it a little bit easier because at least those things are things where we can take our home-built theming stuff and just swap in the system theming stuff. “Swap in” might not be the right word, but at least we'll have a list of things to go find.

Brent Simmons: Is it likely the case that we'll do what kind of we did on the Mac where you can choose between following the system, or specifically I always want this app light or dark, or is that even possible?

Ken Case: I think it's likely we would want to do that, just like we wanted to do it on the Mac. I don't see a reason that it would not be possible given… but I have not looked into it in much depth either.

Tim Ekl: I looked a little bit. This was actually one of the sessions I came away from the most excited, after this WWDC because, they go through the feature set, and then they start talking about the API that we have available as developers to pick up this feature. I just remember thinking, "Wow! They really thought about every different possible thing you could ever want to do with Dark Mode on iOS, and they provided an API for all of it." So, they cascade the information through trait collections, which is the smart thing to do. So, all of your views and view controllers have a notion of whether they're in a dark or a light mode.

Tim Ekl: But then, they also gave us hooks to say, “Well in the absence of a view, if I just want to know in the abstract what color is this system color in light mode or in Dark Mode?” We can resolve those actual values as RGB. Then, we can also get access to a couple of helpers to do even custom view drawing if we don't want to use the system colors. We can say, "Okay well, run this batch of code as though it were in light mode, or as though it were in Dark Mode." That helps us with some of our even more custom controls. So, I think we've got a ton of flexibility there, and it really just comes down to how we decide we want to do it.

Brent Simmons: Awesome, cool. Now we have another operating system, iPadOS. Omni's famously just right on top of the iPad since the iPad was announced. Is there any other iPadOS stuff that—

Ken Case: I would say we already have iPadOS apps out there right now.

Brent Simmons: Okay.

Ken Case: I think… well, obviously things like the multitasking, the multi-window support are things that Apple can focus on a bit more. From a technical point of view, I don't know that it matters too much to us right now, the SDK's the same. We already had to distinguish between are we on an iPad, are we on an iPhone, in our code. There were capabilities on one that were not on the other, like being able to drag and drop between apps, or multi-window mode.

Brent Simmons: I think another iOS change was, and I don't have all the details, but now we have contextual menus, where before you might have Peek and Pop. They're features I didn't actually use, so I don't know.

Tim Ekl: Yeah, the 3D Touch gestures, right? I think the contextual menus look like what the 3D Touch, the Peek and the Pop actions would bring up for you, or could bring up for you on devices that were enabled for them. But, they're hooked up to a long press now. So, if you've got say an iPad running the iOS 13 Beta, or iPadOS 13 Beta and you're in Safari, and you hold down on a link, you'll see a list of actions pop up next to that link that says open in new tab, open in new window, all the things that you would expect out of a contextual menu. But, you didn't have to press really hard on your screen to get it.

Tim Ekl: The other cool thing is that it'll even render a preview of what the tab is going to look like when you click through to it, when you follow that link. So, we've got that same kind of previewing ability, and ability to provide a few actions at the point of interaction in iPadOS 13.

Ken Case: That's going to make it integrate a lot better with drag and drop. For example in OmniGraffle right now, we have to deal with, well, is this long touch on here supposed to start a lift? Well, it has to, because we don't actually have any choice about the lift gesture, we just enable it or not. But, maybe that's not what the user had in mind, they really wanted to just interact with that shape and hit the contextual menu, and now the UI for both is a lot more compatible, so you're not left in this weird thing.

Brent Simmons: For us, Catalyst doesn't really bring us anything because we've got the apps on both platforms anyway.

Ken Case: Yeah, not really. In fact I was thinking, well, maybe it could benefit us for our internal tools, but of course all our internal tools are written for the Mac first. So, if we had Catalyst going the other direction, that would be useful.

Brent Simmons: Oh sure, right.

Tim Ekl: App kit for iPadOS.

Ken Case: Right. But SwiftUI, gets us in that direction. For the internal tools, we don't have to worry about operating system minimum requirements quite so much.

Brent Simmons: Sure. We do these days, it seems, tend to stay fairly close to the current operating system. Current minus one sometimes, or even current. But, even that means that SwiftUI is going to be a while before we can ship stuff using that.

Ken Case: Yeah. I think it really depends on a particular operating system release and a particular app release. If the app releases we are doing for this fall are all about adopting the new operating system and its features, providing things like multi-document support and so on, that's not something somebody on the older operating system needs anyway. So in that case, is there any reason to try to keep that compatibility with the older operating system? Maybe not, in which case, we could go ahead and start using SwiftUI today for that particular release. So, it kind of depends on, again, what we're doing, and what the operating system brings to the table, and whether it will make sense to our customers that we decided to require this thing. It wasn't just an arbitrary choice, it had to do with what we're providing.

Brent Simmons: Besides SwiftUI, there are a number of advances in Swift. One that I really liked was the new table diffing. Tim the Elder, is this a thing you paid attention to, thought about?

Tim Wood: Yeah, it's super exciting for a couple of our apps. OmniFocus for iOS has a very similar mechanism built in that is used to notice changes if you sync new actions, create new actions, whatever, and do the appropriate animations to keep your interface up to date. But, it's a whole bunch of code, and I don't think we've got all of it exactly right. So, there are rare cases where it goes off the rails, and this is something that is much better for Apple to handle for us.

Tim Wood: Similarly, Outliner for iOS has a whole bunch of similar diffing code —

Ken Case: That's where that code started, in fact.

Tim Wood: …which I'm super excited to get to delete all that code. I love deleting code.

Brent Simmons: The best WWDC is the one where afterwards you can delete code, it's as simple as that.

Tim Wood: Yep.

Tim Ekl: I was actually really gratified when I read through that API because the thing we wrote in Focus, the big mental shift was away from row indexes and towards object identifiers, right?

Tim Wood: Right.

Tim Ekl: Instead of saying this thing goes at row 10, you can say this thing is task number whatever, and then track that task through different sections and all that kind of stuff. Then, when Apple's API came out, that was exactly how they chose to do it too. So, it'll be a bit of an easier transition for us, I hope.

Brent Simmons: Was this actually a Swift thing or a Foundation thing?

Tim Wood: The base diffing I think got introduced in Swift 5.0.

Tim Ekl: I think so.

Tim Wood: Is that right?

Tim Ekl: Mm-hmm (affirmative).

Tim Wood: There was a proposal for ordered collection diffing, which I presume this is all based off that one abstraction.

Tim Ekl: That's down at least in Foundation, if not lower, so that it gets its open source re-implementation for Linux and all that jazz. But then, the UI level conveniences exist for UI and NSTableView and CollectionView, so that as app developers, we can more easily say, “here's what my table should look like before a change, and here's what my table should look like after a change,” because we know those things right up top at the UI layer, and then just ask the lower levels to do all the hard work of computing the diff for us.

Brent Simmons: That's such a smart thing for Apple to do, because everyone struggles with this problem.

Tim Ekl: Yeah.

Brent Simmons: And make it so that presumably every app with this issue could just be awesome. I mean, that's improvement to the platform.

Tim Wood: That sorta gets back to what Ken and I have been talking about with SwiftUI making lots of different corners of your app much nicer. The easiest way to deal with table view diffing is just don't do it, preload data and then you get an interface that is not very nice. But this way, it'll be super easy to do, and every view that supports diffing, people will opt into it and it'll be great.

Brent Simmons: Another very interesting Swift advancement was property wrappers. I'm still struggling to get my head around how those actually work, but it sounds like the kind of thing we might use maybe in OmniDataObjects, for instance.

Tim Wood: That's certainly a place where I think it would make sense. Property wrappers allow you to get rid of the boilerplate code where you have to get it right every time you implement it. It's just an annoyance to have to do that, and if you mess up, then you get bugs.

Tim Ekl: Even something as simple as a lazy property or a derived property, every time I introduce one of those, I'm always nervous about, well, am I invalidating or clearing this value at the right points, or it gets recomputed at all the right times? To have that, at least some of that abstraction taken off my mind would be nice.

Brent Simmons: We also now have the ability to create our own DSLs in Swift by using property wrappers and a few other new features. I wondered if this was the kind of thing that we would find useful.

Tim Wood: I suspect there'll be a place where we'll find to use it.

Brent Simmons: We'll have to because it's so cool.

Ken Case: The whole point of a DSL is that it's useful in a particular place. So, if we find a place where a DSL is going to save us some time or thought, or make the job easier, then we'll use it there and we may never use it anywhere else if it doesn't make sense.

Brent Simmons: Note to listeners who don't know, DSL stands for Domain Specific Language. It's a thing, like a little mini-language designed for a specific problem. But, if they're easy to create, they could be super helpful.

Ken Case: We use a DSL right now in our build system actually to define like here are the projects and dependencies and so on. Right now, that DSL is in Ruby, but one could imagine it being in Swift.

Brent Simmons: Sure. Ruby's famous for people making DSLs from Ruby, I think.

Ken Case: Yeah, although not as much as Forth.

Tim Wood: Going way back.

Brent Simmons: Another cool thing, the Combine framework, which goes hand in hand with Swift DSLs, and SwiftUI in some ways, but, it's a framework that allows you to handle changes that happen overtime, and updating your state. Something like OmniFocus I think actually has something very like that written in Objective-C to update the rows in the main content area.

Tim Ekl: Yeah, that was I think probably right around the release of OmniFocus 2.0, so several years ago now, we had all these rules set up about whether or not things like your project field, or your tag field, or context field then, or your due date and defer date field should be visible in a particular row, based on a ton of different variables, like whether any of those fields had data in them, whether the task as a whole was overdue, whether you were scrolling, whether your mouse was over the row, whether the row was selected. So, not just things about the data you entered, but also transient things about the state of the app.

Brent Simmons: Right.

Tim Ekl: So, we wound up hooking up this whole homegrown set of classes that I think fall under the umbrella term “reactive boolean.” But, this was pre-Swift, or at least in the Swift one dot something era. So, it's all in Objective-C, it's all doing string parsing at build time to figure out what variables it needs to be looking at, and using KVO to watch for changes for some of those. It was a really impressive technical feat, and all I want to do is replace it with Combine.

Brent Simmons: Perhaps you'll get the chance sometime.

Tim Ekl: Yeah. I think it looks like one of the first steps might be to have some of the lower level things that we need to watch for, the places where those changes are occurring. Either the views on screen or our model set up, so that they know how to publish changes to Combine framework first, and then we can start taking those events and tying them together using some of the new stuff.

Brent Simmons: So, are we going to say goodbye to NSNotificationCenter forever?

Tim Ekl: Somehow I don't think so. I think NSNotificationCenter will always have a place in my heart.

Brent Simmons: Yeah.

Tim Wood: But we might say bye to KVO.

Tim Ekl: That's reasonable.

Brent Simmons: Me and KVO, we've had problems.

Tim Wood: I've heard you're not a fan.

Brent Simmons: No. Well I'm not, because of all the crashes. I'm like, "Oh well, it's so easy to wire this up." A month later, "Oh, where's this crash coming from? Well, because we used KVO.” Anyway. One of the interesting things is in the watchOS. Now we have standalone watch apps. Apparently, SwiftUI comes from watch initially, it's something I heard, I don't know if that's true, but, the watch even has an app store. I'm not sure it makes sense for us to do a standalone watch app.

Ken Case: Well, in terms of the business side of what people want to buy, I don't know that it would make sense to do a standalone watch app that would split it up. In fact in general, the trend that our apps have been taking have been in the exact opposite direction, where we started out with separate iPhone and iPad apps, and then we unified them into one universal app that also included the watch app. Now we have a subscription that covers all three of those platforms plus OmniFocus for Mac, and OmniFocus for the Web. Customers I think generally prefer the simplicity of just buying the app once and doing it that way.

Ken Case: But, of course we want to offer the option for people who prefer the à la carte experience to buy things separately. But, I'm not sure anybody has expressed any interest in having the à la carte experience with just the watch app. Maybe some other app some day, somewhere down the road.

Brent Simmons: Would it even be technically possible to get our entire syncing engine on the watch? It seems like—

Ken Case: I think so now, not in that first watch.

Brent Simmons: Yeah.

Tim Ekl: Definitely not on that first watch. I will admit to having the Wikipedia tab with different generations of watch hardware, like specifications, open during that part of the keynote, seeing just how much RAM do we really have? It might be a stretch, but maybe now.

Ken Case: But it's not a huge stretch from the problem that we had just getting it onto the iPhone originally, when we did syncing there.

Tim Ekl: That's true, yeah sure. The watch now and the phone then are not so different.

Brent Simmons: Yeah. I do still retain some weird nostalgia for the early iPhone days, because after years of working on a Mac, and suddenly having this super constrained device, where I had to worry if I was using as much as 3 MB of RAM, and it was slow, that was kind of fun, it was fun discipline.

Ken Case: It was the definition of garbage collection in Objective-C.

Brent Simmons: Yeah, that's right. One thing I personally liked, and I think the whole company probably really likes is Apple's continued emphasis on privacy. One of those things was changes in Core Location privacy, which you had described earlier. What were those?

Tim Ekl: So, apps have always been able to, and can still request access to your location. They get the location of where the phone is right now. They can request it in two ways, either the app wants to know while you're using the app, where it is, or the app wants to know always. The latter option can be useful for if you need to setup a geo-fence or other notifications that might need to come in based on location when the app isn't actually running. But in order to try to cut down on the abuse of that feature, where an app requests access to your location always when maybe it doesn't really need it, in iOS and iPadOS 13, now the system, even if the app requests access to your location all the time, the system will only present to the user the option to grant it once, just this one time, or while you're using the app.

Brent Simmons: Okay.

Tim Ekl: Then it goes into this temporary state where the OS remembers, the app wanted location always, and the user said, "While you're using the app, that's fine," then it's on the app to request a couple of more times. If they get that same affirmative response from the user consistently, then eventually they'll get prompted, "You've been using this app a bunch, it's requested your location, you've said yes every time, do you really want to grant it access all the time?" This can be good for people who are getting used to a new app, or maybe trying out location services in an app where they're not quite sure how it works yet. It prevents the OS leaking too much information about the user's location to apps that might not be playing by the rules.

Brent Simmons: That's cool. There is the risk of now I'm being prompted for things too often. That's always a balance, I suppose. But, I do very much like that Apple continues to try to protect us. I mean, as a user, I want to be protected. As a developer, I'm like, "Get out of my way, I want to do these things. I'm not bad, I'm not going to do something terrible," but…

Tim Ekl: I have no idea how it's going to be to try to debug this kind of stuff, where we're not sure what state the app is in at any given time. But from the user's standpoint, it feels like they've taken this potential privacy problem and changed it into a problem of, I hate to use the word “just,” but it seems like it's just implementation now. It's just figuring out how often is too often to prompt, and when the transition actually happens, rather than being a real problem of leaking info about your users.

Brent Simmons: I assume Apple gets some kind of analytics to do that.

Tim Ekl: I would have to assume so.

Brent Simmons: And can tune that kind of thing. Another big privacy, maybe the biggest one was the new sign in with Apple stuff. Now, that doesn't directly affect us I don't think.

Ken Case: Well, it could. It would have been a lot more useful if we'd had it a year ago.

Brent Simmons: Well, yeah.

Ken Case: Right now, as part of adding support to our apps for customers being able to subscribe to them, we needed a way to track who has a subscription, and that means people who have accounts. We set up a whole system on our end for verifying those accounts, keeping track of their email addresses. Of course we know from experience that some of those accounts will go stale over time, where people don't update them. They're not going to think to go through every account that they have on every system to update the email address when they switch something. So then, we'll have to deal with people wanting password reset requests, or all sorts of things.

Ken Case: If we had had this system in the first place a year ago, when we were designing subscriptions, maybe we could have just offloaded all of that problem to Apple, and let them say, "Here's a valid person, here's how you can contact them with a permanent forwarding address," and Apple will relay the mail messages for us. Then, our side of the problem would have been simpler. The user experience would have been simpler because they wouldn't have had to go through and, say, wait for the email message to show up and then enter the code that we sent them, saying yes, we actually have an email message now. Tim the Younger had to do that work and not me.

Tim Ekl: It wasn't that bad.

Ken Case: It's done now.

Tim Ekl: Maybe I have those rose tinted glasses for having done that.

Ken Case: It's done now on iOS, we're about to ship it onto Mac maybe by the time this comes out.

Brent Simmons: To close out, I'm just going to go around and ask, what's your coolest thing that's maybe not a huge thing that we haven't talked about? Got one, Tim the Elder?

Tim Wood: Sure. I was just watching the video for PencilKit, and being able to adopt all the same drawing tools that Notes has is going to be super exciting. One of the interesting details there is that the data that they store can be loaded on a Mac and rendered there. Obviously you don't have a pencil there, but it's super nice to be able to do that for displaying a drawing that you did on iOS, on your Mac.

Brent Simmons: Cool. Tim the Younger, you got one?

Tim Ekl: Well, I always get really into the weeds with what's new in Foundation, and Swift language, and that kind of stuff.

Brent Simmons: Oh sure, yeah.

Tim Ekl: So, I think it was in one part of the Combine session where they were talking about other non-Combine related changes to Foundation. They did some really, really cool stuff with NSRelativeDateTimeFormatter is available now.

Tim Wood: Oh yeah, I saw that.

Tim Ekl: So you can take something and not just say here's how June 11th should look to a particular person in a locale, but you can also now finally figure out, "Hey, that's tomorrow, we should say ‘tomorrow’ on screen instead of June 11th 2019."

Brent Simmons: That extended even to lists.

Tim Ekl: Yeah.

Brent Simmons: Like if you need a list of dates, how is that properly rendered?

Tim Ekl: Yeah, there's a list formatter that gets the right conjunctions, figures out whether you want a trailing comma, whether you're using an Oxford comma or not. They did some neat stuff with NSOperationQueue as well for solving problems, like if you're running many tasks in parallel but you want them all to wrap up, to do one thing, and then to start up in parallel again. They added some special API for that. It's just little tweaks throughout Foundation that make that kind of usability for us developers a whole lot nicer.

Brent Simmons: Yeah. Do we use NSOperationQueue much?

Tim Ekl: Not a ton. I'd like to a little more, but there are certainly places where it's come in handy for us. I think, like in OmniFocus, if you're dealing with your data encryption for example, we wanted to be really sure that we got the threading there correct, because it doesn't do to try to decrypt data before we've downloaded it, for example. So, a lot of that is built on Operation Queues.

Brent Simmons: Got something Ken?

Ken Case: I've got two things now. Do you want hardwares first or software first?

Brent Simmons: Let's do hardware first.

Ken Case: Hardware first, I think Afterburner. The Programmable FPGA stuff going into... Programmable hardware in a Mac I think opens some interesting possibilities down the road, it could be a lot of fun to play with, not that I have any applications in mind right this moment.

Brent Simmons: Sure, no.

Ken Case: But the stuff that they were showing is just the beginning of what you can do with something like that. So yeah, the geek in me is really geeking about that.

Ken Case: On the software front, I would say the shortcuts UI stuff, where now apps can provide their own UI for shortcuts with space for parameters and build up all that stuff instead of having to... in the past, when we added a field to OmniFocus for example to say when you add this Taskpaper template stuff, you can put it in a particular folder or a particular project. That was a new parameter that we added: What's the target of these tasks that you're sending to OmniFocus? Well now, we can add that ourselves, and they can be tied to which version of the app you have installed, and so on, instead of being something where we file a bug with Apple and wait for them to implement it, not that they took very long implementing that specific case, they were very responsive, but that I am sure does not scale very well to millions of the apps out there.

Brent Simmons: Right, yeah, that's very cool. Automation on iOS continues to get better and better.

Ken Case: Yeah.

Brent Simmons: That's an interesting thing.

Ken Case: Hopefully we will see that come into other platforms now we have things like SwiftUI.

Brent Simmons: Cool. Well, I think we'll close with that, unless somebody's got something else. No? All right. Thanks Ken. How can people find you on the web?

Ken Case: You can find me, of course our website is omnigroup.com. The place to reach me personally would be on Twitter at @kcase.

Brent Simmons: Thanks Tim the Elder, how can people find you on the web?

Tim Wood: I am @tjw on Twitter.

Brent Simmons: TJW, one of those short three letter ones, nice.

Tim Wood: You've got to get in early.

Brent Simmons: Yeah. Thanks Tim the Younger, how can people find you on the web?

Tim Ekl: You can find me on Twitter @timothyekl or my personal domain where I blog at timekl.com.

Brent Simmons: Cool. I'd also like to thank our intrepid producer Mark Boszko. Say hello, Mark.

Mark Boszko: Hello Mark.

Brent Simmons: And especially, I want to thank you for listening, thank you. Music.

SFX: [MUSIC PLAYS]