What do I do when starting a new app before building?

What's up, everybody? Welcome to another episode of the CompileSwift podcast. I'm your host, Peter Witham. You can find myself and this podcast at compileswift.com.

Now first of all, if you are a member of our dev club Discord, there's a link in the show notes, you're probably laughing and smiling right now because we were joking about that very sentence that I use at the beginning of the podcast and we're all pretty convinced that I'm AI at this point, but I'm not, I assure you. Anyway, moving on with the episode. A question from our discord and it sounded like such a good idea. I thought why not make an episode on it and it goes like this. What do you do?

What's your routine before you start working on that new project, that new idea that you have? And I thought, okay, I'll go through and I will talk about this and tell you how I do it. So what I do is if I've got an idea for something the first thing I do is write it down somewhere. Just jot down that idea because I know that distractions of the day, an hour, 2 hours later, or in my case, I have a lot of good ideas or I think, just before I go to bed and if I don't write them down I know I'm gonna forget them by the morning because that's what happens every time so write it down After that, what I start to do is I say to myself, okay, let's flesh this idea out a little bit. And I try to come up with a list and it can be a very short list of what the core idea, the core features of this project needs, what it is that makes it, defines it to be, in this case, the app that it's gonna be.

And like I say, this can be a very short list or maybe a long list, but you don't want it to be too long because what I try to do is focus down on that core thing, that that idea of what is this app. And then, by all means, make another list of of cool things that you think of that it could do as well. But the focus really has to be what is the the the central feature of this app? Why am I using this app? Why would someone else use this app?

So that's the next thing I do. Now once I've got that list, I'll start to just sketch out, in my case, I like to do it a lot of the time on paper first of all or I have apps on my iPad that I'll use and I'll just sketch out sit down with a pencil, pen, whatever and draw out a really bad design. But in that design, I will put again those core features. That thing that says, as I'm sitting looking at this app ready to use this main feature, this is what it's gonna look like or this is what it should have on the screen. For example, if it's an audio recording app, at the very least it's gonna have a button to record, a button to playback and that's it.

That is the very absolute minimum that you need for that audio. Put those features into kind of a really rough sketch. Don't spend too long on it. Just literally translate the words into a really bad design, but it now gives you on the screen this view of, okay, the these are the things I've got to incorporate. Now I don't start diving too deep into the design at that point.

The next thing I would be doing is I would look at it and I would now have this idea, this really bad sketch, and I'd ask myself

Time for a break.

Hey, folks. If you like what you're hearing in this podcast and you wanna help this podcast to continue going forward and having great guests and great conversations, I invite you to become a Patreon supporter. You can go to patreon.comforward/compile swift, where you will get ad free versions of the podcast along with other content.

Break time over.

Okay. Have I ever seen or do I use apps that are similar to this in any way? And if I have, I'll go do a little bit of research, not too much because I think if you spend too long doing too much research, it actually can have a negative effect because the chances are you'll come across all these other really cool apps that maybe you use or you've seen or that you find. And that might start to convince you that it's a really bad idea and you shouldn't make it. And I think that's a terrible thing because as I've always said before, yeah, okay.

Maybe there's a 1,000,000 audio recording apps. But if you've never built one, there's not your one. The one that you would make does not exist. So you should do that. Several reasons I've I've mentioned this in episodes before.

1, it's good to practice your skills. 2, it's good to expand your skills. If you've never made an audio app, you're gonna have challenges you've never dealt with before. And at the end of it, okay, maybe it turns out the project's not so great, but you will have gained all that experience from making it. So do a little bit of research, see what else is out there, take inspiration from it, but don't take their ideas.

Right? Don't plagiarize their apps, their designs, all of those kind of things. Just take them as some inspiration for what you think you wanna see in your app. So for example, you've got this record button, this play button. You might go see another app.

It shows the audio timeline and you can scrub through the audio. Okay. Great. Maybe that's something you wanna put in your app. Right?

Something like that. And again, add that to your list, translate it into this rough design. And I like to use an app. Shout out to the Muse app here. I'll put a link in the show notes.

Adam, shout out to you, buddy. I will gather it's it's a whiteboarding app. I will gather screenshots, ideas, my list. Maybe I'll take a photograph of my really hand drawn badly hand drawn sketch and put it in there. And I'll just gather it all into this board that becomes eventually where I might plan my project.

But it gives me something to stare at where I've got everything there and I can look at it. Now, again, at this point, I probably am still not writing code, would not even have started the project. And I will keep revisiting this for a few days because I know from previous experience when I do something like this, if I wait a couple of days and come back to it, my ideas will change. And especially when it comes to maybe that really terrible interface, I'll look at it and go, wow, that's really bad. I got a better idea.

So I let it sit and bake for a couple of days while I'm still thinking about it and messing around with it there. Now after that, once I feel like okay I've got my core idea and some sort of idea what the interface is gonna look like, yes, then I will sit down with my apps or again, maybe by hand. I still like doing a lot of analog because you all know if you've listened to previous episodes. And I will start to make a small serious attempt at a functional interface, not necessarily the prettiest thing on the planet. Now the reason I do it that way is because once I've got that functional design view that has what I think are the controls that I need again record, play, scrubbing of a timeline, whatever, maybe saving of a file something like that.

Once I've got those in my design, then I will start thinking about putting together a prototype or exploring things that I I now recognize I don't know. So for example, if I'm making on the Apple platforms an app with audio and I don't know anything about any of the audio kits or anything like that, core audio, whatever, Now I'll start playing with those, and I may make multiple projects to understand how each of those work. Right? Another example, if you have never loaded a file in from say Icloud or your device into an app, that might be something that you would make a little project for. So I would make up myself a little list of these, the knowledge bombs that I need to go find and understand.

And then at that point, I would feel like I have enough to now actually start putting a full prototype together and maybe kicking around a better design for the interface as well. But that is basically all of my pre work anytime I have an idea that I think I'm actually gonna make into something. Now the other reason that I like to do a lot of this analog on paper is I have notepads with these ideas. Many of these ideas. Right?

That maybe I've never used them but they still exist. They're still on paper. We've all done this, right, as developers. All those test projects, right, you've got that developer folder with say Xcode projects and there's a whole ton of folders and and projects in there that have never become to be something. This is my analog equivalent, and I can go back to those at any time.

Sometimes I might be thinking, oh I'm gonna do this thing and then I'll remember, oh it's gonna have this audio element. I can now come back to this project even if I abandoned it and look at it and go, oh, I can use these ideas. So that's my entire sort of pre build process there. So I hope I've done the question justice to the question in the Discord. Again, dev club Discord.

I'll put a link in the show notes. But I thought it was such a great idea to put this together as an episode to share it with other folks who may be wondering, do you dive straight in and and do the code and why I don't think that's a good idea. If you have any thoughts on this, love to hear from you. You know what to do. Compile Swift on on any other networks or go to compileswift.com.

There's a contact form. And if this has been helpful, hey, you also know what to do. Share it with someone, leave a comment, leave a rating. Greatly appreciate that. If you wanna take it up to the next level, go to patreon.comforward/compileswift where you can support the future of this podcast and get ad free versions.

That's it folks. Next time around, at this point, we may well be talking about dub dub dc. If I've got an interview in the Bay that may make it out just before the dub dub DC hits, we'll see. But either way, I will see you at confidence time folks.