One of the most common implementations of menu views has been the “side drawer,” “basement,” or “side menu” made popular in apps such as Facebook and Path.

When a user taps the “Hamburger” icon to open a side menu, the main screen slides to the right (or left in some implementations) to reveal another screen below.

This works well in iOS 6 and earlier operating systems because the status bar exists in a 20pt tall area isolated from the rest of the application. In iOS 7, the status bar is overlaid on the screen below it. In other words, the app and the status bar are no longer two separate worlds, as was seen in iOS 6. This change utilizes more of the screen space but presents an interesting problem when implementing a side menu.

The Problem

Because of this new setup, designers have had to come up with a way to show a top-level navigation menu without cutting the status bar up with a layer stacked on top of another layer. If developers were to implement the sidebar in the old style they would have a vertical break through the status bar information.

Our designers at Two Toasters first encountered this challenge while helping a client, Luvocracy, redesign their app for iOS 7 before it had publicly launched. Many of the design decisions made for the iOS 6 version were easily carried over or satisfied iOS 7 design guidelines. The side menu, however, was uncharted iOS 7 territory, with no clear-cut right or wrong approach.

We saw a unique opportunity to find a clever way of implementing the side menu

Despite having no defined solution, we saw a unique opportunity to find a clever way of implementing the side menu. Working with Luvocracy, we went back to the drawing board and gathered inspiration from the design community and Apple’s native UI elements in iOS 7.

The Inspiration

The first places we turned to were design communities like Dribbble. Before iOS 7 reached the general public, designers on Dribble were playing around with side menu implementation ideas. Our designers stumbled upon a few they felt were sleek and also made good use of the many of the attributes of iOS 7, such as layering and blurring. Those projects include an iOS 7 style inspired menu from Creativedash and a Side Menu concept from Jayson Lane demonstrating layering and translucency.


While Apple didn't directly demonstrate how to implement a side menu in iOS 7, there were a few cues we picked up on in their native UI and incorporated into our final design. Namely, the zooming transition of the side menu—a transition seen all over iOS 7, from the App Switcher, to the home button, to the launching of apps.

Our Solution

From the pieces of inspiration mentioned above, we landed on the following design for the side menu.

Using an objective-C library we created named TWTSideMenuViewController (subsequently open sourced on Github), we solved the side menu animation problem by moving and scaling the main view down and away from the status bar. We also improved the scaled down view by thinking of the menu and the main view as a single view with both of them in the same visual plane. In other words, we changed the viewport to focus on different aspects of the application as if zooming in or out like the new iOS 7 app switcher.

Other Solutions

While we can’t speak for the inspiration behind other solutions, we can share some notable alternatives we found in apps updated for iOS 7. Ones we took particular note of included American Airlines, Foursquare, Mailbox, Kindle, and Vesper—all of which can be seen in action in the following video:

American Airlines

The American Airlines app follows fairly similar patterns to the Luvocracy app, but differs in how the screens animate back over top of the side menu and the speed at which it animates overall. Depending on what screen you are on before, a different animation will occur. When selecting a screen that is above your last one, the screen will animate down onto the view, likewise for an item below the current screen in the list, the screen will animate up onto the screen. The Luvocracy animation was designed to animate like a camera moving the point of view in and out, while the American Airlines app was designed as a shrinking animation.


For Foursquare the app fades out from behind the status bar and the sliding menu animates separately. Essentially, it doesn’t add anything new, instead forcing the old style to work for iOS 7.


In Mailbox the app moves the status information completely off the screen and pushes the side menu all the way to the top. An interesting solution, but maybe not the best one, as it momentarily removes all status information from the screen and may be frowned upon by Apple as it may need to access things unavailable in the public API.


Kindle had one of the more interesting solutions we came across. When accessing the menu, the sidebar slides above the main layer in the form of a glass overlay. This certainly seems inspired by Apple’s navigation to the Control Center and Notification Center in iOS7. Overall, Kindle is a great representation of a third-party app sticking to Apple’s guidelines. While we all love this approach, the designers had to be careful and make sure their design had a consistently dark background for the status bar to overlay.


The Vesper app’s sidebar animates very much the same way most apps did in iOS 6— the app remains behind the status bar. It doesn’t obscure the information on the status bar, but perhaps isn’t the ideal solution given the visual break in the status bar area.

In Conclusion

As you can see, there are numerous solutions to the implementation of the side menu in iOS 7. If you are working on an iOS 7 app and thinking about including a side menu, I hope you found inspiration in some of the apps mentioned. Please share your experiences designing for iOS 7 in the comments below.

Hamburger icon image courtesy Timothy Miller.Ad by


I have facing problem, when integrating Tabbar Controller with slide menu.
Breif of problem please check it below:

Tabbar contain 5 tab(eg. a,b,c,d,e) in slidemenu contains more than 5(a,b,c,d,e,f,g,h,i).so we have facing problem when tap on g from a, i navigate on g controller, but i again tab on a from g cannot be push there.

If anyone have solution for that please suggest me.


Apple does not recommend Hamburger side menus. Tabs are still the best solution. Why: 1. That people who use their app don’t switch to different sections very frequently when they use this menu. 2. It takes at least twice as many taps to change sections. Something that should be very easy and fluid is made more difficult. 3. And finally, the downside of being able to show a lot of options is that you can show a lot of options.

I agree with cj in that hamburger menus can be done well and they can be done poorly, regardless of OS. The issues Rob points out are really usability issues looked at in isolation. You have to look at the overall experience you are trying to design and then judge whether the hamburger menu helps or degrades that experience.

To Rob's points:

1. Infrequent switching of sections might be a good thing if the sections in the hamburger menu are for infrequent use cases (like cj said). Who cares if they're not accessing the Settings every day?

2. As far as twice as many taps... This goes with the previous point, if the users aren't accessing the items in the menu often, why does it matter? You have to weigh "twice as many taps" (a 2 year old can tap twice) against cluttering the UI with options seldom used (it's so painful when apps have too many options).

3. And showing a lot of options can be bad, but that's not a characteristic of the hamburger menu itself. The designer can put 2 items in the menu or 20 or 200 or 0. That's a different issue altogether.

Whenever people judge design decisions to be wrong because they break Android or iOS interface guidelines, I basically say that if you are following a rigid book of rules to design your UI, odds are you aren't thinking about the user experience. You're basically letting Apple or Android dictate your app's user experience with a template they created without ever having seen your app. I know this isn't what Rob is suggesting, it's just a side thought. Great artists learn the rules of their art well and once they've developed mastery, they begin to break the rules strategically to produce great art. If you are just following rules, chances are you are not creating great art.

The argument against the hamburger menu is all well and good, but it can't be a knee jerk reflex response to all situations. There are some situations where I believe the 'hamburger' works:

If you don't need to provide access to all capabilities at the same level, it can make sense to 'hide' some of them rather than expose them at the same level as other primary functions, using up real estate. If an app has one primary goal, but some items which might need occasional setting or tweaking, I like using the hamburger icon. For example in some camera apps...99% of my time is spent just taking a picture...but if I want a special effect, I'm left trying to figure out the clever way the designer hid the menu, IF options are even there. The hamburger, like it or not, has become a fairly pervasive and understandable location to find more 'stuff' in an app, and I'd expect to find 'more' in there.

Next is when a number of high level options are available, but once in an option a user is likely to spend most of their time interacting's unlikely they will even want to change high level tasks very often, if at all. Their goal is one task, they want to go in and get it done. To get those lower level tasks done, contextual navigation within the task becomes available. Showing both tabs and contextual navigation suddenly uses up quite a bit of real estate.

Finally, another situation where I've found it useful it for apps which need to flexibly scale. If users have varying permissions and are granted varying numbers of tasks, I have found the ability to grow or shrink a list (under the slider menu) easier than trying to define all the posssible permutations of tabs within a tab bar...which might end up with 1 or 10 functions on it, depending on user permissions.

So in general the hamburer icon isn't a great choice when all tasks are equal in an app or RWD page or of you want to encourage exploration around the app, but in some situations, I'd argue for keeping it as an option in the toolbox.

I have seen so many terms used for this form of navigation - it's starting to get extremely confusing.

I've never heard of a "basement" or "side drawer". The most common term I see used (and the one that probably best describes it) is "off canvas" navigation. Difficult to confuse and not in any way mistakenly related to furniture.

As for the Icon, "Hamburger" is probably the most commonly used term in the community, closely followed by "Navicon".

Lovely article, I really like the design you've chosen in the end and its great to see the research you've done. Let's just stop all the silly terms we're throwing around to describe something that in fact is a very simple approach to navigation.

I personally find the side menu's pretty annoying. A lot of the time when scrolling down I grab te screen to close to the edge and the side menu pops up. 90% of the time im unsin an app i use the up/down scroll and not any side menu's, seems pretty illogic to dedicate 10% of screen touch space on eifher side to these menu's.

Very nice...Does this work for IOS 6? Can it be modified to work for both sides?

How did this design perform in user testing, and have you received any feedback since launch that would impact the next version of the design?

Why the hell are people down voting this comment? Have they forgotten about the 'user' part of UX?

I'm the author of ECSlidingViewController, a popular open source solution for side menus on iOS. The latest version for iOS 7 supports custom transitions, and I implemented some of the examples from this article.

See the examples here:

I'd have to agree with Emmanuel on this, but not because of the reason he stated.. although we are probably thinking about it the same way. The zoom out method is currently the navigational paradigm Apple is using for fast app switching, or to close apps (you can drag the tile with an "upward" swipe to close the app, or you can close (2) apps with a 2-finger upward swipe.. or even (3) apps with a (3) finger upward swipe after fast app switching is triggered by a double tap on the home button). Because Apple is using this feature in this way, it would not make sense to use that feature for in-app navigation. It not the same as saying.. "In mail Apple uses the < "Label" to go back so I can use < "Label" to go back in my app. That is in-app navigation.

I have my own preferences of how to resolve this, which does not involve using a menu animating from the left or right. In my opinion, Facebook's UI has taken many steps backwards. They added some cool functionality with the chat/drag/close feature but messed it up with their left/right slide menu system. Their latest UI corrected the left/right menu issue (somewhat), but the navigation at all corners is not the most elegant UI for a mobile device. It's now too complicated with buttons all around the screen. I have found myself having to re-train and re-learn the app to find some menus/sections...

With all due respect, I think the solution you have put forward is not very graceful, even next to Apple's whacked idea of taking the status bar information out of sight - while, to me, the solution used in the Vesper app is about the most convenient compromise I can think of.

This to say tho, Apple's use of the Z index should not be used for anything but a very high-level guideline, their own use of it varies a lot and isn't consistent. Furthermore, it's almost as if they put that forward because it's pretty, but there's no consensus on how to use it.

My first reaction to this proposed solution is that while I do think it's visually appealing (that GIF example is pretty sleek), the UX is somewhat disjointed. The separation of body content from the menu (primary nav items in their example) is too vast. The delight of a side menu, in my opinion, is having the safety and convenience of additional control (navigation), without departing from the content body; I feel this approach is decapitating the navigation.

The use of depth in iOS7 is appropriate in the context of folders for example, where it conveys a hierarchy – grouped apps are within or "below" their group label. I’m not convinced that an app lives “inside” the navigation, but rather, I see navigation as a filter or fast-track to something in an app or site. It can accompany (and on the web usually sits at the top for convenience), but shouldn’t necessarily supersede content.

The Foursquare and Kindle examples provided are more agreeable to me. I’ll have to try out American Airlines or any other free app that has this spacey side menu to really decide, but my UX gut tells me this is a little too much exploration risk.

Id argue that the best alternative is the one that Vesper uses.
The small break is nothing but layers intersecting in Z-space, which is completely fine with the OS design paradigm.

The zoom out version that you seem to like is flat out wrong. Why? Well if you see the the app as a part of the OS context - the user usually zooms into a folder and then then zooms into an app. The zoom out navigation first of all zooms the wrong direction (out, instead of in) and then presents a menu in a space that is above (in terms of Z-index) the app itself.

Example flow:
1. Open folder (Zoom in)
2. Start app (Zoom in)
3. Press navigation (Zoom out)

I find this confusing and unnatural because the spatial flow is broken.

The three planes that a user navigates through are:
1. OS
2. Folder
3. App

The zoom out navigation makes the user feel he/she is somewhere between the folder/OS and the app.

Great article. Going to keep this in mind for the next versions of the Couchsurfing app :)

Thanks for sharing!