CONNECT

So I’m looking at laying out my interface using storyboards. I could manually build out each screen, but I’m not sure what would be the point. If you haven’t done much iOS before, basically every single screen is a view controller. So using storyboards is just a matter of throwing view controllers down.

As with all iOS endeavours, what I find is wiring the screens together isn’t the big issue – it’s always passing data back and forth or how that data persists. I think I’ll start with a simple singleton object. Something I attach to the app delegate. I know this might not be a long term solution, but in the short term it will get me to a functioning prototype.

Thinking about a prototype… I’m wondering how soon I could actually throw something on the App Store. Do this really agile… Chuck an app up, get people playing around with it and then iterate on it. I’ve read 2-3 days or as much as 8 days to get an app reviewed. Anyone have any recent experience with this?

I started by laying out the very bare essential screens I needed. I didn’t even consider navigation. Then I started drawing lines to and from the screens. The navigation options started to jump out.

I’m not building any kind of utility application, so using Pages or flipping back and forth between a couple view controllers won’t work. I’ve got to assume 90% of apps come to this conclusion pretty early… unless they are making a flashlight or a task list. So really you end up at navigation controller or tab bar controller… or a combination of both. You could always go ahead and come up with something really dramatic like Path, but that would take me way past MVP. I told myself no custom navigation elements. I’ll never get this done in a short period of time.

I’m gonna do a bit of paper prototyping tonight. See if one of the patterns really jumps out at me. I’m going to use the UI Stencils iPhone Sketch Pad and their app to test the prototype. I ordered these a while ago and so its time to put them to good use.

After that I’ll probably take a break until tomorrow morning. Then the code starts. I’ll be posting about the issues I run into or any a-ha moments I have with things like location, searching, and camera (yes that was a bit of a hint).

I’m also going to throw together the rails backend tomorrow morning. Should be easy, not going to do much except design the url routes and models. I’ll just hard code some JSON responses for now. I think that exercise will help me determine what objects I might be dealing with in iOS early on.

I should have something ridiculously rough tomorrow… that’s the goal anyway.

Come up with an MVP. If you’re not familiar, basically a list of app features the app must have to be the product you dreamed up. However, this shouldn’t prevent you from writing EVERYTHING down. You never know… it might just become a big deal and you’ll get to do all the cool things you want to do.

So, what was interesting about making the list was that I looked at it from two angles. What features did the app need to have – and what features would be easy… ish to develop. Having some understanding of iOS and backend of development is pretty crucial here. Otherwise you’ll just go ahead and plan out a 3D first person shooter…. (I’m not making one of those… I swear).

I’m moving on to design – going to skim some of the books again. Making the list also gave me some idea of how the app might look work. Side note: does anyone else think that iOS 7 made it easier to come up with a design? Skeuomorphism seemed like a higher bar in terms of coming up with the assets to make your designs look like ‘real world’ things.

Anyway. Lessons learned. Make a list, scratch off the items that are totally necessary or will require huge technical investments or post major technical hurdles.