HIRE A DEVELOPER

APPLY AS A DEVELOPER

WHY HOW WHAT CLIENTS TEAM COMMUNITY BLOG

LOGIN

CALL US: 888.604.3188

RESOURCES VIDEOS CONTACT FAQ

iOS User Interfaces:

Storyboards vs. NIBs vs.
Custom Code

View all articles

SUBSCRIBE

FREE EMAIL UPDATES

Get the latest content first.
BY ANTONIO BELLO - IOS DEVELOPER @
TOPTAL

Enter your email address...

#iOS #Storyboards #NIBs #ObjectiveC

Get Exclusive Updates
Share

Share
Tweet

10
66
84

No spam. Just great engineering

posts.

TRENDING ARTICLES

I often hear iOS developers ask

some variant of the same key
question:
Whats the best way to develop
a UI in iOS: through
Storyboards, NIBs, or code?
Answers to this question, explicitly
or implicitly, tend to assume that
theres a mutually exclusive choice

Why I Decided To
Embrace Laravel
about 23 hours ago

Ruby Concurrency and

Parallelism: A Practical
Primer
10 days ago

From the Ground Up:

How I Built the

to be made, one that is often

addressed upfront, before
development.
Im of the opinion that the answer
instead should take the form of one
or more counter questions.

Whats the best car?

Let me explain with an off-topic
example. Say I want to buy a car
and I ask you one simple question:
Whats the best choice?
Can you really answer by
suggesting a model, or even a
brand? Not likely, unless you
suggest a Ferrari. Instead, youd
probably answer with a few other
questions, like:
Whats your budget?
How many seats do you need?
Do you care about fuel
consumption?
How do you feel about sports
cars?
Its obvious that theres no such
thing as a good or bad car unless
its placed in a proper context
theres just a good or bad car
based on specific needs.

Developer's Dream
Keyboard
about 1 month ago

Using Logstash to
Streamline Email
Notifications
2 days ago

Shazam It! Music

Processing,
Fingerprinting, and
Recognition
11 days ago

Predicting Likes: Inside

A Simple
Recommendation
Engine
9 days ago

RELEVANT TECHNOLOGIES

Front-end
Mobile
Objective-C
UI
Xcode
iOS

TOPTAL AUTHORS

Nikolay Derkach
Software engineer

Ryan J. Peterson
Software Engineer

L Anh Qun

Back to iOS UI Design

Just like with our car inquiry, the
Whats the best way to develop an
iOS UI question lacks context. And
surprisingly enough, the answer
need not be a catch-all case.

Software Engineer

Ivan Vasilev
Java Developer

Mahmud Ridwan

Broadly speaking, there are three

types of user interface design
approaches that you can take, each
with its pros and cons, its fans and
haters:
iOS Storyboards: A visual tool
for laying out multiple
application views and the
transitions between them.
NIBs (or XIBs): Each NIB file
corresponds to a single view
element and can be laid out in
the Interface Builder, making it
a visual tool as well. Note that
the name NIB is derived from
the file extension (previously
.nib and now .xib, although the
old pronunciation has
persisted).
Custom Code: i.e., no GUI tools,
but rather, handling all custom
positioning, animation, etc.
programmatically.
None of these options are
universally better than any other
(despite what you might hear).

Freelance Software Engi

View all authors

Storyboards, for example, are the

latest addition to the iOS UI toolkit.
Ive been told that theyre the
future, that they will replace NIBs
and custom code UIs. I see
Storyboards as a useful tool, but
not so much a replacement as a
complement for NIBs and custom
code. Storyboards are the right
choice in some, but not all
situations.

Further, why should you statically

stick to a single option when you
can use them all (in the same
project), picking the mechanism
that best fits the specific problem
at-hand?
This is a question that can be, in my
opinion, generalized at a higher
level, and whose answer is ranked
highly in my list of software
development principles: There is no

universal language, framework, or

technology that is the universal
best choice for every software
development problem. The same is
true for iOS UI design.
In this iOS development tutorial,
were going to explore each of
these methods and introduce use
cases in which they should and
should not be employed, as well as
ways in which they can be blended
together.

iOS Storyboards
A classic beginners mistake is to
create one massive project-wide
iOS Storyboard. I too made this
mistake when I first started working
with Storyboards (probably
because its a tempting route to
take).

A classic beginners
mistake is to create one
massive project-wide
Storyboard. A Storyboard
is a board with a story to
tell. It shouldn't be used
to mix unrelated stories
into one big volume.
As its name implies, a Storyboard is

a board with a story to tell. It

shouldnt be used to mix unrelated
stories into one big volume. A
storyboard should contain view
controllers that are logically related
to each otherwhich doesnt mean
every view controller.
For example, it makes sense to use
Storyboards when handling:
A set of views for
authentication and registration.
A multi-step order entry flow.
A wizard-like (i.e., tutorial) flow.
A master-detail set of views
(e.g., profiles lists, profile
details).
Meanwhile, large Storyboards
should be avoided, including single
app-wide Storyboards (unless the
app is relatively simple). Before we
go any deeper, lets see why.

The Folly of Large iOS

Storyboards
Large Storyboards, other than
being difficult to browse and
maintain, add a layer of complexity
to a team environment: when
multiple developers work on the
same storyboard file at the same
time, source control conflicts are

inevitable. And while a storyboard

is internally represented as a text
file (an XML file, actually), merging
is usually non-trivial.
When developers view source
code, they ascribes it semantic
meaning. So when manually
merging, theyre able to read and
understand both sides of a conflict
and act accordingly. A storyboard,
instead, is an XML file managed by
Xcode, and the meaning of each
line of code is not always easy to
understand.
Lets take a very simple example:
say two different developers
change the position of a UILabel
(using autolayout), and the latter
pushes his change, producing a
conflict like this (notice the
conflicting id attributes):
<layoutGuides>
<viewControllerLayoutGuide type
<viewControllerLayoutGuide type
</layoutGuides>
<layoutGuides>
<viewControllerLayoutGuide type
<viewControllerLayoutGuide type
</layoutGuides>

The id itself doesnt provide any

indication whatsoever as to its true
significance, so you have nothing to
work with. The only meaningful
solution is to choose one of the two

sides of the conflict and discard the

other one. Will there be side
effects? Who knows? Not you.
To ease these iOS interface design
problems, using multiple
storyboards in the same project is
the recommended approach.

When to Use Storyboards

Storyboards are best used with
multiple interconnected view
controllers, as their major
simplification is in transitioning
between view controllers. To some
degree, they can be thought of as a
composition of NIBs with visual and
functional flows between view
controllers.

Storyboards are best

used with multiple
interconnected view
controllers, as their major
simplification is in
transitioning between
view controllers.
Besides easing navigation flow,
another distinct advantage is that
they eliminate boilerplate code
needed to pop, push, present, and
dismiss view controllers. Moreover,
view controllers are automatically

allocated, so theres no need to

manually alloc and init .
Finally, while Storyboards are best
used for scenarios involving
multiple view controllers, its also
defensible to use a Storyboard
when working with a single table
view controller for three reasons:
The ability to design table cell
prototypes in-place helps keep
the pieces together.
Multiple cell templates can be
designed inside the parent
table view controller.
Its possible to create static
table views (a long awaited
addition thats unfortunately
only available in Storyboards).
One could argue that multiple cell
templates can also be designed
using NIBs. In truth, this is just a
matter of preference: some
developers prefer to have
everything in one place, while
others dont care.

When Not to Use iOS

Storyboards
A few cases:
The view has a complicated or
dynamic layout, best-

implemented with code.

The view is already
implemented with NIBs or code.
In those cases, we can either leave
the view out of the Storyboard or
embed it in a view controller. The
former breaks the Storyboards
visual flow, but doesnt have any
negative functional or development
implications. The latter retains this
visual flow, but it requires additional
development efforts as the view is
not integrated into the view
controller: its just embedded as a
component, hence the view
controller must interact with the
view rather than implementing it.

General Pros and Cons

Now that we have a sense for when
Storyboards are useful in iOS UI
design, and before we move on to
NIBs in this tutorial, lets go through
their general advantages and
disadvantages.

Pro: Performance
Intuitively, you can assume that
when a Storyboard is loaded, all of
its view controllers are instantiated
immediately. Fortunately, this is just
an abstraction and not true of the

actual implementation: instead,

only the initial view controller, if
any, is created. The other view
controllers are instantiated
dynamically, either when a segue is
performed or manually from code.

Pro: Prototypes
Storyboards simplify the
prototyping and mocking up of user
interfaces and flow. Actually, a
complete working prototype
application with views and
navigation can be easily
implemented using Storyboards
and just a few lines of code.

Con: Reusability
When it comes to moving or
copying, iOS Storyboards are
poorly positioned. A Storyboard
must be moved along with all of its
dependent view controllers. In
other words, a single view
controller cannot be individually
extracted and reused elsewhere as
a single independent entity; its
dependent on the rest of the
Storyboard to function.

Con: Data flow

Data often needs to be passed

between view controllers when an

app transitions. However, the
Storyboards visual flow is broken in
this case as theres no trace of this
happening in the Interface Builder.
Storyboards take care of handling
the flow between view controllers,
but not the flow of data. So, the
destination controller has to be
configured with code, overriding
the visual experience.

Storyboards take care of

handling the flow
between view
controllers, but not the
flow of data.
In such cases, we have to rely on a
prepareForSegue:sender , with an
if/else-if skeleton like this:

- (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(

NSString *identifier = [segue identifier];
if ([identifier isEqualToString@
MyViewController *vc = (MyViewController *) [segue destinationView
[vc setData:myData];
} else if ([identifier isEqualToString@
...
} else if ...
}

I find this approach to be error

prone and unnecessarily verbose.

NIBs

NIBs are the old(er) way to perform

iOS interface design.
In this case, old doesnt mean
bad, outdated, or deprecated.
In fact, its important to understand
that iOS Storyboards arent a
universal replacement for NIBs;
they just simplify the UI
implementation in some cases.
With NIBs, any arbitrary view can
be designed, which the developer
can then attach to a view controller
as-needed.
If we apply object-oriented design
to our UIs, then it makes sense to
break a view controllers view down
into separate modules, each
implemented as a view with its own
NIB file (or with multiple modules
grouped into the same file). The
clear advantage to this approach is
that each component is easier to
develop, easier to test, and easier
to debug.
NIBs share the merge conflict
problems we saw with Storyboards,
but to a lesser extent, as NIB files
operate at a smaller scale.

When to Use NIBs for iOS UI

Design
A subset of all uses cases would

be:
Modal views
Simple login and registration
views
Settings
Popup windows
Reusable view templates
Reusable table cell templates
Meanwhile

When Not to Use NIBs

You should avoid using NIBs for:
Views with dynamic content,
where the layout changes
significantly depending on
content.
Views that by nature are not
easily designable in the
Interface Builder.
View controllers with
complicated transitions that
could be simplified with
Storyboarding.

General Pros and Cons

More generally, lets walk through
the pros and cons of using NIBs.

Like what you're reading?

Get the latest updates first.
Enter your email address...

No spam. Just great engineering posts.

Get Exclusive Updates

Like what you're reading?

Get the latest updates first.
Enter your email address...

No spam. Just great engineering posts.

Get Exclusive Updates

Pro: Reusability
NIBs come in handy when the
same layout is shared across
multiple classes.
As a simple use case, a view
template containing a username
and a password text field could be
implemented with the hypothetical
TTLoginView and TTSignupView
views, both of which could
originate from the same NIB. The
TTLoginView would have to hide
the password field, and both would
have to specify corresponding
static labels (such as Enter your
username vs Enter your
password), but the labels would

have the same basic functionality

and similar layouts.

Pro & Con: Performance

NIBs are lazily loaded, so they dont
use memory until they have to.
While this can be an advantage,
theres latency to the lazy loading
process, making it something of a
downside as well.

iOS Custom Code

(Programmatic UIs)
Any iOS interface design that can
be done with Storyboards and NIBs
can also be implemented with raw
code (there was a time, of course,
when developers didnt have the
luxury of such a rich set of tools).

What cannot be done

with NIBs and
Storyboards can always
be implemented with
code.
Perhaps more importantly, what
cannot be done with NIBs and
Storyboards can always be
implemented with codeprovided,
of course, that its technically
feasible. Another way of looking at

it is that NIBs and Storyboards are

implemented with code, so their
functionality will naturally be a
subset. Lets jump straight into the
pros and cons.

Pro: Under the Hood

The greatest advantage of creating
an iOS UI programmatically: if you
know how to code a user interface,
then you know what happens
under the hood, whereas the same
is not necessarily true of NIBs and
Storyboards.
To make a comparison: a calculator
is a useful tool. But its not a bad
thing to know how to perform
calculations manually.
This isnt limited to iOS, but to any
visual RAD tool (e.g., Visual Studio
and Delphi, just to name a few).
Visual HTML RAD environments
represent a typical borderline case:
they are used to generate (often
poorly written) code, claiming that
no HTML knowledge is needed,
and that everything can be done
visually. But no web developer
would implement a web page
without getting his or her hands
dirty: they know that manually
handling the raw HTML and CSS
will lead to more modular, more

efficient code.
So, mastering the coding of iOS
user interfaces gives you more
control over and greater awareness
of how these pieces fit together,
which raises your upper-bound as a
developer.

Pro: When Code is the Only

Option
There are also cases in which
custom iOS code is the only option
for UI design. Dynamic layouts,
where view elements are moved
around and the flow or layout
adjusts significantly based on
content, are typical examples.

Pro: Merge Conflicts

While NIBs and Storyboards
suffered significantly from merge
conflicts, code doesnt have the
same fault. All code has semantic
meaning, so resolving conflicts is
no more difficult than usual.

Con: Prototyping
Its difficult to figure out how a
layout will look until you seen it in
action. Further, you cant visually
position views and controls, so
translating layout specs into a

tangible view can take much

longer, as compared to NIBs and
Storyboards which give you an
immediate preview of how things
will render.

Con: Refactoring
Refactoring code that was written
long ago or by someone else also
becomes much more complicated:
when elements are being
positioned and animated with
custom methods and magic
numbers, debugging sessions can
become arduous.

Pro: Performance
In terms of performance,
Storyboards and NIBs are subject
to the overhead of loading and
parsing; and in the end, theyre
indirectly translated into code.
Needless to say, this doesnt
happen with code-made UIs.

Pro: Reusability
Any view implemented
programmatically can be designed
in a reusable fashion. Lets see a
few use cases:
Two or more views share a
common behavior, but they are

slightly different. A base class

and two subclasses solve the
problem elegantly.
A project has to be forked, with
the aim of creating a single
code base, but generating two
(or more) different applications,
each with specific
customizations.
The same UI design process would
be much more complicated with
NIBs and Storyboards. Template
files dont allow inheritance, and
the possible solutions are limited to
the following:
Duplicate the NIB and
Storyboard files. After that, they
have separate lives and no
relationship to the original file.
Override the look and behavior
with code, which may work in
simple cases, but can lead to
significant complication in
others. Heavy overrides with
code can also render visual
design useless and evolve into
a constant source of
headaches, e.g., when a certain
control displays one way in the
Interface Builder, but looks
completely different when the
app is running.

When to Use Code

Its often a good call to use use
custom code for iOS user interface
design when you have:
Dynamic layouts.
Views with effects, such as
rounded corners, shadows, etc.
Any case in which using NIBs
and Storyboards is complicated
or infeasible.

When Not to Use Code

In general, code-made UIs can
always be used. Theyre rarely a
bad idea, so Id put an here.
Although NIBs and Storyboards
bring some advantages to the
table, I feel theres no reasonable
downside that I would put in a list
to discourage code usage (except,
perhaps, laziness).

One Project, Multiple Tools

Storyboards, NIBs, and code are
three different tools for building iOS
user interface. Were lucky to have
them. Fanatics of programmatic UIs
probably wont take the other two
options into account: code lets you
do everything thats technically

possible, whereas the alternatives

have their limitations. For the rest of
the developers out there, the
Xcode army knife provides three
tools which can be used all at once,
in the same project, effectively.
How, you ask? However you like.
Here are some possible
approaches:
Group all related screens into
separate groups, and
implement each group with its
own distinct Storyboard.
Design non-reusable table cells
in-place with a Storyboard,
inside the table view controller.
Design reusable table cells in
NIBs to encourage reuse and
avoid repetition, but load these
NIBs through custom code.
Design custom views, controls,
and in-between objects using
NIBs.
Use code for highly dynamic
views, and more generally for
views that are not easily
implementable via Storyboards
and NIBs, while housing view
transitions in a Storyboard.
To close, lets look at one last
example that ties it all together.

A Simple Use Case

Say we want to develop a basic
messaging app with several
different views:
A list of followed friends (with a
reusable cell template to keep
the UI consistent across future
lists).
A profile detail view, composed
into separate sections
(including profile information,
stats, and a toolbar).
A list of messages sent to and
received from a friend.
A new message form.
A tag cloud view that displays
the different tags used in user
messages, with each tag
proportional in size to the
number of times its been used.
In addition, we want the views to
flow as follows:
Clicking an item in the list of
followed friends displays the
relevant friends profile details.
The profile details show the
profile name, address, statistics,
a short list of the most recent
messages, and a toolbar.
To implement this iOS app, all three

of our UI tools will come in handy,

as we can use:
A Storyboard with four view
controllers (the list, details, list
of messages, and new
message form).
A separate NIB file for the
reusable profile list cell
template.
Three separate NIB files for the
profile details view, one for
each of the separate sections
that compose it (profile details,
statistics, last three messages),
to allow for better
maintainability. These NIBs will
be instantiated as views and
then added to the view
controller.
Custom code for the tag cloud
view. This view is a typical
example of one that cannot be
designed in the Interface
Builder, neither through
StoryBoards nor NIBs. Instead,
its completely implemented
through code. In order to
maintain the Storyboards visual
flow, we choose to add an
empty view controller to the
Storyboard, implement the tag
cloud view as a standalone
view, and programmatically add
the view to the view controller.

Clearly, the view could also be

implemented inside the view
controller rather than as a
standalone view, but we keep
them separated for better
reuse.
A really basic mock-up might look
like:

With that, weve outlined the basic

construction of a reasonably
sophisticated iOS app whose core
views tie together our three primary
approaches to UI design.
Remember: theres no binary
decision to be made, as each tool
has its strengths and weaknesses.

Wrapping Up
As examined in this turtorial,
Storyboards add a noticeable
simplification to iOS UI design and
visual flow. They also eliminate

boilerplate code; but all this comes

at a price, paid in flexibility. NIBs,
meanwhile, offer more flexibility by
focusing on a single view, but with
no visual flow. The most flexible
solution, of course, is code, which
tends to be rather unfriendly and
inherently non-visual.
If this article intrigued you, I highly
recommend watching the great
debate from Ray Wenderlich, 55minutes well-spent on a discussion
of NIBs, Storyboards, and codemade UIS.
In closing, I want to emphasize one
thing: Avoid using the improper
iOS UI design tool at all costs. If a
view is not designable with a
Storyboard, or if it can be
implemented with NIBs or code in a
simpler way, dont use a
Storyboard. Similarly, if a view is not
designable using NIBs, dont use
NIBs. These rules, while simple, will
go a long way in your education as
a developer.

Hiring? Meet the Top 10 iOS

Developers for Hire in February 2015

Don't miss out.

Get the latest updates first.

Enter your email address...

Get Exclusive Updates

No spam. Just great engineering posts.

Comments

Community

Login

Share Favorite

Sort by Best

Join the discussion

Nicholas Phillips

10 months ago

Excellent piece, thanks for

sharing. I favor the storyboard as
somewhat of a scaolding tool,
though I need to split my
storyboards more! One thing I do
that might not be so popular is
actually avoid segues in the
storyboard in favor of controlling
them via code for data passing.
The 'flow' to me is suciently
communicated with the layout of
the controllers within the
storyboard.
4

Reply Share

Antonio Bello >

Nicholas Phillips
10 months ago

That's a good strategy, I

like it - of course if there
aren't too many "virtual"
segues.
By placing view
controllers properly it
won't be hard to figure
out how they are
interconnected

Reply Share

dbjdbj

10 months ago

It is probably wrong to assume

Toptal customers know what is
NIB ...
Just this one sentence would
improve usability of this article:
"A nib file is an Interface Builder
document". Two or a bit more,
will be a great help.
1

Reply Share

Charlie Marsh

Mod

> dbjdbj
10 months ago

Good call! We've added a

sentence of explanation.
Thanks for the feedback.
1

Reply

Share

Alan Chavez >

dbjdbj
10 months ago

@dbjdbj I totally agree

with you, I am a
developer but I'm not too
familiar with app
development, so I'm not
familiar with the terms
NIB are XIB. It's easy to
google the definitions and
understand what the
author is talking about,
but I agree that it's wrong
to assume that toptal
customers/readers know
o the top of their heads
what NIB/XIB means.

kgelner

Reply Share

6 days ago

Single large storyboards are

indeed bad, that is true. But it's
very easy to use multiple
storyboards within the same
app.
I think the article misses a

number of other very useful

aspects of storyboards beyond
just table view cell definition
(which is by itself a huge reason
to use storyboards):
1) Size classes. An easier way to
have a simple design slightly
tweaked between dierent sizes
of devices.
2) Split view controllers. Now
see more
Reply Share

Ivo Leko > kgelner

5 days ago

@kgelner,
I think there are few
misunderstanding here
between your comment
and post.
1.) This article is written
before iOS 8 SDK which
introduce Size Classes.
However, size classes are
still availble trough
Storyboards, XIB and
even programatically.
2.) Also part of iOS 8
SDK. If app uses native
SplitViewController
design, then definitelly
see more

Reply Share

Gautam Lakum

2 months ago

How is it dicult to use a library

built using NIBs into a project
which uses storyboard?

Min Kim

Reply Share

7 months ago

Great info. With the recent

introduction of size classes and

presentation view controller, it
really seems like apple is
pushing very hard to get us to
use the interface builder and
auto layout to build all our views
in storyboards. I'm afraid my
days of building screens using
springs and struts in code are
numbered. What are your
thoughts or recommendations?
Reply Share

kgelner > Min Kim

5 days ago

Don't forget that you can

always disable auto
layout in a storyboard
and keep using
springs/struts if you like it gets turned o or on for
the whole storyboard
though, be aware of that.
Apple is pushing both
AutoLayout and
Storyboards hard, but
AutoLayout is much more
optional... storyboards
are becoming more and
more needed over time.

Guest

Reply Share

10 months ago

@Ian: maintainability is not only a

matter of how fast you can
create a piece of functionality,
but also how easily you can
make changes. In case of code,
changes boils down to a simple
refactors in extreme cases. In UI
builder changes are only easy
when Ui builder designers made
them easy.

Reply Share

Ian Donaldson

10 months ago

It's a good article. I would only

somewhat disagree with the
statement "Theyre [codegenerated UIs] rarely a bad idea,
so Id put an (sic) here." I think
code-generated UIs are a bad
idea (or at least, not the best
idea) where the goal can be
achieved more quickly, more
simply or more understandably
in one of the other options. This
speaks to maintainability.

Reply Share

Antonio Bello > Ian

Donaldson
10 months ago

Using code only is a

matter of personal
preference - some
developers just prefer it.
Personally I use code as
last resource, when I
realize that none of the
others is a good fit. In
terms of maintainability, I
agree with what @Hubert
OG says - code, although
requiring more initial
eort, is in many cases
easier to maintain,
because sooner or later it
will happen that a change
not easily implementable
with IB must be done.
1

Reply

Share

Hubert OG > Ian

Donaldson
10 months ago

Maintainability is not only

a matter of how fast you
can create a piece of
functionality, but also
how easily you can make
changes. In case of code,
changes boils down to a

simple refactors in
extreme cases. In UI
builder changes are only
easy when Ui builder
designers made them
easy.

Reply Share

WHAT'S THIS?

ALSO ON TOPTAL

JavaScript Video
Tutorial - The
Behavior
1
comment of
a month
ago
"This" in
Visar Uruqi
JavaScript

Managing the
View State with
3 comments 2 months
React
ago

coreyitguy A

thnx for
sharing this,
very well
Reverse
explained

great
walkthrough of
React. I've
Building
HTML5
reduced
jQuery
Engineering The canvas
basedto
spaghetti
Couchsurfing.com
8
comments a month
video
6
comments
game
19
days
simple,
easyago
ago
API
to-read code
Sergey
Ezequiel
using De
Tolmachev
simone
Nice article!
Awesome
I've never
thanks for
heard about
share!
the smali
debugging, it's
interesting
Subscribe
solution!

At Toptal, we
connect the best
developers all

over the world.

Join the
Toptal
community.

TRENDING ON BLOG

HIRE A DEVELOPER
OR

APPLY AS A DEVELOPER

NAVIGATION

CONTACT

SOCIAL

Why I Decided To
Embrace Laravel

Why

Apply for
work

Facebook

Ruby Concurrency and

Parallelism: A Practical
Primer

What

Become
a partner

Google+

From the Ground Up: How

I Built the Developer's
Dream Keyboard

Team

Send us
an email

Dribbble

Using Logstash to
Streamline Email
Notifications
Shazam It! Music
Processing,
Fingerprinting, and
Recognition
Predicting Likes: Inside A
Simple Recommendation
Engine

Exclusive access to top developers

How
Clients
Community
Blog

Call
888.604.3188

Resources
Videos
Client reviews
Developer reviews
Contact
FAQ

Copyright 2010 - 2015 Toptal, LLC

Terms of Service

Privacy Policy,

Twitter
GitHub