

How To Prototype In Xcode Using Storyboard - wallflower
http://blog.mengto.com/prototype-xcode-storyboard/

======
taybenlor
We've had some of our designers at work use this approach. I think it's quite
good for illustrating intentions. But then building on top of the designed
Storyboard doesn't quite work out.

Storyboards work well for simple apps with standard UI. Once you start
building something custom or complex they are a poor tool. If you have a
designer then they're likely going to be making custom UI which will need code
(maybe lots of it). The Storyboard quickly becomes a crazy mess of placeholder
views, implementation details, arrows and blank screens. The designer can no
longer use it to demonstrate their ideas and you've probably completely ripped
out their original work.

If your only intention is to make a interactive demonstration of screen
progressions - then this is perfect. But don't think that this has the same
reusability as making a HTML+CSS+JS mockup.

~~~
potatolicious
I work on an app with a _lot_ of custom UI - custom UIControls, heavily custom
UIViews, etc. Storyboard is a complete no-go for us because of this. Its
primary strength - the nearly-WYSIWYG preview, is completely gone, and what's
left is the insane XIB system and lack of scriptability.

The app I work on also does a great deal of custom drawing instead of relying
on a truckload of assets. This has given us _incredible_ speed and flexibility
where we can tweak, refine, and polish without tiresome trips to our designers
for assets (perk: your designers don't hate you for the endless grunt work).
None of this fits well into a Storyboard-based workflow.

There is, IMO, a lot to be said for proceduralizing your UI instead of a
reliance on a massive bundle of assets. It's a topic I do not see being
covered in the iOS community but confers incredible speed and flexibility (and
download size, oh man the download size).

~~~
jurre
AFAIK the reason that this isn't very common in the iOS community is that
loading an image is often much faster (performance wise) than drawing a custom
UI. What are your experiences with this?

~~~
potatolicious
Depends on size of image. The file system, while much faster than a spinning
disk, is still slow enough that saving/loading large files (say, nearly-full-
screen-sized) has a noticeable performance impact. Especially if you do it on
the main thread (as people tend to do).

If this asset is nothing more than a gradient with some trimmings, it'll be
substantially faster to just draw it. Also bear in mind that manual drawing in
iOS is _blisteringly_ fast.

You are right though - blitting a 32x32 icon to screen from a cached image is
substantially faster than translating it from a vector format (say, an icon
font). That being said, all of the iOS devices in common use today have a
_large_ amount of CPU performance headroom that makes this rather moot. We
have absolutely no trouble hitting 60fps consistently drawing all of our own
UI procedurally. Your main bottleneck is in your GPU's fill rate (and even
then, only on the original iPhone 4), which limits the amount of
overdraw/offscreen rendering you can do.

Some things in iOS-land are still slow. CALayer shadows for example are _very_
slow if you use them directly out of the box (where they determine the visible
mask of the layer and cast a shadow based on that). But they are very, very
fast if you know the magic buttons to push (e.g., setting the shadow path to a
fixed shape). Proceduralizing your entire UI definitely takes a bit of
experience with Core Animation and Core Graphics.

The workflow gains we make, though, are massive. All of our iconography is
vector-based, and all of our UI dynamically drawn. Need that button a
different shade of green? Done. Need to change the depressed state of the
button? Done. Icon a bit small? Done. Shadow should be a touch lighter? Done.
We do take some performance loss for this, in theory, but since there is so
much headroom it doesn't actually translate to a noticeably (read: sub-60-fps)
degraded experience.

------
DesaiAshu
Love this! I feel like I'm one of the few developers who really appreciates
storyboards. Our game Ghost (built as an open source template available here:
<http://www.makegameswith.us/sdk/>) was built using a pretty simple / clean
storyboard. Using it forced us to rely on a simple menu structure, and saved
us thousands of lines of code. While I think there is work to be done on
improving compatibility with version control + adding flexibility to customize
UI elements directly in the editor, I think it's a phenomenal tool for
prototyping and often great for building complete apps.

------
esusatyo
Just a note to fellow developers: if you started developing for iOS way before
storyboards and started working on a new project with storyboard, some methods
are not behaving as it was previously.

For example in the awakeFromNib and viewDidLoad method, views that you created
in storyboard wouldn't have been initialised even thought it used to work like
that in Interface Builder. See this SO answer:
<http://stackoverflow.com/a/12811188/361247>

------
nicholassmith
I think Storyboard is a massively useful feature that has some crippling long
term limitations depending on what you're building, but using it for design
prototypes is a good thing. If you're using a Storyboard prototype at least
you know the designer has worked within the constraints (ish) of what is
doable, and then you can build from there, and gives you a nice run on what
you want to do in terms of visual cues.

------
troels
Lovely article, but it would be easier to follow the tutorial if you provided
the assets (images etc.) along the way. I realise that there is a full zip
halfway through (and further down), but in the beginning of the article it's
missing.

------
ardit33
If you are building anything serious, (lets say more than few screens), then
avoid Storyboards like the plague. They make some stuff easier, but doing
anything advanced with them is a pita. They are crutch, that might help you if
you are just getting started, but do slow down people that are doing anything
substantial/non-trivial.

