I'll leave myself a cheat sheet on how to make a bash script that builds your project into an ipa file.

In the iOS project source folder, create a folder, for example, scripts, and inside it create the file build.sh

mkdir scripts
touch build.sh
chmod +x build.sh

Put your provisioning profile into that folder. Say it is called arm1.ru.mobileprovision. After that, put this code inside build.sh:

#!/bin/bash

# go to the script directory
CURRENT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
cd "${CURRENT_DIR}"

# use the same name that is selected in the project settings under Build Settings > Code Signing Identity
CODE_SIGN_IDENTITY="iPhone Distribution: Your Code Signing Identity"

# name of the provisioning profile stored here
PROVISION="$PWD/arm1.ru.mobileprovision"

# name of the scheme we are building
SCHEME="appScheme"
WORKSPACE="$PWD/../your-app.xcworkspace"

echo "Building..."

BUILDDIR="$PWD/build"
DSYMDIR="$PWD/dSYM"

if [ ! -d "$BUILDDIR" ]; then
    mkdir -p "$BUILDDIR"
fi

if [ ! -d "$DSYMDIR" ]; then
    mkdir -p "$DSYMDIR"
fi

# find the UUID in the provisioning profile
UUID=`grep UUID -A1 -a "${PROVISION}" | grep -io "[-A-Z0-9]\{36\}"`


xcodebuild     -workspace "${WORKSPACE}"     -scheme "${SCHEME}"     -sdk iphoneos     -configuration Release     CODE_SIGN_IDENTITY="${CODE_SIGN_IDENTITY}"     PROVISIONING_PROFILE="${UUID}"     OBJROOT=$BUILDDIR     SYMROOT=$BUILDDIR

if [ $? != 0 ]; then
    echo "Build failed"
    exit 1
fi

echo "Packaging..."

NOW=$(date +"%d_%m_%Y_%H_%M_%S")

xcrun -sdk iphoneos PackageApplication -v "${BUILDDIR}/Release-iphoneos/${SCHEME}.app" -o "$PWD/${SCHEME}_${NOW}.ipa"
if [ $? != 0 ]; then
    echo "Packaging failed"
    exit 2
fi

mv "${BUILDDIR}/Release-iphoneos/${SCHEME}.app.dSYM" "${DSYMDIR}/${SCHEME}_${NOW}.app.dSYM"

echo "Build succeeded."

Voilà, in the folder with the script you now have appScheme.ipa - the built project. The dSYM folder contains the dSYM files. You can add something else at the end of the script. In one of my projects, the end uploads the build to our homemade Testflight and sends the install link to everyone who needs it. Convenient: double-click the sh file and everything gets built and sent.

iOS has a system gesture - swipe from the left edge of the screen and you go back to the previous screen. It's cool and intuitive, and it annoys me when apps disable it, but sometimes you still have to do it. For example, because of an interface decision that conflicts with this swipe.

So for iOS 8, add this to the current UIViewController:

in YouViewController.h:

// add the gesture handling protocol
@interface YouViewController : UIViewController <UIGestureRecognizerDelegate>

in YouViewController.m:

- (void)viewDidLoad {
  [super viewDidLoad];

  self.navigationController.interactivePopGestureRecognizer.enabled = NO;
  self.navigationController.interactivePopGestureRecognizer.delegate = self;
}

#pragma mark - UIGestureRecognizerDelegate

- (BOOL)gestureRecognizerShouldBegin:(UIGestureRecognizer *)gestureRecognizer {
  // disable the gesture if this is swipe back
  if ([gestureRecognizer isEqual:self.navigationController.interactivePopGestureRecognizer]) {
    return NO;
  } else {
    return YES;
  }
}

A problem came up because dates were being parsed incorrectly through RestKit - the time zone was not taken into account, so in the end all dates were displayed 3 hours later than they should have been.

Inside RestKit there are already several NSDateFormatters for parsing a date. If one fails, the second one is used, and so on. But none of them matched the format in which I was getting dates through the API. To parse dates correctly, you need to add your own NSDateFormatter, and put it first in the list so it is applied first:

NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:@"yyyy-MM-dd'T'HH:mm:ss Z"];

[RKObjectMapping alloc];
[[RKValueTransformer defaultValueTransformer] insertValueTransformer:dateFormatter atIndex:0];

A small cheat sheet on the UIViewController lifecycle - which methods are called, and in what order, during different transitions between UIViewControllers.

Controller A Pushes to Controller B

Call order during the transition:

1. initWithCoder:
   1. When a storyboard is used, this method is called instead of init or initWithNibName:bundle:
2. awakeFromNib
3. willMoveToParentViewController:
4. prefersStatusBarHidden
5. preferredStatusBarUpdateAnimation
6. loadView
   1. loadView assigns all outlets (IBOutlets) to the corresponding @property.
7. prepareForSegue:sender:
8. viewDidLoad
   1. All outlets are already connected, but the views have not been rendered yet
9. extendedLayoutIncludesOpaqueBars
10. edgesForExtendedLayout
11. viewWillAppear:
12. extendedLayoutIncludesOpaqueBars
13. edgesForExtendedLayout
14. updateViewConstraints
15. viewWillLayoutSubviews
16. viewDidLayoutSubviews
17. Animation
18. viewDidAppear:
19. didMoveToParentViewController:
20. updateViewConstraints
21. viewWillLayoutSubviews
22. viewDidLayoutSubviews

Some of the methods are called more than once. Layout is called twice - before and after the animation.

Controller B Pushes to Controller C

During the transition:

1. prepareForSegue:sender:
2. viewWillDisappear:
3. updateViewConstraints
4. Animation
5. viewDidDisappear:

Controller C Pops to Controller B

When returning from C to B, this happens:

1. prefersStatusBarHidden
2. preferredStatusBarUpdateAnimation
3. extendedLayoutIncludesOpaqueBars
4. edgesForExtendedLayout
5. viewWillAppear:
6. extendedLayoutIncludesOpaqueBars
7. edgesForExtendedLayout
8. updateViewConstraints
9. viewWillLayoutSubviews
10. viewDidLayoutSubviews
11. Animation
12. viewDidAppear:
13. updateViewConstraints
14. viewWillLayoutSubviews
15. viewDidLayoutSubviews

Controller B Pops to Controller A

Leaving B for good:

1. willMoveToParentViewController:
   1. The argument for this call is nil, which means that scene B will be removed from the hierarchy.
2. viewWillDisappear:
3. updateViewConstraints
4. viewDidDisappear:
5. Animation
6. didMoveToParentViewController:
   1. The argument is also nil
7. dealloc

Source.

I've been trying to come up with something that would make it convenient to do pixel-perfect screen layout while developing iOS apps. Something that would make it easy and visual to compare the mockup and the result. Today I hacked together this tool for OS X - an almost transparent window where you can open a mockup, place it over Xcode or the simulator, and see what you got. You can adjust the transparency with a slider to check how closely it matches.

Maybe it will be useful to someone. Or maybe someone else feels the same pain and will join the development.

The source code is on github.

Download the binary.

P.S. my first app for OS X.

I found a nice little thing on Stack Overflow. In Xcode's Interface Builder you can set some UI values through User Defined Runtime Attributes. I needed to set a border. You can set the layer.borderWidth thickness and it will be picked up, but the color will not. layer.borderColor stores a value of type CGColorRef, while the color you can choose in Interface Builder is a UIColor. A simple category lets you use UIColor through the layer.borderUIColor property.

CALayer+UIColor.h :

//
// CALayer+UIColor.h
//
// Created by Sergey Armodin on 29/05/15.
// Copyright (c) 2015 Sergey Armodin. All rights reserved.
//

#import <QuartzCore/QuartzCore.h>
#import <UIKit/UIKit.h>

@interface CALayer (UIColor)
/**
* CGColor to borderColor
*/
@property(nonatomic, assign) UIColor* borderUIColor;
@end

CALayer+UIColor.m :

//
// CALayer+UIColor.m
//
// Created by Sergey Armodin on 29/05/15.
// Copyright (c) 2015 Sergey Armodin. All rights reserved.
//

#import "CALayer+UIColor.h"

@implementation CALayer (UIColor)
/**
* Setter
*
* @param color UIColor
*/
- (void)setBorderUIColor:(UIColor *)color {
    self.borderColor = color.CGColor;
}

/**
* Getter
*
* @return UIColor
*/
- (UIColor *)borderUIColor {
    return [UIColor colorWithCGColor:self.borderColor];
}
@end

And voilà:

Released a new app - CompareShots.

While working, I had the thought that it would be nice to have some kind of tool for comparing the mockup and the actual result. I wrote this little tool in one evening. Then I spent a few more evenings making screenshots. Yeah, the screenshots took more time :)

The app lets you choose 2 images from the device library. For example, a designer's app or website mockup and a screenshot of what the developer built, and check whether it really matches pixel for pixel. While you keep your finger on the screen, the first image is shown. Take it away, and the second one appears. There is a transparency slider, so you can clearly see where things do not match. The mismatch result as an image can be shared, emailed, or sent to any other app that accepts images.

App for iPhone and iPad.