In my work, I tend to use two kinds of prototypes:

Static (or “tappable”) prototypes. These help to explore, explain, and test user flow concepts pretty quickly. They take anywhere from 5 minutes to an hour to create, and
Dynamic (or “animation study”) prototypes. These work to describe the animations, easing curves, or custom transitions in your app. These take anywhere from 30 minutes to a day to create. For this post, I’ll focus on the first use case - creating static prototypes.

When to use a static prototype

Whether you’ve got sketches, wireframes, or visual designs, it’s really helpful to create a walk-through to demonstrate a user flow.

I love using static prototypes in place of a huge wireframe deck - in the same way that a photograph is worth a thousand words, a simple prototype is worth a hundred design comps. You can express in a few minutes what would otherwise take a long, drawn-out meeting to walk through a wireframe deck.

Outside of presenting designs, static prototypes are a great, lightweight way to make your wireframes or visual comps interactive for usability testing.

How to make a static prototype

There are a ton of tools out there, and I’ve tried many of them (Flinto, Keynote, Briefs, among others) but by far, the best tool among ‘em is Flinto. It’s crazy-fast to build, install, demo, and update the prototypes - and just enough fidelity to get the point across without trying to be a replacement for your design or development tools.

First, you’ll need some screens. Either sketch ‘em out on paper, throw together some wireframes, or export your visual designs to flat image files.

Next, go to flinto.com, create a new prototype, and drop those screens in. I’ll leave it to you to learn the tool - it’s super intuitive.

A few tips to really make the prototype sing:

Use transition animations. There’s the standard UINavigationController-style push, pop, present, and dismiss - I’d skip the rotational-flip ones, unless you’re some kind of monster - but the crossfade is often a nice choice if you’re changing out the content while remaining in the “same” view.
There’s a timer function; you can have the prototype pause for a moment on a screen and then transition to the next screen. This is great for prototyping the loading state of a screen.
Pay attention to the status bar style. It’s a limitation of iOS Safari that you can only have a single status bar color for your fullscreen webapp - so you’ll need to choose either light, dark, or a black background status bar for the entire prototype. Choose wisely.
Make your lists scrollable. If you’re creating a prototype with long UITableViews or UICollectionViews, use a tall image for the screen - say, 2000 pixels high - and Flinto will make that screen scrollable. Then, use the Top Slice and Bottom Slice tools to carve out any UINavigationBars or UIToolBars - those will remain fixed in place as you scroll the rest of the content.
Test on-device and in-browser before you present. You might have status bars in your comps, and Flinto has some smart tools to try and work around it, but you’ll want to test the prototype on-device and in-browser for any glaring issues before you present your work to a larger audience.
Use the generic “back” transition. One of Flinto’s real strengths is its generic “back” transition - essentially, it performs the inbound transition in reverse, back to whichever parent view you came from. (Very useful when you have, say, a user profile view that gets accessed from three different places - don’t make three profiles, use one, with a back transition.)

Using the prototype

Use these static prototypes to get a feel for an idea before writing code, or to share a user flow far more effectively than you could with a set of wireframes.

When it comes to using your prototype, Flinto really sings:

If you open the prototype on your laptop, you’ll get a fullscreen presentation mode, ready for sharing. If you open the prototype on your phone, it’ll behave nearly as if it were a real app.
If you share the prototype with others, you can make updates, and all of the prototypes will be updated the next time they’re launched. You can even nuke the URL, so that if you’ve changed the design significantly, there’s not an old, crusty ghost-design floating around.
You can choose whether to show “hints” in the prototype - if you’re doing usability testing, turn them off; if you’re sending a prototype out to team members, turn them on.

So: if you haven’t already, go check out Flinto, and enjoy! If you have any questions, Flinto’s really quick to respond on their Twitter account - or you can shoot me a question there, too.