Category Archives: Podcast

How to load UIStoryboards depending on screen height in iOS

A while ago I’ve written an article about how to load different storyboards depending on the screen size of an iOS device. Back in those days (2013) it was all a bit simpler than it is today, and I looked into it mainly because I loathed Auto Layout so much.

I felt it was time for an update, so here it is!

Things haven’t gotten any easier in iOS, because currently we have the following 5 screen sizes to deal with:

  • iPhone 6 Plus: 736×414 @3x
  • iPhone 6: 667×375 @3x
  • iPhone 5s: 568×320 @2x
  • iPhone 4s: 480×320 @2x
  • all iPads: 1024×768 @1x / @2x

It’s very difficult to make a UI look nice on all devices with a single UIStoryboard, and in the above video I’m showing you an alternative: design a completely different storyboard for each screen size.

The upkeep of such an app will be a little more complex, but it puts us in full control of the user experience, and not some compromise that sounds good in the Apple presentation (and sucks in reality).

In principle, the following steps are involved:

  • design various storyboards
  • detect the current device’s screen height
  • load the appropriate storyboard
  • make it “key and visible”

Detecting the screen size

If your app is set to “auto-rotate” (i.e. both portrait and landscape modes, or portrait only), the screen height will detect the longer side of the screen. This is true even if the app is started in landscape mode. Determining screen height can be done like this:

int screenHeight = [UIScreen mainScreen].bounds.size.height;
NSLog(@"Screen Height is %i", screenHeight);

Note that if you set your app to “landscape only” mode, the height parameter will return the shorter side of the screen – in which case, bounds.size.width to determine the longer portion of the screen. Thanks to Johan Grip for bringing this to my attention!

iOS 7 compatibility

Note that the screen size is orientation dependant since iOS 8 – previous versions did not take this into a account. If you must support iOS 7 and earlier it gets a lot more complicated (and I won’t cover this here – sorry).

However, this Stack Overflow discussion may help you in that case:

Loading the correct UIStoryboard

With this handy integer in place, we can build a switch statement to react according to the screen height. I’m using the following method that returns my desired storyboard in my AppDelegate implementation file.

If you’re not worried about each single size, feel free to write a shorter if/then/else type method.


- (UIStoryboard *)grabStoryboard {
    // determine screen size
    int screenHeight = [UIScreen mainScreen].bounds.size.height;
    UIStoryboard *storyboard;
    switch (screenHeight) {
            // iPhone 4s
        case 480:
            storyboard = [UIStoryboard storyboardWithName:@"Main-4s" bundle:nil];
            // iPhone 5s
            case 568:
            storyboard = [UIStoryboard storyboardWithName:@"Main-5s" bundle:nil];
            // iPhone 6
            case 667:
            storyboard = [UIStoryboard storyboardWithName:@"Main-6" bundle:nil];
            // iPhone 6 Plus
            case 736:
            storyboard = [UIStoryboard storyboardWithName:@"Main-6-Plus" bundle:nil];
            // it's an iPad
            storyboard = [UIStoryboard storyboardWithName:@"Main" bundle:nil];
    return storyboard;


Displaying the storyboard

Inside our AppDelegate method didFinishLaunchingWithOptions, we’ll call the above method and grab the storyboard we need. To make it show up, we need to load it as the window’s root view controller and declare it “key and visible”. This is akin to the old-style way of making things appear on our iOS screens.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // grab correct storyboard depending on screen height
    UIStoryboard *storyboard = [self grabStoryboard];
    // display storyboard
    self.window.rootViewController = [storyboard instantiateInitialViewController];
    [self.window makeKeyAndVisible];
    return YES;

Note that using this approach will override whatever storyboard is declared in your target (under General – Deployment Info – Main Interface).


Demo Project

I’ve updated this project on GitHub, it shows exactly what I’m building in the screencast. Play and enjoy 🙂

How to build a UICollectionView in iOS 8

In this video I’ll show you how to build a UICollectionView from scratch in Xcode 6. The class is available for both iPhone and iPad since iOS 6. If you know how to build a UITableView then building a UICollectionView will be familiar to you.

I’ll start with a single view application, delete the ViewController class and start fresh with a UICollectionViewController. Next I’ll add a custom class for the UICollectionViewController and UICollectionViewCell and then we’ll hook it up in the storyboard.

By the end we’ll have a simple Collection View App which allows multiple selections. I’m going to use this project to build on with other features in the future.

Custom CollectionViewController Class

The template provides a few good starting points, but they need to be changed to work. First there’s the cell’s reuse identifier, conveniently added as a static at the top of the implementation file. It’s there so we only need to change this once in the file. Replace it with your own, and remember to make the same change in the storyboard:

static NSString * const reuseIdentifier = @"Cell";

Screen Shot 2015-02-03 at 11.11.03

Next up is the viewDidLoad method. To make dequeuing cells easier, Apple have provided a registerClass method. If you don’t add your custom cell here, nothing will appear when you run the app. I found that simply commenting out the line works just as well.

The reason they provide this is so that the dequeueCellWithIdendifier method knows which custom cell class to instantiate (prior to iOS 6 it returned nil, but that check is no longer necessary).

I’m also adding multiple selections here, something that cannot be done in the storyboard.

- (void)viewDidLoad {

    [super viewDidLoad];
    // EVIL: Register your own cell class (or comment this out)
    [self.collectionView registerClass:[YourCustomCell class] forCellWithReuseIdentifier:reuseIdentifier];
    // allow multiple selections
    self.collectionView.allowsMultipleSelection = YES;
    self.collectionView.allowsSelection = YES;


Much like with UITableViews, we need to provide the number of sections, as well as the number of items in each section:

- (NSInteger)numberOfSectionsInCollectionView:(UICollectionView *)collectionView {

    return 1;

- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section {

    return self.cellData.count;

If you don’t provide the sections method, it is assumed that you have one section. Usually we’d have some data and would return a count of how many items we have rather than fixed values here.

We also need to provide what’s in each cell. Here we can add data to labels, populate UIImageViews and many other things our collection view cells may need:

- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath {
    MyCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:reuseIdentifier forIndexPath:indexPath];
    cell.textLabel.text = [self.cellData objectAtIndex:indexPath.row];

    return cell;


With UITableViews there were four styles of table cells we could choose from out of the box. A collection view cell on the other hand is completely blank, and we’re expected to provide everything inside it. This means we need a custom UICollectionViewCell class for our project.

Anything we drag into the prototype cell in the storyboard can be hooked up to that custom class and the configured in the above cellForItemAtIndexPath method. Make sure any outlets are defined in the cell’s header file.

Cell Selections

Collection view cells have several views layered on top of each other. At the bottom is the backgroundView and the selectedBackgroundView. These are not configured by default, but if we add our own views here, the cell knows how display selections.

Above the background/selectedBackgroundView is the contentView, and on top of the contentView is where we can add out own outlets (like labels and images). If we leave the contentView’s background colour transparent, the views underneath will be visible, and hence selections are visible too.

Here’s how to configure our custom cell with two colours for selection and deselection. I’m doing this in awakeFromNib, which is called as soon as our cell is instantiated:

- (void)awakeFromNib {
    // standard background (deselected)
    UIView *bgView = [[UIView alloc]initWithFrame:self.bounds];
    self.backgroundView = bgView;
    self.backgroundView.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"blue"]];
    // selected background
    UIView *selectedView = [[UIView alloc]initWithFrame:self.bounds];
    self.selectedBackgroundView = selectedView;
    self.selectedBackgroundView.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"pink"]];

Demo Project

The code I’m writing here is available as a demo project on GitHub:

How to create an Unwind Segue in iOS 8

The Unwind Segue was introduced in iOS 6 to make retrieving data from a dismissed view controller easier. A regular Segue allows us to send data from one view controller to another, but it’s not easy to bring data back if the user has changed or added details in that view controller. That’s where an Unwind Segue comes in.

Part 1: Code

Here’s how to create one. I’m assuming we have two view controllers at our disposal, ViewController1 has initiated a standard segue, maybe passing some data. The user then changes the data, and upon saving the data, ViewController2 is dismissed and we’re going back to ViewController1.

So in ViewController1 we’ll add a method we can use as an Unwind Segue, which we later hook up in the storyboard to the Exit object. Here’s that method:

- (IBAction)backToTheStart:(UIStoryboardSegue *)segue {
    // grab a reference
    ViewController2 *viewController2 = segue.sourceViewController;
    // access public properties from ViewController2 here

It doesn’t matter what the method is called, just as long as it resides in ViewController1, in which you’ve imported the ViewController2.h file. What DOES matter however that our method is an IBAction and takes a UIStoryboardSegue as a parameter – otherwise Interface builder won’t recognise it, and you won’t be able to drag to the Exit object later.

Meanwhile, in ViewController2, we can make use of the following method which is often provided as a stub in new view controller classes:

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
    // do any preparation here when the segue is called

prepareForSegue is called just before the unwind segue (or any segue for that matter) is about to begin. You may want to read out a text field or any other values and add it to the object or variable that ViewController1 needs access to.

Part 2: Hooking up the Storyboard

With our code in place, control-drag from the button you’d like to use for initiating the segue. You can hook up multiple buttons to the same unwind segue.

Control-drag each button to the Exit object (in ViewController2):

Screen Shot 2015-01-29 at 12.00.49

As soon as the button is pressed, the unwind code in ViewController1 is executed and ViewController2 is dismissed.

Demo Project

I’ve put together a quick demo project on GitHub which is the code I’m creating the screencast above:

Further Reading

Core Dara Nugget #1: How to speak Core Data

In this screencast I’ll talk you through the lingo of Core Data: those scary classes and expressions that you’ll frequently come across. In fact, this is the start of a new series:

Core Data Nuggets are bite-sized chunks about the framework. Dip in and out or watch them all in a row and learn how this super complicated framework works and what it has to offer.

Don’t get overwhelmed by Core Data: it wants to help – it’s just not designed with humans in mind.

As always, enjoy!

Creating an In-App Purchase in iOS 7 and Xcode 5.1

In this 7-part screencast series I’ll show you how to create an In-App Purchase in iOS 7 with Xcode 5.1.

The course will run you through everything from setting up your product in iTunes Connect, creating a custom shop class for easy re-use, making “first contact” with the App Store and how to deal with its responses. I’ll explain the overall concept in Part 1.

Parts 1+2 are free to watch. The rest is for members only. Sign up for full access, or you can purchase the course from Vimeo On Demand.

Part 2 describes how to setup your your app for use with In-App purchases. We’ll setup a new App ID in Member Center, and create a product in iTunes Connect.

This content is for members only.

I’m following my earlier two articles almost to the letter, here they are for reference:

How to use Popovers on iPad

In this series I’ll show you how to create Popovers on iPad. They’re fairly easy to create once you get the hang of the inner workings of the UIPopoverController.

I’ll show you how to create basic Popover in code and in your Storyboard, and we’ll discuss how you can retrieve data from a Popover when it’s dismissed. We’ll do this with a simple UIDatePicker. In the last video I’ll demonstrate how you can pick images from the camera roll using the UImagePickerController with a Popover – which is how you’re meant to do it on iPad.

The series contains three videos in total. The first one is “free to air”, and the other two are for members only.


This content is for members only.