# ViewDeck is a container you fill, not a menu you configure

> An Objective-C container view controller for iOS side menus, written to slot into an existing navigation stack rather than to define one. Here is what it does with your controllers, what it leaves entirely to you, and what its release history says about adopting it now.

**ViewDeck/ViewDeck** — GitHub describes it as An implementation of the sliding menu found in various iOS apps.. The repository metadata lists Objective-C as its primary language. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/ViewDeck/ViewDeck
- Stars: 5,251 · Forks: 950
- Language: Objective-C
- License: not declared
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/viewdeck-viewdeck

## ViewDeck hands you a container, not a menu

ViewDeck is a framework for managing side menus, and its central class is `IIViewDeckController`, a container view controller. You assign a center view controller to it plus up to two side view controllers, and the container takes over the mechanics: it makes sure your content controllers are added to the view controller hierarchy and their views to the view hierarchy when they are needed. It also plays nicely with the containers you already use, such as `UINavigationController` or `UITabBarController`, so wrapping an existing navigation stack is the normal case rather than an exception. The limit is stated once and never revisited: ViewDeck provides no configurable menus at all. There is no drawer style option, no item model, no header or footer view to fill in. You hand it three controllers, it moves them, and every visual decision stays yours.

## A nil side takes its gesture recognizers down with it

Both side view controllers are optional, and leaving one nil has a defined effect rather than a cosmetic one: no panning to that side will work, and the gesture recognizers for that side are deactivated. Removal uses the same mechanism as switching. Assign a view controller to the appropriate property and the deck switches to it in mid flight, so replacing a panel is one assignment:

```objc
// prepare view controllers
UIViewController* newController = [[UIViewController alloc] init];
self.viewDeckController.rightController = newController;
```

Setting that property to nil removes the side again. From inside a child controller, the enclosing deck is reachable through a `viewDeckController` property, the same way `UINavigationViewController` assigns itself to its children, and that property returns nil if the controller is not enclosed by one. Opening a side from there is a single call:

```objc
[self.viewDeckController openSide:IIViewDeckSideRight animated:YES];
```

By default the deck also listens for swipe gestures and opens sides interactively, so you choose per instance whether touch or your own button drives the menu.

## The Podfile line decides whether a 4.x reaches your build

CocoaPods is described as the easiest integration, and it comes down to one line. Which line you write is the decision that matters:

```ruby
pod 'ViewDeck'
pod 'ViewDeck', '~> 3.0'
```

The first form takes the latest ViewDeck version every time you run `pod update`, which means a future 4.x arrives in your build on the day it is published. The second stays inside the 3.x line: it updates to any 3.x release but will not cross to 4.x. The project follows semantic versioning, so within a major version there are no breaking changes by promise, and you may see deprecations appear on methods that are likely to go away in the next major release while they keep working until then. After either line, one import remains, in whichever class needs it: `#import <ViewDeck/ViewDeck.h>`.

## pod try builds the demo, or open the workspace in Example

To see it before committing to it, `pod try ViewDeck` creates an Xcode project that runs the demo app. The alternative is to check out the repository and run the example directly: open `ViewDeckExample.xcworkspace` in the `Example` folder and run it. That workspace is the entry point that matters, because the Example folder carries its own Podfile, a Podfile.lock, a checked in Pods directory, the ViewDeckExample.xcodeproj, the ViewDeckExample source folder and a ViewDeckExampleTests folder. The workspace is what ties those together, so opening the .xcodeproj on its own skips the pod integration it was generated from. The same structure explains the top level of the repository: ViewDeck.podspec sits next to a VERSION file, a CHANGELOG.md, a Gemfile, a Gemfile.lock and a .ruby-version, with the framework sources themselves kept in the ViewDeck directory.

## Side width comes from preferredContentSize, height does not

Controlling the size of a side panel is a single property, and it is a property UIKit already owns: `preferredContentSize`. ViewDeck respects the width from that size while making sure the height is always the height of the view deck controller itself, so a side view spans the full vertical extent whatever width you ask for. There is no separate ViewDeck knob for panel width or for a fixed or proportional drawer, which means the design decision about how much of the screen the menu covers happens in UIKit's own layout vocabulary. The stated reason for this design is that ViewDeck tries to embed into UIKit as nicely as possible and therefore leverages hooks that already exist, rather than adding parallel ones that a view controller would then have to reconcile.

## Appearance changes route through the transition animator

Customizing how a side is presented is not a matter of setting style properties on the controller. The documented route is the animator: the documentation for `-[IIViewDeckController animatorForTransitionWithContext:]` and the `IIViewDeckTransitionAnimator` class are where transition behavior is meant to change. So the open and close animations, and what the side looks like on the way in and out, live behind an object you supply instead of behind configuration you toggle. That keeps the container small and puts the work on you: someone looking for a menu appearance switch in the storyboard or in a settings screen will not find one here, because this framework deals in controllers and animation objects and expects the rest of the menu, its header and its items, to come from your own code.

## Last release 3.1.0, last push 21 July 2022

The version history deserves a look before you adopt this. The newest tagged release is 3.1.0, published on 29 December 2016, following 3.0.1 as a patch release on 2 December 2016 and 3.0.0 as a major release on 22 October 2016. Commits continued after that, since the repository was pushed to on 21 July 2022, but no release has been cut since 2016 and the repository is not archived. The requirements section says the same thing in a different register: base SDK iOS 10, deployment target iOS 8.0 or greater, and Xcode 8.x. Those are the numbers a new integrator has to reconcile with a current toolchain, and they belong next to the license statement, which says MIT with a copyright line reading 2011-2015, ViewDeck.

## The project asks for credit and names its original author

Two closing requests are part of how this project asks to be used. The credits section asks you to mention the use of the code somewhere if it ships in an app, on a website, in an about page, in the app itself, or by email or through GitHub, on the grounds that it is nice to know where the code is used. It also invites apps that use the view deck to be listed there. The special thanks section records that Tom Adriaenssen started the project and can no longer maintain it, pointing readers at his blog for the reason, and credits Samo Korosec for the logo. That handover is the background to the release dates above: a framework whose stated maintainer stepped away still gets occasional pushes, but new releases depend on someone else taking an interest.

## Conclusion

ViewDeck makes sense if you already build your screens in UIKit, want a drawer that behaves like a native container, and are willing to own the menu design, the sizing and the transition animation in your own code. Skip it for a new project if you need a configurable menu component, current iOS tooling, or a dependency that has shipped a release in the last few years. Before you commit, check the last release against your Xcode version, decide whether the Podfile constraint should be pinned to the 3.x line, and confirm that a nil side controller in your layout does what you intended.

## FAQ

### What is a viewdeck, in the ViewDeck framework?

ViewDeck is a framework for managing side menus in iOS apps, built around IIViewDeckController, a container view controller that takes a center view controller and up to two side view controllers and presents them. It supports both left and right sides, works alongside UINavigationController and UITabBarController, and can be opened by swipe gesture or programmatically.

### what is view deck, and is ViewDeck still being worked on?

The same thing: the sliding side menu found in various iOS apps, implemented as a container view controller rather than as a configurable menu component. The newest tagged release is 3.1.0 from 29 December 2016, and the repository was last pushed to on 21 July 2022 without a release since.

### How do I install ViewDeck without CocoaPods?

Download the latest ViewDeck release from the release section and move ViewDeck.framework into your Xcode project. The CocoaPods route instead adds pod 'ViewDeck' to your Podfile, then a single #import <ViewDeck/ViewDeck.h> in the class that uses it.

## Sources

- [Official README](https://github.com/ViewDeck/ViewDeck#readme)
- [Project repository](https://github.com/ViewDeck/ViewDeck)
- [Release notes](https://github.com/ViewDeck/ViewDeck/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/viewdeck-viewdeck