Once you’ve built your iOS skills up to a certain point, your mind probably starts going crazy coming up with ideas for apps to build. App ideas that will grow your knowledge (like maybe cloning an existing app?), or maybe apps you want to release to the App Store to make some money. Finally, you pick one that you are ready to build. And then you freeze.
You’re thinking: ”I’ve got my great idea. Now how the @*%$( am I going to build it?” Because it looks overwhelming. So many screens to design and code, an app workflow to develop, backend services to connect up, new iOS concepts to learn. But you open Xcode, select New Project, and you don’t even know which new app template to pick.
The blank page problem. This happens when we’re starting an app, adding features, anytime we’re building something new. It’s something big and unclear. There are so many parts, and you have no clue how they fit together. Or worse, you don’t even know all the moving parts in the first place.
Every creative discipline knows this problem well, and all of them have developed various techniques to combat it. Here is a useful framework I use as I’m building a new app or new features for an app to begin and keep filling in that blank page.
Do you think about the big picture first?
If when you start working an app, you think about the big picture first: the set of screens you will need and the navigation flow, this is a great mode to start in.
Depending on the nature of your app, whether you’re developing alone or on a team, what tools you use, etc., this might involve opening up a design tool like Sketch, Figma, or the like, or dropping straight into Interface Builder to do some prototyping. Even if you normally write your UIs in code, for this step of the process, it is much better to do something visually first. You want that rapid feedback of seeing and changing things on the fly — you’re going to be doing a lot of experimenting.
At this stage, less work is your friend. With this technique, you’re trying to build out the navigation flow of the app to get an idea of which screens you need to build, and which controls you will need to make that navigation possible. You should only flesh out as little of the interface as you need to, and use static text, images, assets, etc. as much as possible. Just keep chanting: as little code as possible, and only what is needed to make your interface look correct (sometimes necessary for Interface Builder)!
The point is to make it look like what you want to create. With that process complete, you’ll have the clarity to know what you need to build and how to plan it out and build it for real.
Do you think about the details first?
On the other hand, you may have a really clear picture of what one of your screens looks like. Or maybe not even a full screen: maybe it’s one of your custom controls that you see with perfect clarity. Take advantage of that and really work on that component.
This is where Xcode Playgrounds really shine. You can focus on one particular screen without the additional overhead or distraction of having an app wrapped around it. Once you’ve built your view controller, you can simply copy the source into your app. While a little heavier weight, a single-view app project can work just as well, and is necessary if you want to use some features like storyboards/XIBs, asset catalogs, and other features that require a full app backing it.
Building one screen with detail will start to fill in a list of other view controllers to which that screen’s controls will need to navigate. Once you’ve worked on a particular view controller to your satisfaction — notice I didn’t say to completion! — you can take one of the view controllers from that list and start building that.
If there is any additional guiding principle for this idea, is that if you do know upfront — or are at least pretty sure — which screen will serve as the main screen of your app, you should start with that one. That screen is the core of your app; it will create a strong scaffold you can build the rest of your app from.
Bouncing between the two?
The truth is that most of us don’t work exclusively in one of these modes or the other. While I definitely prefer the “big picture” method of building my app’s navigation out first, there are occasions where I just can’t make any further progress fleshing out my broad app design without getting really detailed about one of my view controllers. At that point, I switch modes and dive deep into that particular screen.
After you’ve worked this way for a while, you’ll notice this sort of “see-saw” pattern as well. You’ll pick one method, work that way for a while, and then notice you’re getting stuck. At that point, you should consider switching modes. I’ve found that more often than not, the reason you’re stuck is because you don’t have enough clarity to continue in that mode of thinking.
Bouncing between these two modes keeps a healthy balance between how your interface works at a detailed level, and how the app works as a whole. That clarity is what keeps you working at your best pace.
Don’t be afraid to throw out
Finally, a tip that comes in handy whichever mode you’re in: don’t be afraid to throw things out. You’re in new territory, and you don’t know exactly how your product is going to look and work in the end. You could build something, put it aside for a while, come back to it, and decide it stinks. It happens. A lot.
If it stinks, and there’s something better you can do, you should replace it. This is why through both modes above, I emphasized doing as little work as possible. Throwing out work is always painful, but the less work you did, the easier it is to throw it out and do something else. While you’re in pure building mode, this gives you the flexibility to try different things to decide on the right way to do something, without taking huge amounts of time to make perfect code, only to throw it out later.
I hope this helps you get past that blank page, and get moving on building your next app! Now get going!
Comments are closed.