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

00:00:09 ◼   ► started. So today I thought it would be a fun topic for us to talk about finishing up

00:00:17 ◼   ► a project, or doing that last 1% that definitely doesn't take 1% of the time you spend on a

00:00:24 ◼   ► project. Like, the energy and the effort and the willpower it takes to just get over that

00:00:30 ◼   ► last little bit is definitely massively disproportionate for launching a software product. And you

00:00:37 ◼   ► get better at it the more you do it, which I think is something hopefully that I can

00:00:40 ◼   ► say that is -- I found in my own experience and is hopefully encouraging, if you're coming

00:00:45 ◼   ► to development fairly -- if you're fairly new to this, that it's totally normal for

00:00:52 ◼   ► that last little bit of a project, where it's almost done, but isn't quite done, isn't quite

00:00:57 ◼   ► released, to feel like it takes forever. And part of it, I think, in a weird way is the

00:01:03 ◼   ► term "software release" is very aptly named, because software isn't so much finished as

00:01:08 ◼   ► it is slowly tugged out of our hand, and eventually we just release our grip and it flies out

00:01:14 ◼   ► into the world. It is never this thing where -- at least I've never had the experience

00:01:19 ◼   ► where I feel like I have created this perfectly formed thing that I am now presenting out

00:01:26 ◼   ► into the world. It's like, at some point, you just have to say, "This is good enough.

00:01:30 ◼   ► I'm going to put this out, and I will fix all the bugs or the issues or the problems

00:01:35 ◼   ► later." And I think we've talked many times in episodes previous about the importance

00:01:39 ◼   ► of getting something out into the world, because you can get feedback, you can validate the

00:01:44 ◼   ► idea, make sure that you're actually building something people want, or not missing whole

00:01:49 ◼   ► aspects of the problem domain that you're trying to solve that you're just unaware of

00:01:54 ◼   ► because you're stuck in your own little world. But more importantly, I think what I was going

00:01:58 ◼   ► to be interested in to focus on for today is some of the little aspects of doing that,

00:02:02 ◼   ► of the things that you have to do in that last 1%. And the first thing that I think

00:02:08 ◼   ► is worth talking about is deadlines. This is especially complicated, I think, being

00:02:14 ◼   ► -- if you're doing this project by yourself or just one or two other people, and this

00:02:19 ◼   ► isn't something where you have an externally imposed deadline. It's not that you're doing

00:02:24 ◼   ► consulting for a client and the client has said, "By this date, you need to have done

00:02:29 ◼   ► this or you won't get paid or there'll be some kind of penalty." If there's an external

00:02:34 ◼   ► deadline, that sort of takes care of itself. But if you don't have one of those -- and

00:02:40 ◼   ► what I've found for myself is that if I don't have some kind of deadline in mind, and maybe

00:02:47 ◼   ► it's slightly squishy, but it shouldn't be so squishy that it's not a deadline. It still

00:02:51 ◼   ► should have some weight behind it. I find it very hard to really get there because there's

00:02:57 ◼   ► something -- I think it's Parkinson's Law. It's one of those management laws where it's

00:03:03 ◼   ► like work will expand to fill the time allotted to it, basically. So if you give yourself

00:03:09 ◼   ► another month, you will find a month's worth of work to fill that with. And if you give

00:03:12 ◼   ► yourself another two months, it'll fill indefinitely. And if you don't have a deadline, you will

00:03:16 ◼   ► just keep filling with work forever. It's this never-ending, inflating balloon. And

00:03:21 ◼   ► so you have to at some point put a line on it and say, "I'm going to get it done by here."

00:03:27 ◼   ► Something that I found really helpful with this is to start to try and talk to other

00:03:35 ◼   ► outside people about your launch. So whether this be someone in the press, with friends,

00:03:40 ◼   ► whoever it is, and start talking around a date. I have December 12th as the date that

00:03:45 ◼   ► I'm going to launch Workouts++ 2.0. That's something that I've started to socialize and

00:03:51 ◼   ► talk about to different people. And now that that's a thing in the world, it changes it

00:03:57 ◼   ► from this vague amorphous thing to something that I have this personal ownership of making

00:04:02 ◼   ► happen. And if I didn't have that, I feel like I would just keep working on this app

00:04:06 ◼   ► forever, which is not good for anybody. It's far better to draw a line, cut what I need

00:04:12 ◼   ► to cut, narrow it down so that I can get it out there, and then start iterating on the

00:04:17 ◼   ► version that's out in the world rather than just getting stuck without a deadline, without

00:04:22 ◼   ► any sense of end in mind.

00:04:24 ◼   ► - Yeah, I mean, I have found that most of my releases have basically been, I've basically

00:04:32 ◼   ► been working all month or year or six months or whatever, working for a very long span

00:04:39 ◼   ► on a kind of unending list of features that like, everything is like, oh, it would be

00:04:47 ◼   ► nice if I had time, I can do this. And very few of the features are actually required.

00:04:53 ◼   ► And so the amount of time that I'm working on these releases is pretty open-ended. And

00:04:59 ◼   ► without any kind of external deadline imposing on me, like the release of a new version of

00:05:03 ◼   ► iOS or a new Apple hardware or something like that, they would just go on forever. And usually

00:05:08 ◼   ► when I do finally release something, it is planned almost no time in advance, and one

00:05:15 ◼   ► day I just kind of, I'm like, you know what, I'm just, I'm done. I just want this to be

00:05:19 ◼   ► out there. I'm tired of it not being released, so I'm just going to release it like tomorrow

00:05:24 ◼   ► or something like that. Just a kind of arbitrary decision of, okay, I just need to get this

00:05:29 ◼   ► out there. Enough is enough. But a lot of times that takes me a long time to get to.

00:05:35 ◼   ► - Do you think that kind of slightly arbitrariness to it works in your favor, or is it problematic?

00:05:44 ◼   ► It seems like it could go both ways, that in some ways it's helpful because you're not

00:05:49 ◼   ► creating this sort of, any internal stress about something. You're just kind of working,

00:05:53 ◼   ► working, and at some point you're just like, you know, this is good, and just ship it.

00:05:58 ◼   ► Is that, do you find that to be helpful, or is that problematic?

00:06:02 ◼   ► - It's one of the many ways that I think and work that are probably not ideal, but that

00:06:09 ◼   ► also I probably will never change about myself. So I just have to basically take the good

00:06:15 ◼   ► and the bad that comes with it. I think that there's a lot of things that are bad about

00:06:20 ◼   ► this kind of capricious or rash decision making. Sometimes it's not a good time to release

00:06:25 ◼   ► that thing, it turns out, which I find out later. Or sometimes it would have benefited

00:06:29 ◼   ► from a stronger and more considered marketing push maybe. But the reality is that I also

00:06:37 ◼   ► then am rarely in the position where I have to wait forever. I'm rarely in the position

00:06:43 ◼   ► of designing myself into such a corner or having such a huge list of what needs to be

00:06:49 ◼   ► done before the release that it never comes out. Like, no one's ever waiting years for

00:06:55 ◼   ► an overcast update. The way I work ensures that something will get released on a fairly

00:07:02 ◼   ► regular interval, and I will never know until it's actually released what features will

00:07:07 ◼   ► end up making it before that deadline comes or not. The self-imposed arbitrary deadline

00:07:12 ◼   ► that was declared two days ago.

00:07:14 ◼   ► >>

00:07:34 ◼   ► When I start to work on anything big, the overall quality of the app drops somewhat

00:07:45 ◼   ► precipitously, and then it'll gradually work its way back up to good again over the

00:07:52 ◼   ► course of time. For me, I find it's important to have something in mind that I know how

00:07:59 ◼   ► much time do I have to keep breaking things before I have to switch things around to just

00:08:06 ◼   ► fixing things. And that might just be the way that I develop. That I tend to take everything

00:08:14 ◼   ► apart and then put it back together again rather than fixing things in a way that is

00:08:21 ◼   ► probably a bit more elegant or straightforward, where if something isn't done, it could

00:08:26 ◼   ► just be left out. I know you hear about this a lot with web development type of things,

00:08:34 ◼   ► where everything that's in your master branch is always ready for production, and nothing

00:08:39 ◼   ► that touches that should ever not be ready for that, which is the opposite of what I

00:08:44 ◼   ► do. I just have things go from great, horribly broken, back to great, back to horribly broken

00:08:51 ◼   ► for me. So I need some sense of endpoint that I'm aiming at in order to get things turned

00:08:59 ◼   ► around and fixed. Otherwise, I'd find myself in a lot of trouble if I was like, "You

00:09:03 ◼   ► need to release this in two days." No, I need a week to put it all back together again.

00:09:09 ◼   ► That might just be the way that I work.

00:09:12 ◼   ► Yeah, I do the exact same thing. Basically, when I decide enough is enough, I need to

00:09:21 ◼   ► release this, that just becomes my number one to-do item, is just let's close all

00:09:25 ◼   ► this back up again. Let's fix what's broken. If too much is broken and I can't do that

00:09:29 ◼   ► quickly then okay, I won't release it yet. But usually, the things that I break horribly

00:09:35 ◼   ► are the first things that I fix during a development cycle for release. And then everything after

00:09:42 ◼   ► that is either minor polish items, which are easy to basically knock them all out and clean

00:09:48 ◼   ► it up in one or two days at the end once you decide you're done, or additional features

00:09:52 ◼   ► that aren't really necessary or that are more self-contained so that if I have to

00:09:57 ◼   ► disable an entire feature for release and just ship it later, I can do that fairly easily

00:10:02 ◼   ► with preprocessor macro definitions or commenting out some things or things like that. But that

00:10:09 ◼   ► doesn't usually come to that for me for whatever reason. Usually, whatever I make,

00:10:14 ◼   ► I ship soon afterwards because I've gotten pretty good at the mad rush at the end to

00:10:20 ◼   ► just polish all the rough edges and fix the remaining bugs of what I have and then just

00:10:24 ◼   ► ship what I have. But it's more of a mode switch for me to stop making new stuff at

00:10:33 ◼   ► that point and to just only focus on making what I have releasable.

00:10:38 ◼   ► - Yeah, and I think it sounds like there's a similarity that I have where as I'm developing,

00:10:45 ◼   ► I tend to have a very high level feature list of the things that I'm trying to accomplish

00:10:52 ◼   ► in an update or in a release. And then at a certain point, I switch from that kind of

00:11:00 ◼   ► a to-do list to what I call a punch list, which I think is a term from construction

00:11:07 ◼   ► for when you're finishing up a house. But you switch to this different mode where the

00:11:16 ◼   ► only things that are on your list are things that need to be fixed. You're no longer creating

00:11:22 ◼   ► anything. All you're doing is fixing things that are broken. And so it changes the nature

00:11:29 ◼   ► of it because that list, hopefully anyway, by necessity, will shrink to zero over time.

00:11:37 ◼   ► Whereas your feature list or your idea list or your more creative list can grow indefinitely

00:11:44 ◼   ► and probably should grow indefinitely in some ways. It's great when you can come up with

00:11:50 ◼   ► new ideas for your app, when you can come up with... It's awesome that when you start

00:11:54 ◼   ► using something for a while, then you're like, "Hey, what if it did this? What if it did

00:11:57 ◼   ► that?" Those are awesome. But I have to force myself to start... Right now, I have two lists

00:12:03 ◼   ► in my to-do list manager. I have one for the punch list for Workouts++ 2.0, and then I

00:12:09 ◼   ► have the everything else list. And any idea or feature, anything that I have that's an

00:12:17 ◼   ► idea for Workouts++ at this point, that isn't actively fixing a problem in the app right

00:12:22 ◼   ► now, goes onto the second list and won't be looked at until I get this release out. The

00:12:27 ◼   ► only thing that's on my list now is all these broken items, anything that needs to be dealt

00:12:32 ◼   ► with. And I tend to get into a nice cycle with those where I'll sit down, I'll try and

00:12:39 ◼   ► knock out three or four of those. I'll do either an internal beta or maybe send it out

00:12:47 ◼   ► to a few people, go through the app, see if anything's broken, and repeat. And it tends

00:12:53 ◼   ► to, in a good way, narrow in nicely where... When I first switch over from feature to punch

00:13:01 ◼   ► list, maybe I have 40 items on my punch list. Lots of things are a little broken. And then

00:13:08 ◼   ► I do a cycle through, now there's 20 things. And now there's 10 things. Now there's five

00:13:14 ◼   ► things. Now there's three things. I'm just gonna have to live with those in a ship. That

00:13:19 ◼   ► pattern seems to work pretty well for me. And it's important, I think, more importantly,

00:13:24 ◼   ► rather than how you do that, is having that mindset switch where at the end, you have

00:13:30 ◼   ► to have the discipline to say, "I'm not gonna add any more features at this point." Now

00:13:36 ◼   ► it's just fixing stuff. Because if you don't draw that line at some point, it just expands

00:13:42 ◼   ► forever. But having that mindset switch to, "Is it broken, or is it an enhancement?" And

00:13:48 ◼   ► if it's an enhancement, it goes in the next bucket. And it's important, I think, to have

00:13:52 ◼   ► that other bucket. I would drive myself crazy if I didn't have a place that I knew I was

00:13:57 ◼   ► going to look at that idea in the future, because I want to build it. I want to do that.

00:14:03 ◼   ► But it's like, I need to have a place to say, "You will look at that," in my case, "On December

00:14:09 ◼   ► 13th, you can look at that feature. You can look at that idea and work out if it's a good

00:14:14 ◼   ► idea. But for right now, if it isn't broken, then it's not gonna get fixed." Speaking of

00:14:20 ◼   ► knowing when things are broken, our sponsor this week is Pingdom. You can monitor your

00:14:24 ◼   ► websites and servers. Start today at pingdom.com/relayfm. You will get a 14-day free trial. And when

00:14:31 ◼   ► you enter offer code radar, check out you got 30% off your first invoice. Pingdom is

00:14:36 ◼   ► focused on making the web faster and more reliable for everybody by offering powerful

00:14:40 ◼   ► and easy to use monitoring tools and services. For example, you can monitor the availability

00:14:45 ◼   ► and performance of your server, database, or website by using more than 70 global test

00:14:50 ◼   ► servers that emulate visits to your site, checking its availability as often as once

00:14:53 ◼   ► every minute. Websites are so sophisticated and potentially complicated these days, and

00:14:59 ◼   ► very often include several different dependencies such as contact forms, e-commerce checkouts,

00:15:04 ◼   ► logins, search, so much more. And Pingdom makes it possible to monitor the availability

00:15:08 ◼   ► and performance of all of these key interactions people have with your site. Because stuff

00:15:12 ◼   ► breaks on the internet all the time. Every month, they detect 13 million outages at Pingdom.

00:15:17 ◼   ► That is more than 400,000 outages a day. So whether you have a small site or you're managing

00:15:22 ◼   ► a complete infrastructure, it is very important to monitor its availability and performance.

00:15:27 ◼   ► And Pingdom is great. I have used Pingdom since long before they were a sponsor. I used

00:15:31 ◼   ► them all the way back at Tumblr, and I assumed they set up Instapaper. I set up Pingdom immediately.

00:15:37 ◼   ► Then I went and I set up Overcatch. I set up Pingdom there. It is wonderful. I've used

00:15:42 ◼   ► it all this time because it is great. I love knowing when stuff is slowing down or broken

00:15:48 ◼   ► or down. It is very, very useful to know. Because you want to know before all your customers

00:15:53 ◼   ► or your audience finds out. You want to know that first you can go fix it before too many

00:15:57 ◼   ► people see it. So all you do is give Pingdom a URL to monitor. If you want any kind of

00:16:01 ◼   ► custom conditions or logins, you can do that too, but you don't need to. They take care

00:16:06 ◼   ► of the rest. You are immediately notified whatever means you want. SMS, push notification,

00:16:11 ◼   ► email, and you can fix the error before too many people see it. Check it out today. Pingdom.com/RelayFM

00:16:17 ◼   ► for a 14-day free trial. And use code RADAR at checkout to get 30% off your first invoice.

00:16:23 ◼   ► Thank you to Pingdom for supporting this show and RelayFM.

00:16:26 ◼   ► So as a recording, you just released Forecast, your MP3 encoder, metadata manager, chapter

00:16:36 ◼   ► maker tool to the world finally. And I know this has been a long time coming. I don't

00:16:42 ◼   ► know exactly when you started working on this tool, but it seems like it was forever ago.

00:16:47 ◼   ► And I was curious if you had any thoughts about what got you through that last 1% to

00:16:52 ◼   ► finally actually ship it, put it out in the world, and start that next phase of its lifespan.

00:16:59 ◼   ► I wanted to release Forecast for a while. I had waited in part for the MP3 patents to

00:17:07 ◼   ► expire, the last of which expired this past spring. So I could have released it really

00:17:11 ◼   ► any time after that safely. And I intended to. But then basically throughout the summer

00:17:20 ◼   ► and fall, Overcast was basically on fire. Between iOS 11 and drag and drop and then

00:17:28 ◼   ► the iPhone 10, Overcast has been consuming almost all of my development time. I have

00:17:35 ◼   ► touched Forecast very little in the last year, just because Overcast just was needier than

00:17:41 ◼   ► I expected. And so what finally pushed me to release this, I mean I've been using

00:17:46 ◼   ► this both myself and in a small private beta with some of our friends who are also podcasters

00:17:52 ◼   ► for like two years. And so I knew the functionality of it worked. The app still had a bunch of

00:18:00 ◼   ► rough edges. And it still does, because it's a Mac app and I am terrible at making Mac

00:18:04 ◼   ► apps and I'm very, very new to it. AppKit is very little like UIKit. It's very different.

00:18:13 ◼   ► And there's still a lot of legacy to be aware of, a lot of rough edges, a lot of things

00:18:19 ◼   ► you have to consider, a lot of functionality that simply just doesn't work. And iOS has

00:18:26 ◼   ► a lot of this too, but I know what it is on iOS. I've been there for so long that I

00:18:29 ◼   ► have a lot of experience there. On the Mac, it's all new to me. It's all unfamiliar.

00:18:34 ◼   ► And the amount of available help on the Mac is way smaller. You can't just like do a

00:18:40 ◼   ► web search for some problem you're having and get a thousand Stack Overflow results

00:18:44 ◼   ► about the answers. No, like for Mac problems you're lucky to get one. You might even get,

00:18:50 ◼   ► you might get two, maybe, but you're probably only going to get zero or one answer to what

00:18:54 ◼   ► you're looking for. And it might be on some ancient mailing list that's impossible to

00:18:58 ◼   ► skim or find. So Mac development is very slow going. So part of why I haven't released

00:19:05 ◼   ► it yet is because it wasn't, the app wasn't very pretty or polished and so I was afraid

00:19:13 ◼   ► to release it because I was afraid that people would judge it on these superficial but still

00:19:19 ◼   ► important qualities that I'm just not very good on the Mac yet and I might never be.

00:19:24 ◼   ► So that was part of it. But our conversation last week was a pretty big motivator for me

00:19:29 ◼   ► to go into let's just release this mode because you know last week we basically, you know,

00:19:36 ◼   ► I talked with you about how it, how I decided basically that it should be free because it

00:19:42 ◼   ► has benefits to me beyond just money. Like it benefits overcast, it benefits podcasts

00:19:50 ◼   ► as a whole. You know, it saves people time and it can generate a lot of goodwill for

00:19:55 ◼   ► a podcast. So I figured like based on that rationale, if it's going to be free, then

00:20:02 ◼   ► I don't, I have a lot less to worry about. I can pull out a lot of like weird license

00:20:06 ◼   ► checking code and I don't have to worry about like in app purchases or the Mac app store

00:20:10 ◼   ► or anything like that. Or building some kind of storefront for the website and then supporting

00:20:14 ◼   ► paid like the number of things you have to do and worry about and manage if it's free

00:20:20 ◼   ► drops down tremendously. And then also I figured like, well, I want to start accruing those

00:20:25 ◼   ► benefits now. All those benefits are going to have to overcast and to podcasting everything.

00:20:31 ◼   ► Why keep this private any longer? Like this is probably good enough to release for free

00:20:34 ◼   ► right now. And so I basically went into, you know, punch list mode as you said, like I

00:20:41 ◼   ► fixed the few remaining bugs I cleaned up. I disabled some experimental stuff that I

00:20:45 ◼   ► decided was a dead end. I polished up some of the rough edges and I released it. Now

00:20:54 ◼   ► the process of releasing a Mac app when you've mostly not released a Mac app before, I did

00:20:59 ◼   ► release Quitter before, so I have one Mac app that doesn't even have a window really.

00:21:04 ◼   ► Oh no, it does. I guess the preference is window. But yeah, like it's one very small

00:21:08 ◼   ► Mac app that lives in the menu bar and does very little. So that was a little bit easier.

00:21:13 ◼   ► But when you release apps outside of the Mac app store, and I don't want to get too much

00:21:16 ◼   ► into that, but once I decided that this was not going to be paid, the argument to be in

00:21:24 ◼   ► the Mac app store basically evaporated because the complexity of doing that and maintaining

00:21:30 ◼   ► a different version that was sandboxed versus not sandboxed, it was not worth it. And maybe

00:21:37 ◼   ► down the road it will be, but right now it's not. But when you're not in the Mac app store,

00:21:45 ◼   ► you basically have to build iTunes Connect from scratch for yourself. I think us iOS

00:21:50 ◼   ► developers have, we take a lot of things for granted. Things like updates. Like how does

00:21:59 ◼   ► your app update itself if it's not in an app store? And so what Mac apps do is they have

00:22:03 ◼   ► this framework called Sparkle usually that is like the auto- updating framework that

00:22:08 ◼   ► everyone has seen the windows of, but maybe you don't know what it's called. But almost

00:22:13 ◼   ► all apps use this on the Mac. But you have to then have an RSS feed on your server that

00:22:18 ◼   ► tells the app installations like what version is available. You have to have a signature

00:22:24 ◼   ► workflow on it to sign your updates to make sure that it's coming from you. And then you

00:22:29 ◼   ► have to have some kind of way to manage these builds and validate them. And so before when

00:22:34 ◼   ► I was just doing the forecast beta and for Quitter, I just have a couple of local shell

00:22:38 ◼   ► scripts that do all this. And it's pretty crappy, but it's pretty basic needs on those.

00:22:44 ◼   ► For forecast, it's an overcast product. So I decided it should be part of the overcast

00:22:48 ◼   ► website and that I wanted some kind of web management panel to do these things. So basically

00:22:58 ◼   ► yesterday I built all of this. I basically built myself a crappy, small, limited version

00:23:03 ◼   ► of iTunes Connect that I upload a build, it reads the plist, it pulls out the keys for

00:23:10 ◼   ► like build number and version number and everything and it sticks it all in the database and I

00:23:15 ◼   ► can edit the release notes, which is also good because then I can provide a version

00:23:18 ◼   ► history on the website very, very easily because it's all in the database. So I edit the release

00:23:22 ◼   ► notes for it, be able to publish it or have it not be published yet. Next I'm going to

00:23:28 ◼   ► create a beta channel, which I haven't done yet, but basically just not even to the level

00:23:34 ◼   ► of sophistication iTunes Connect had, just like a granularity of like, is this version

00:23:37 ◼   ► on the beta train or not? And then have a separate feed for that. Then it's all on the

00:23:42 ◼   ► overcast site and then it runs through your overcast CDN, so I don't have to worry about

00:23:45 ◼   ► like download, you know, overloads or overages. So it was a lot of work to build all that,

00:23:54 ◼   ► and this is like, it's one of those things like the first time you make a Mac app, you

00:23:57 ◼   ► learn all this crazy stuff. I mean, just like, you know, I guess similarly the first time

00:24:00 ◼   ► somebody makes an iOS app and you learn about like all the provisioning stuff that you have

00:24:05 ◼   ► to do and certificates and everything else. So I guess it isn't that different of an amount

00:24:09 ◼   ► of work, but you know, certainly the first time you build all this, it's a lot and this

00:24:14 ◼   ► is all even easier because it's free. Like if it was actually paid and I had my own storefront

00:24:21 ◼   ► on my website, I'd have to build that and manage that, and that's not a small thing

00:24:25 ◼   ► either. So there's a lot that you have to do in the Mac world that you don't have to

00:24:30 ◼   ► do in iOS, at least if you don't do the app store. And it's kind of made me appreciate

00:24:34 ◼   ► like, oh, this is why people still use the app store. Like not everyone uses it, and

00:24:39 ◼   ► a lot of big developers don't because they have the resources not to. But certainly if

00:24:44 ◼   ► you are a small developer and you just want to put something up, charge a few bucks for

00:24:49 ◼   ► it or whatever, the app store is way easier than doing it yourself. It's not even close.

00:24:54 ◼   ► I guess they get that 30% for a reason. So ultimately it was a ton of work, almost none

00:25:00 ◼   ► of which was the forecast app itself. Like almost all of it was putting together the

00:25:05 ◼   ► infrastructure and making a page for it on the site, writing what's on the page, taking

00:25:10 ◼   ► a screenshot, putting that on the page. It's all this work that we have when we release

00:25:17 ◼   ► a new app, especially if it's the first app for a certain platform that we've released.

00:25:22 ◼   ► There's so much work to do. It's like that last 1%, as you said, the last 1% is ridiculous

00:25:28 ◼   ► when it's like your very first Mac app that you've ever made. Like you make this happen

00:25:32 ◼   ► somehow. It's so much work. And it's nowhere near polished or done, but it's close enough,

00:25:38 ◼   ► it's functional. And so I just shipped it.

00:25:40 ◼   ► And I think, too, there's a more general point that I hear you saying. It's important to

00:25:46 ◼   ► remember, too, that there may be a lot of things that you have to do before you, even

00:25:52 ◼   ► when you finally get to the point that you let go and say, "Yep, this is good enough.

00:25:56 ◼   ► I'm going to put this in the store." Like there is still, like, the work is not done

00:26:00 ◼   ► at that point. Like the work may be done in Xcode. Like you may have finally uploaded

00:26:06 ◼   ► your binary to iTunes Connect or, in your case, like Overcast Connect. But then you

00:26:14 ◼   ► have all this other stuff that you have to do. Like are you going to do any kind of frequently

00:26:17 ◼   ► asked questions? Or do you have to build a website for it? Are you the thing? Like there's

00:26:22 ◼   ► any kind of marketing materials, even just the iTunes Connect kind of screenshotting

00:26:26 ◼   ► and all that kind of stuff. Like if you have a localized set of screenshots, it takes a

00:26:31 ◼   ► good day for whenever I need to update my screenshots, even when I automate a lot of

00:26:36 ◼   ► it. Like just because I think Pedometer++ is localized into 10 languages or something

00:26:43 ◼   ► like that. And so if I have multiple five screenshots times 10 languages times multiple

00:26:51 ◼   ► devices, like it just goes crazy. And it's important, I think, to keep that in mind,

00:26:56 ◼   ► too, that if you have set a deadline and you have communicated that, that you need to leave

00:27:01 ◼   ► buffer in your workflow so that you have time to do all this stuff that has nothing to do

00:27:09 ◼   ► with finishing the app, that you finally got your punch list down to good enough, you're

00:27:14 ◼   ► done, you still have a bunch of other stuff that you're going to have to do. And so just

00:27:18 ◼   ► like leaving enough buffer in your schedule to actually do that is important. Like I know

00:27:23 ◼   ► I've gotten caught out for iOS updates where it's like I feel like I'm working towards

00:27:29 ◼   ► making it so that as soon as the gold master version of Xcode comes out and as soon as

00:27:33 ◼   ► iTunes Connect opens up, I'm ready to go. And then I've forgotten that I'm like, I'm

00:27:38 ◼   ► going to need a whole new set of screenshots. And so rather than submitting right that moment,

00:27:42 ◼   ► I'm submitting like a day later. And so that's just entirely poor planning on my part.

00:27:47 ◼   ► Yeah, screenshots are my Achilles' heel. They always take me, like I always forget that

00:27:51 ◼   ► I have to do them. And then the very last minute I'm like, oh crap, I need to make forty

00:27:55 ◼   ► screenshots. This is bad. And then, you know, then I have to figure out some way to try

00:27:59 ◼   ► to automate some of it. I know there's tools out there to help with this, but I've never

00:28:02 ◼   ► bothered to set one up. And so it's it's that's a big deal. This is one of the reasons why

00:28:08 ◼   ► I haven't made a preview videos yet. I probably should make videos just to try them out, but

00:28:13 ◼   ► I haven't yet in part because that's a massive undertaking to add to this, like to add like

00:28:21 ◼   ► the production of an entire video to the list of things you have to do every time your UI

00:28:26 ◼   ► changes. That's or every time a new device comes out. That's a that's a large amount

00:28:31 ◼   ► of work. And so, you know, it has to be pretty compelling. And I just I haven't had the time

00:28:36 ◼   ► to do it yet. But, you know, now, you know, forecast is out. You know, it's mostly stable.

00:28:42 ◼   ► You know, I don't think I need to do a whole lot of work on it release wise. Overcast is

00:28:46 ◼   ► pretty stable. So I'm back in a good place now. But man, that last one percent on both

00:28:51 ◼   ► of those things was was killer. Yeah. And I think the thing that's fun is like now you're

00:28:55 ◼   ► in the place that is, at least if anything, if you're anything like me is the best part,

00:28:59 ◼   ► right? Now you can look at your big long feature list and you're like the reward for battling

00:29:04 ◼   ► through that last one percent is that you now have the opportunity to look at your like

00:29:08 ◼   ► fun feature list and, you know, decide what's fun to work on next. And like that's in a

00:29:14 ◼   ► weird way. It's like as an engineer, like the best reward for for for lots of hard work

00:29:18 ◼   ► is more hard work. But at least it's like the fun work that I enjoy doing rather than

00:29:23 ◼   ► the hard like the the grunt work that I don't enjoy doing as much. Exactly. All right. We're

00:29:29 ◼   ► out of time this week. Thanks for listening, everybody. And we'll talk to you next week.

00:29:32 ◼   ► Bye.

00:29:33 ◼   ► Bye.

00:29:34 ◼   ► [ Silence ]