UIScrollView that adapts to fit content

So I have to say, I have had some difficulty getting UIScrollView to play nicely with Autolayout. There are posts such as here that look to be the solution to many people’s problems. I didn’t really get it working for me.

So I thought I’d write what did. To outline what I’d like to do, I’d like to avoid re-purposing UITableView and cells to display content. It is a lot more boilerplate and it adds complexity. That said, you can have content that is infinitely long and it will be displayed efficiently.

Basically I’d like to create a content view that is potentially larger or shorter than the iPhone screen. Using a UIScrollView is a good candidate for this.

I’ll just get to the summary of the approach. I’ll create a contentView that has its width pinned to the scroll view’s (ultimately the screen’s) width, pinned at the top, but be flexible to allow this contentView to be as large or as small as it needs to be (for example because you have a text view).

I did this by making sure that I pin the scrollView to the superview’s edges, then I add a contentView to the scrollView and pin its top, left, right edges, and pin its width to be the scrollView’s width.

Assuming the component in my contentView is a UITextView, and thus has content that is dynamic, whenever I add this to my storyboard, I make sure that scrolling is disabled on the text view. Then I add an outlet for a NSLayoutConstraint for the text view’s height. I use the delegate callback of UITextView (textViewDidChange) to calculate the ideal height of the text view, then use that height to set the constant of the layout constraint I just mentioned. This resizes the text view to its dynamic content, and thus the size of the contentView.

    func textViewDidChange(_ textView: UITextView) {
    func resizeTextViewToFitContent() {
        self.textViewHeightConstraint.constant = self.textView.sizeThatFits(CGSize(width: self.textView.frame.size.width, height: CGFloat.greatestFiniteMagnitude)).height

If I set this up in interface builder and don’t pin the bottom of the contentView, I will get an error about the scrollView having ambiguous content height. This can be suppressed by setting the Ambiguity to “never verify”.

Now all I need is a custom scroll view that will update its content size whenever the contentView changes size:

class ContentScrollView: UIScrollView {
    override func layoutSubviews() {
        // alternatively, you can set an IBOutlet weak var contentView: UIView! instead of assuming one subview.
        if let contentView = self.subviews.first {
            self.contentSize = contentView.bounds.size

And that’s it! How to make dynamic content be scrollable where required. You’ll notice that if your contentSize is less than the screen height, no scrolling, no scroll indicators; you’ll never even know it’s embedded in a scrollView.

To summarize:

  1. Add UIScrollView inside the main view in Storyboard
  2. Add UIView inside the UIScrollView
  3. Add UITextView inside the UIView (the view added in step 2)
  4. Make sure “Scrolling Enabled” of UITextView is unchecked
  5. Add 4 constraints (leading, trailing, top, bottom) on UIScrollView
  6. Add 3 constraints (leading, trailing, top) on UIView (the view added in step 2)
  7. Add “Width Equally” constraint on UIView (the view added in step 2) and the main view
  8. Add 5 constraints (leading, trailing, top, bottom, height) on UITextView. After this step you shouldn’t get any errors and warnings on constraints.
  9. Add UITextView height constraint IBOutlet on the ViewController. @IBOutlet weak var textViewHeightConstraint: NSLayoutConstraint! and connect it in Storyboard
  10. Make your view controller conform to UITextViewDelegate and implement methods listed above, and make sure the text view’s delegate is this view controller.
  11. If you set the text programmatically, call resizeTextViewToFitContent
  12. In your storyboard, for the scrollView, set Ambiguity to “never verify”
  13. Make sure the UIScrollView is the ContentScrollView given above.

Nostalgia for old iOS

This sounds silly, but I kind of miss iOS development in the days before iOS 7. I kind of have this feeling the entire ecosystem has become less stable, less reliable, not as clear in its vision, and basically less easy than it used to be.

Don’t believe me?  Just look at all the different ways Apple has tried to solve Autorotation.  That API has just changed so many times.

The thing that actually inspired this post is actually not related to nostalgia because it’s an issue that has always been less than straightforward.  All I want to do is tell my navigation bar that the back button should have no text (just the arrow).

There are all sorts of posts on this, but none of them actually work.  Change the title of the back button in viewWillAppear: ??  Nope.  Override the navigationItem variable and set its back button to an item with no title?  Nope….

Just sometimes simple things in iOS are annoyingly not that way.

HSHTMLImageRenderer !

So with permission of my current client (for whom I wrote the original code), I’m able to open source this component for all to use. I’m delighted I can do that because I think this component can be of good use to people.

HSHTMLImageRenderer is a way to be able to render HTML offscreen to images that can be stored in a cache.  It’s useful when you have many layout elements whose content is a small bit HTML that could be complicated and unsuitable for a UILabel, and it’s not feasible to have numerous instances of UIWebView everywhere.

Have a look. It’s over on my github page.

UINavigationBar that Scrolls Away (Revised)

On this blog one of my most searched for posts is the one about a UINavigationBar that scrolls away.

That was written a while back.  I’ve recently had to revisit this topic again, so I thought I’d revise my implementation, which aims to remove many caveats and just make it easy to drop into your code and you’re done.

So I redid that code and made it slightly less hacky, and implemented it as a category on UIVIewController. If it doesn’t work for you the only thing I can think of are the new properties on UIViewController that pertain to layout. Mine had automaticallyAdjustScrollViewInsets to YES, and extend edges under top bars.

//  UIViewController+ScrollyNavBar.h
//  Created by Stephen O'Connor on 24/03/16.
//  MIT License

 How to use this:
 import this into your (probably) table view controller
 make sure you set HS_navigationBarLayerDefaultPosition in viewDidLoad:
 self.HS_navigationBarLayerDefaultPosition = self.navigationController.navigationBar.layer.position;
 optionally set HS_scrollingNavigationBarThresholdHeight if you want to be able to scroll a bit before 
 the nav bar starts scrolling with it.  A typical use case would be if you want the bar to start
 scrolling with your first table view section, and not with the tableViewHeader.
 in viewWillAppear:, call:
 - (void)HS_updateNavigationBarPositionUsingScrollView:(UIScrollView*)scroller
 and, assuming your table view controller is still the UITableView's delegate, it's also
 a scroll view delegate.  In -scrollViewDidScroll:, call:
 - (void)HS_updateNavigationBarPositionUsingScrollView:(UIScrollView*)scroller
 as well.

#import <UIKit/UIKit.h>

@interface UIViewController (ScrollyNavBar)

@property (nonatomic, assign) CGFloat HS_scrollingNavigationBarThresholdHeight;  // defaults to 0.  I.e. think about tableViewHeader's height
@property (nonatomic, assign) CGPoint HS_navigationBarLayerDefaultPosition;

- (void)HS_updateNavigationBarPositionUsingScrollView:(UIScrollView*)scroller;


Then then .m file:

// some theoretical knowledge here:  http://nshipster.com/associated-objects/

#import "UIViewController+ScrollyNavBar.h"
#import <objc/runtime.h>

@implementation UIViewController (ScrollyNavBar)

@dynamic HS_scrollingNavigationBarThresholdHeight;
@dynamic HS_navigationBarLayerDefaultPosition;

- (void)setHS_navigationBarLayerDefaultPosition:(CGPoint)HS_navigationBarLayerDefaultPosition {
                             [NSValue valueWithCGPoint:HS_navigationBarLayerDefaultPosition],

- (CGPoint)HS_navigationBarLayerDefaultPosition {
    return [(NSValue*)objc_getAssociatedObject(self, @selector(HS_navigationBarLayerDefaultPosition)) CGPointValue];

- (void)setHS_scrollingNavigationBarThresholdHeight:(CGFloat)HS_scrollingNavigationBarThresholdHeight {

- (CGFloat)HS_scrollingNavigationBarThresholdHeight {
    return [(NSNumber*)objc_getAssociatedObject(self, @selector(HS_scrollingNavigationBarThresholdHeight)) floatValue];

- (void)HS_updateNavigationBarPositionUsingScrollView:(UIScrollView*)scroller
    // get the navigation bar's underlying CALayer object
    CALayer *layer = self.navigationController.navigationBar.layer;
    CGFloat contentOffsetY = scroller.contentOffset.y;
    CGPoint defaultBarPosition = self.HS_navigationBarLayerDefaultPosition;
    CGFloat scrollingThresholdHeight = self.HS_scrollingNavigationBarThresholdHeight;
    // if the scrolling is not at the top and has passed the threshold, then set the navigationBar layer's position accordingly.
    if (contentOffsetY > -scroller.contentInset.top + scrollingThresholdHeight) {
        CGPoint newPos;
        newPos.x = layer.position.x;
        newPos.y = defaultBarPosition.y;
        newPos.y = newPos.y - MIN(contentOffsetY + scroller.contentInset.top - scrollingThresholdHeight, scroller.contentInset.top);
        layer.position = newPos;
        layer.position = defaultBarPosition;  // otherwise we are at the top and the navigation bar should be seen as if it can't scroll away.


Boom! Pretty straightforward.

Note however, that I don’t really recommend this functionality because it’s prone to error, and it’s sort of hacking UINavigationBar.  It has a few related consequences:

  • UITableView section headers will still ‘stick’ to the bottom of the now invisible navigation bar.
  • You must use a translucent UINavigationBar for this to really work properly.

Now, for the first of those two points, I don’t have a solution and anyone who does, please leave me something in the comments.

For the second one, if you read the API docs of UINavigationBar closely, you’ll see:

@property(nonatomic, assign, getter=isTranslucent) BOOL translucent


The default value is YES. If the navigation bar has a custom background image, the default is YES if any pixel of the image has an alpha value of less than 1.0, and NO otherwise.

So, with a little trickery, we can just change the Class on a UINavigationController to use a custom UINavigationBar class that sets an *almost* opaque image as the background image any time you change the barTintColor:

#import "UIImage+NotQuiteOpaque.h"

@interface HSNavigationBar : UINavigationBar

@implementation HSNavigationBar

- (void)awakeFromNib
    [self setBarTintColor:self.barTintColor];

- (void)setTranslucent:(BOOL)translucent
    NSLog(@"This HSNavigationBar must remain translucent!");
    [super setTranslucent:YES];

- (void)setBarTintColor:(UIColor *)barTintColor
    UIImage *bgImage = [UIImage HS_stretchableImageWithColor:barTintColor];
    [self setBackgroundImage:bgImage forBarMetrics:UIBarMetricsDefault];


And you’ll see here that the real trick is this category on UIImage that generates a stretchable image of the color specified, but it sets the top right corner’s pixel alpha value to 0.99. I assume that nobody will notice that slight translucency in one pixel at the top right of the screen.

@implementation UIImage (NotQuiteOpaque)

+ (UIImage*)HS_stretchableImageWithColor:(UIColor *)color
    UIImage *result;
    CGSize size = {5,5};
    CGFloat scale = 1;
    CGFloat width = size.width * scale;
    CGFloat height = size.height * scale;
    CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
    size_t bitsPerComponent = 8;
    size_t bytesPerPixel    = 4;
    size_t bytesPerRow      = (width * bitsPerComponent * bytesPerPixel + 7) / 8;
    size_t dataSize         = bytesPerRow * height;
    unsigned char *data = malloc(dataSize);
    memset(data, 0, dataSize);
    CGContextRef context = CGBitmapContextCreate(data, width, height,
                                                 bytesPerRow, colorSpace,
                                                 (CGBitmapInfo)kCGImageAlphaPremultipliedLast | kCGBitmapByteOrder32Big);
    CGFloat r, g, b, a;
    UIColor *colorAtPixel = color;
    r = 0, g = 0, b = 0, a = 0;
    for (int x = 0; x < (int)width; x++)
        for (int y = 0; y < (int)height; y++)
            if (x == (int)width - 1 && y == 0) {
                colorAtPixel = [color colorWithAlphaComponent:0.99f];  // top right
            [colorAtPixel getRed:&r green:&g blue:&b alpha:&a];
            int byteIndex = (int)((bytesPerRow * y) + x * bytesPerPixel);
            data[byteIndex + 0] = (int)roundf(r * 255);    // R
            data[byteIndex + 1] = (int)roundf(g * 255);  // G
            data[byteIndex + 2] = (int)roundf(b * 255);  // B
            data[byteIndex + 3] = (int)roundf(a * 255);  // A
            colorAtPixel = color;
    CGImageRef imageRef = CGBitmapContextCreateImage(context);
    result = [UIImage imageWithCGImage:imageRef scale:scale orientation:UIImageOrientationUp];

    result = [result resizableImageWithCapInsets:UIEdgeInsetsMake(2, 2, 2, 2) resizingMode:UIImageResizingModeStretch];
    return result;


So, there it is. It works, yes, but not perfectly, and the whole thing feels a bit hacky. I wonder if there’s a better way to do this, or if in the future Apple will start to update this code. Seeing as we see collapsing address bars on WebView controllers like in Safari, perhaps they might abstract this further to support UINavigationControllers.

UITableView with Animating Section Header

So, I’ve been scratching my head on an issue I’ve been having:

I want to have a UITableView with a section header, because I want it to stick to the top of the screen while scrolling.  The thing is, it’s supposed to have a search bar that expands when you enter “search mode”.

What you see in the video is my prototype.  Tapping a table cell is supposed to toggle this search mode on and off.  In the video above you see that that table cell layout updates and expands, but the section header seems to be “one click behind” and expands when the cell layouts push up because they think the header is shorter.

This behaviour happened via the standard posts on stack overflow.  Here, for example.

Now, perhaps my issue is because I also have a stretchy section header, which I based off of this post:

Anyway, I found the solution involved a slightly complicated solution, but once it’s in place, there’s little to know (i, ii, iii, …) and do (A, B, C, D, …) :

i)  I assume you will have one section on your table view
A) Define an associated view on your view controller, which will be your “expandableHeaderView” (more on the specifics later)
Screenshot 2016-03-17 14.03.04

B) Define your class to have such properties and methods:

@interface QLExpandableSectionHeaderTableViewController : UITableViewController

@property (nonatomic, assign) IBInspectable NSInteger expandableSectionHeaderInactiveHeight;  // defaults to 44
@property (nonatomic, assign) IBInspectable NSInteger expandableSectionHeaderActiveHeight; // defaults to 88

@property (nonatomic, strong) IBOutlet UIView *expandableHeaderView;

@property (nonatomic, readwrite, getter=isHeaderExpanded) BOOL headerExpanded;

- (void)setSectionHeaderHeightExpanded:(BOOL)expanded animated:(BOOL)animated;


@implementation QLExpandableSectionHeaderTableViewController

- (instancetype)initWithCoder:(NSCoder *)aDecoder
    self = [super initWithCoder:aDecoder];
    if (self) {
        _expandableSectionHeaderInactiveHeight = 44.f;
        _expandableSectionHeaderActiveHeight = 88.0f;
    return self;

- (void)viewDidLoad {
    [super viewDidLoad];
    if (!self.expandableHeaderView) {
        NSLog(@"WARNING: You haven't provided an associated header view you want to use when toggling section header height!");
        // this has to be clear, since animation doesn't quite work as desired.
        self.expandableHeaderView.backgroundColor = [UIColor clearColor];

- (CGFloat)tableView:(UITableView *)tableView heightForHeaderInSection:(NSInteger)section
    if (section == 0) {
        if (self.isHeaderExpanded) {
            return self.expandableSectionHeaderActiveHeight;
        return self.expandableSectionHeaderInactiveHeight;
    return 0;

- (UIView*)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section
    if (section == 0) {
        if (self.expandableHeaderView) {
            return self.expandableHeaderView;
            // will probably never get used
            UIView *header = [UIView new];
            header.backgroundColor = [UIColor redColor];
            header.frame = CGRectMake(0, 0, self.tableView.bounds.size.width, self.expandableSectionHeaderInactiveHeight);
            return header;

    return nil;

- (void)toggleSectionHeader:(UIButton*)button
    if (self.isHeaderExpanded) {
        [self setSectionHeaderHeightExpanded:NO animated:YES];
    else {
        [self setSectionHeaderHeightExpanded:YES animated:YES];

- (void)setSectionHeaderHeightExpanded:(BOOL)expanded animated:(BOOL)animated
    if (self.isHeaderExpanded && expanded) {
        return;  // nothing to do!
    self.headerExpanded = expanded;
    [self.tableView beginUpdates];
    [self.tableView endUpdates];
    //NSLog(@"%@", self.searchHeaderView.constraints);
    __block NSLayoutConstraint *headerHeightConstraint = nil;
    [self.expandableHeaderView.constraints enumerateObjectsUsingBlock:^(__kindof NSLayoutConstraint * _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
        // I determined this name by logging the self.searchHeaderView.constraints and noticed
        // it had a constant value that was one of my searchBar(In)activeHeight values.
        if ([obj.identifier isEqualToString:@"UIView-Encapsulated-Layout-Height"]) {
            headerHeightConstraint = obj;
            *stop = YES;
    CGFloat newHeight = expanded ? self.expandableSectionHeaderActiveHeight : self.expandableSectionHeaderInactiveHeight;
    headerHeightConstraint.constant = newHeight;
    // after the animation completes, the expandableHeaderView's frame doesn't change until a layout update
    // , which only happens after you start scrolling.  This will ensure it has the right size as well.
    CGRect frame = self.expandableHeaderView.frame;
    frame.size.height = newHeight;
    [UIView animateWithDuration:animated ? 0.3f : 0.0f
                         [self.tableView layoutIfNeeded];
                     } completion:^(BOOL finished) {
                         self.expandableHeaderView.frame = frame;

The code above will handle animation.  There is still some weirdness happening on the UIKit side of things, because the the header view’s subviews animate according to auto-layout, but the self.expandableHeaderView doesn’t visually change size until a layout update occurs.  And this only occurs once you start scrolling.  So we set that frame to the size it’s supposed to have, and that sorts it all out. As a result, we have to set the self.expandableHeaderView.backgroundColor = [UIColor clearColor];

And that solved the problem! It’s a bit hacky, but I found no other way to accomplish this that isn’t THAT ugly.

And here’s the result:

Storyboard Segues that don’t animate

It’s a bit of a hack as one can’t seem to set this easily in code, but perhaps you have a view controller hierarchy in your Storyboard where you want to guarantee a specific state on app launch, but your entry point is in some base-level container view controller (think HSApplicationViewController).

It would be silly on viewDidLoad to then trigger a bunch of segues, especially if these animate.  The App would start and the first thing you’d see would be transitions through a view controller hierarchy.

My solution for this started via this article on stackoverflow, and is basically just repackaged here.

I tend to keep a naming convention for segue identifiers.  They usually begin with “segue…” for forward segues, and “unwind….” for unwind segues.

Have a look at this: non-animated_segue

The idea is that you duplicate any segue, uncheck the animates box in the inspector pane and add a suffix to it, such as “…NoAnimation”.  So now you would have “segueSomeThing” and “segueSomeThingNoAnimation”, then when you implement your “prepareForSegue:” method, you have the same handler code for both:

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
  if ([segue.identifier hasPrefix:@"segueSomeThing"])
    // the key is "hasPrefix". You can even use a string constant for your animated variant
    // same destinationViewController, same setup. Just not animated.

And that’s it.  It does have a bit more management overhead as you have to keep track of hard-coded strings in your Storyboard in 2 places, but perhaps it’s worth it.

IB_DESIGNABLE UIView using a custom CALayer (for animations)

I’m a very visual person.  If I can use Interface Builder, I do.  I like it mainly for the separation of concerns, and really who doesn’t like a WYSIWYG way of inspecting your UI ??

So, I had a somewhat unique scenario in that I want to have a UIView that has a custom CALayer that has properties I can animate.  (See here for some background on that, though I will touch on it below:  https://www.objc.io/issues/12-animations/animating-custom-layer-properties/ )

But I also want to be able to configure these properties in Interface Builder via the Inspector pane.

I found a way to do this, although it’s tedious.  In short, you have to define a custom layer, deal with it’s display and animation, and wrap the layer properties on your UIView subclass.

What?  Fine.  Here’s the simplified code to show you how it would work for something like a custom progress bar:

//  HSProgressView.h
//  Created by Stephen O'Connor on 17/02/16.
//  MIT License.

#import <UIKit/UIKit.h>

@interface HSProgressView : UIView

@property (nonatomic, assign) IBInspectable CGFloat progressValue;  // clamps between 0...1
@property (nonatomic, strong) IBInspectable UIColor *barColor;

- (void)setProgressValue:(CGFloat)progress animated:(BOOL)animated;


And the .m file

//  HSProgressView.m
//  Created by Stephen O'Connor on 17/02/16.
//  MIT License.

#import "HSProgressView.h"

@interface HSProgressView()

+ (NSArray*)customLayerProperties;


@interface _HSProgressViewLayer : CALayer

@property (nonatomic, assign) CGFloat progressValue;
@property (nonatomic, strong) UIColor *barColor;


@implementation _HSProgressViewLayer

// these methods are generated at runtime
@synthesize progressValue, barColor;

+ (BOOL)needsDisplayForKey:(NSString *)key
    for (NSString *propertyName in [HSProgressView customLayerProperties]) {
        if ([key isEqualToString:propertyName]) {
            return YES;
    return [super needsDisplayForKey:key];

// AND HOW.  Duration, timing, etc.
// In our case, we only want to animate progress, but not color
- (id)actionForKey:(NSString *)key
    // if (key corresponds to a property name I want to animate...)
    if ([key isEqualToString:@"progressValue"])
        CABasicAnimation *animation = [CABasicAnimation animationWithKeyPath:key];
        animation.timingFunction = [CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionLinear];
        if ([key isEqualToString:@"progressValue"])
            // LOOK HERE!  It's outlined in that post listed above, but
            // if you animate, you need to look to the presentationLayer
            // as it holds the currentValue *right now* or *on screen*
            // if you didn't call presentationLayer, the progress
            // value is going to be the value you are trying to animate to
            // and you would see nothing!
            animation.fromValue = @([self.presentationLayer progressValue]);
        // other animatable properties  here...
        return animation;
    return [super actionForKey:key];

- (void)display
    // again, takes the value that it currently is animating to,
    // if you called self.progress it would always return the final value.
    // that being said, if we want to inspect it in interface builder
    // we have to omit animation and just look at the value it 'wants' to be
    CGFloat progress;
    progress = [self.presentationLayer progressValue];
    progress = [self progressValue];
    //create drawing context
    UIGraphicsBeginImageContextWithOptions(self.bounds.size, NO, 0);
    // backgroundColor is a property on CALayer, but we still need to draw him!
    CGContextRef ctx = UIGraphicsGetCurrentContext();
    CGContextSetFillColorWithColor(ctx, self.backgroundColor);
    CGContextFillRect(ctx, self.bounds);

    // now for our custom properties
    UIBezierPath *path;
    CGRect drawRect = self.bounds;
    drawRect.size.width = MAX(0, MIN(1, progress)) * drawRect.size.width;
    path = [UIBezierPath bezierPathWithRect:drawRect];
    [self.barColor setFill];
    [path fill];
    //set backing image
    self.contents = (id)UIGraphicsGetImageFromCurrentImageContext().CGImage;


static NSArray *HSProgressViewLayerProperties = nil;

@implementation HSProgressView

+ (Class)layerClass
    return [_HSProgressViewLayer class];
+ (NSArray*)customLayerProperties
    if (!HSProgressViewLayerProperties) {
        HSProgressViewLayerProperties = @[
    return HSProgressViewLayerProperties;

#pragma mark - Generic Accessors

// we wrap the properties on the layer, so we override this
// for integration into Interface Builder's IBInspectable properties

- (void)setValue:(id)value forKey:(NSString *)key
    for (NSString *propertyName in [HSProgressView customLayerProperties]) {
        if ([key isEqualToString:propertyName]) {
            [self.layer setValue:value forKey:key];
    [super setValue:value forKey:key];

- (id)valueForKey:(NSString *)key
    for (NSString *propertyName in [HSProgressView customLayerProperties]) {
        if ([key isEqualToString:propertyName]) {
            return [self.layer valueForKey:key];
    return [super valueForKey:key];

#pragma mark - Public Methods

- (void)setProgressValue:(CGFloat)progress animated:(BOOL)animated
    // if animated is yes, it gets it's information about how to
    // animate it via actionForKey: on the custom layer implementation!
    if (!animated) {
        [CATransaction begin];
        [CATransaction setDisableActions:YES];
    _HSProgressViewLayer *layer = (_HSProgressViewLayer*)self.layer;
    layer.progressValue = progress;
    if (!animated) {
        [CATransaction commit];

#pragma mark - Layer-backed Accessors

- (void)setProgressValue:(CGFloat)progressValue
    [self setProgressValue:progressValue animated:NO];

- (void)setBarColor:(UIColor *)barColor
    _HSProgressViewLayer *layer = (_HSProgressViewLayer*)self.layer;
    layer.barColor = barColor;

- (UIColor*)barColor
    _HSProgressViewLayer *layer = (_HSProgressViewLayer*)self.layer;
    return layer.barColor;

- (CGFloat)progressValue
    _HSProgressViewLayer *layer = (_HSProgressViewLayer*)self.layer;
    return layer.progressValue;

#pragma mark - Layout and Drawing

- (void)layoutSubviews
    [super layoutSubviews];
    self.layer.bounds = self.bounds;
    [self.layer setNeedsDisplay];  // because the layer follows the size of the view, whose contents fill the view's frame.


There it is! Copy-paste this into your own class and try it out in Interface Builder. Now you should see how you can extend this for your own purposes.

Proportionally Sized Views, Views that inherit backgroundColor

So, I’m a bit of a late adopter. The problem with working intensively on a project that is grossly understaffed is that you don’t have time to keep up with all the technology. So just now am I getting a deeper understanding of Autolayout on iOS.

There is no way to avoid using Autolayout, so if you haven’t started using it, please do! The various screen sizes of the various iPhones, not to mention multi-tasking on iPad will basically demand you use it.

I’ve run into a situation where I might design some elements for iPhone 5s, but on iPhone 6 they could be bigger. I don’t like the complexity of Size classes, and don’t even think they work very well for the different iPhones. I think it was a way to make one layout work on iPhone and iPad. Hmm… the topic here.

On my latest project I found two things that I needed. So I built them. I wanted a UI Element (a UIView) to always maintain a certain proportion of its superview. Say 75% of the screen width. I didn’t know how to do this in Autolayout. (I suspect it might have something to do with Multipliers??)

Anyway, I also wanted to be able to define a view that would just inherit the background color of its superview. This makes it easier to make changes later in Interface Builder without having to go and alter the whole view hierarchy by hand, or to make outlets for all those views and change them in code.

Well, try for yourself. Here’s the code:

// HSProportionallySizedView.h
// Created by Stephen O'Connor on 30/09/15.
// Copyright © 2015 Iconoclasm Spasms. All rights reserved.
// Actually, MIT License. Hack to your heart's content!
#import <UIKit/UIKit.h>
extern CGFloat const HSProportionallySizedViewNoEffect;
@interface HSProportionallySizedView : UIView
@property (nonatomic, assign) IBInspectable BOOL inheritsBGColor;  // default: NO
// between 0...1.f. Defaults to HSProportionallySizedViewNoEffect
@property (nonatomic, assign) IBInspectable CGFloat widthProportion;
@property (nonatomic, assign) IBInspectable CGFloat heightProportion;
//  HSProportionallySizedView.m
//  Created by Stephen O'Connor on 30/09/15.
//  Copyright © 2015 Iconoclasm Spasms. All rights reserved.
//  Actually, MIT License.  Hack to your heart's content!

#import "HSProportionallySizedView.h"

CGFloat const HSProportionallySizedViewNoEffect = -1.f;

@implementation HSProportionallySizedView

- (void)willMoveToSuperview:(UIView *)newSuperview
    if (self.inheritsBGColor) {
        self.backgroundColor = newSuperview.backgroundColor;

- (void)awakeFromNib
    if (self.inheritsBGColor && self.superview) {
        self.backgroundColor = self.superview.backgroundColor;

- (void)makeDefaultValues
    _inheritsBGColor = NO;
    _widthProportion = HSProportionallySizedViewNoEffect;
    _heightProportion = HSProportionallySizedViewNoEffect;

- (instancetype)initWithFrame:(CGRect)frame {
    if (self = [super initWithFrame:frame]) {
        [self makeDefaultValues];
    return self;

- (instancetype)initWithCoder:(NSCoder *)aDecoder {
    if (self = [super initWithCoder:aDecoder]) {
        [self makeDefaultValues];
    return self;

- (CGSize)intrinsicContentSize
    CGSize size = [super intrinsicContentSize];
    if (self.superview) {
        if (_widthProportion != HSProportionallySizedViewNoEffect) {
            CGFloat proportionalWidth = MAX(0, MIN(1, _widthProportion));
            if (proportionalWidth == 0) {
                NSLog(@"One of your proportional size values is set to 0!!");
            size.width = proportionalWidth * self.superview.bounds.size.width;
        if (_heightProportion != HSProportionallySizedViewNoEffect) {
            CGFloat proportionalHeight = MAX(0, MIN(1, _heightProportion));
            if (proportionalHeight == 0) {
                NSLog(@"One of your proportional size values is set to 0!!");
            size.height = proportionalHeight * self.superview.bounds.size.height;
    return size;

You can see that with the default values it behaves exactly like a UIView. So it makes a suitable baseclass in your codebase.

NOTE: I’m sure there’s a way to do the proportional size in Autolayout without this, so please help me in the comments!

Custom UITableViewHeaderFooterView with Interface Builder

So, one area that Apple needs to tighten up as it’s not clear and the Internet is also a bit divided on is setting up UITableViewHeaderFooterView objects in Interface Builder. Now, sadly you can’t do this in a table view in a Storyboard much like you’d design a prototype cell. No, but there are still ways to visually design these and write minimal code.

So you will have to subclass UITableViewHeaderFooterView and override -(UIView*)contentView. That’s the jist of it. You probably have to subclass it anyway because you have custom content!

@implementation MySettingsHeaderView
- (UIView*)contentView
  return self.subviews[0];

And then create a View NIB file, where the root view’s class is set to this above. The trick is that the first subview is going to be the contentView of the UITableViewHeaderFooterView, but strangely it is a readonly property. So that’s why you need to override.

Custom UITableViewHeaderFooterView in IB

So treat this view as the contentView and add everything to that. This way you can preserve AutoLayout stuff and avoid warnings like:

Setting the background color on UITableViewHeaderFooterView has been deprecated. Please use contentView.backgroundColor instead

Then, all you do is in your viewDidLoad method, you put something like:

[self.tableView registerNib:[UINib nibWithNibName:@"MySettingsHeaderView" bundle:nil] forHeaderFooterViewReuseIdentifier:@"MyHeaderIdentifier"]; // though, be a good coder, and don't pass a hard-coded string, but define a constant for your header identifier!!

Boom! I love you too.

How to center a UIPopoverController and also without arrows

Short recipe here. This blog isn’t always about you… it’s about augmenting my memory! 😀

  UIViewController *contentController = [[UIViewController alloc] init]; // obviously your own...
  UIPopoverArrowDirection arrows;
  CGRect rectForWindow;
  BOOL centeredInWindow = YES;
  if (centeredInWindow) {
    rectForWindow = CGRectMake(self.view.bounds.size.width/2, self.view.bounds.size.height/2, 1, 1);
    arrows = 0;
    // view being some view like a UIButton, that triggered the popup...
    rectForWindow = [self.view convertRect:view.frame fromView: view.superview];  // or whatever...
    arrows = UIPopoverArrowDirectionDown;  // or whatever...

  self.popover = [[UIPopoverController alloc] initWithContentViewController:contentController];
  self.popover.delegate = self;
  // set your contentSize
  CGSize contentSize = (CGSize){320, 460};
  [self.popover setPopoverContentSize:contentSize];
  [self.popover presentPopoverFromRect:rectForWindow