Links

• Oxygene
• Sugar

You can get 25% of Oxygene using coupon code idtv.

Guest Details

• Marc Hoffman from RemObjects, Twitter: @dwarfland
  
• Scotty from iDeveloper Podcast, Twitter: @macdevnet, App.Net: Scotty
• John Fox from Memory Miner, Twitter: @djembe, App.net: djembe

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here
Or Subscribe in iTunes.

Show Sponsors

Many thanks to our show sponsors who help cover the costs of running the show.

Use Coupon Code  IDEVTV-2013 to get $200 off.

Company: Invasivecode, Training: Invasivecode Training Courses, Twitter: @invasivecode

Links

• Visceral Apps and You (Blog Post)
• MTAnimation (GitHub)
• iDeveloper TV / Invasive Code WWDC Party

Guest Details

• Adam Kirk from Mysterious Trousers, Twitter: @atomkirk
• Scotty from iDeveloper Podcast, Twitter: @macdevnet, App.Net: Scotty
• John Fox from Memory Miner, Twitter: @djembe, App.net: djembe

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here
Or Subscribe in iTunes.

Show Sponsors

Many thanks to our show sponsors who help cover the costs of running the show.

Use Coupon Code  IDEVTV-2013 to get $200 off.

Company: Invasivecode, Training: Invasivecode Training Courses, Twitter: @invasivecode

Links

• BRIEFS

Guest Details

• Ron Rhyne from MartianCraft, Twitter: @capttaco
  
• Scotty from iDeveloper Podcast, Twitter: @macdevnet, App.Net: Scotty
• John Fox from iDeveloper Podcast, Twitter: @djembe, App.Net: @djembe

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here
Or Subscribe in iTunes.

Show Sponsors

Many thanks to our show sponsors who help cover the costs of running the show.

Use Coupon Code  IDEVTV-2013 to get $200 off.

Company: Invasivecode, Training: Invasivecode Training Courses, Twitter: @invasivecode

1. Searching For Speedy Searching

2. Testing For FTS in SQLite

3. Diacritics and FTS

After thinking this through I have decided to move the business stuff out into it’s own podcast and leave the iDeveloper Podcast as it is.

However as I am now producing two podcasts and my current passion is to see indie’s become better business owners I am making it known that the iDeveloper Podcast will, at least for the time being, be operating on an intermittent schedule rather than it’s current weekly(ish) one.

Doing things this way will allow me to still look at things outside of business that interest me or are currently causing a stir without upsetting the people looking for business stuff. As we say about software so often it’s about doing one thing and doing it well.

So my new Software Indie Blog and Podcast will cover business, marketing and productivity while the iDeveloper Podcast will cover technology. Please head over the http://softwareindie.com and check the new stuff out as it begins to develop.

Links

• Mercury Mover
• Highbrow
• Grocery List
• Voodoo Pad
• Acorn
• Moneywell
• NSConference
• TrackTime

Guest Details

• Keith Aperin from Heliumfoot Software, Twitter: @kalperin, App.Net: kalperin
• Scotty from iDeveloper Podcast, Blog: Waffle With Meaning Twitter: @macdevnet, App.Net: Scotty
• Gus Mueller from Flying Meat Software, Blog: The Shape of Everything Twitter: @ccgus, App.Net: ccgus
• Kevin Hoctor from Nothirst Software, Blog: Entrepreneurial Seduction Twitter: @kevinhoctor, App.Net: KevinHoctor

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here
Or Subscribe in iTunes.

Show Sponsors

Many thanks to our show sponsors who help cover the costs of running the show.

Use Coupon Code  IDEVTV-2013 to get $200 off.

Company: Invasivecode, Training: Invasivecode Training Courses, Twitter: @invasivecode

Links

• Lemure Chemistry
• Pure Creek Software

Guest Details

• Matteo Manferdini from Pure Creek, Twitter: @matmanferdini
• Scotty from iDeveloper Podcast, Twitter: @macdevnet, App.Net: Scotty
• John Fox from iDeveloper Podcast, Twitter: @djembe, App.Net: @djembe

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here
Or Subscribe in iTunes.

Show Sponsors

Many thanks to our show sponsors who help cover the costs of running the show.

Use Coupon Code  IDEVTV-2013 to get $200 off.

Company: Invasivecode, Training: Invasivecode Training Courses, Twitter: @invasivecode

Links

• Invasive Code Coupon Code :  IDEVTV-2013
• App Store Pricing – Part 1
• App Store Pricing – Part 2
• App Store Pricing – Part 3
• App Store Pricing – Part 4
• App Store Pricing – Part 5
• Sell More Software E-Book

Guest Details

• Scotty from iDeveloper Podcast, Twitter: @macdevnet, App.Net: Scotty
• John Fox from iDeveloper Podcast, Twitter: @djembe, App.Net: @djembedemora

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here
Or Subscribe in iTunes.

Show Sponsors

Many thanks to our show sponsors who help cover the costs of running the show.

Use Coupon Code  IDEVTV-2013 to get $200 off.

Company: Invasivecode, Training: Invasivecode Training Courses, Twitter: @invasivecode

Links

• Invasive Code Coupon Code :  IDEVTV-2013
• NSConference

Guest Details

• Scotty from iDeveloper Podcast, Twitter: @macdevnet, App.Net: Scotty
• John Fox from iDeveloper Podcast, Twitter: @djembe, App.Net: @djembedemora

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here
Or Subscribe in iTunes.

Show Sponsors

Many thanks to our show sponsors who help cover the costs of running the show.

Use Coupon Code  IDEVTV-2013 to get $200 off.

Company: Invasivecode, Training: Invasivecode Training Courses, Twitter: @invasivecode

Links

• Invasive Code Coupon Code :  IDEVTV-2013
• Johns Appsterdam Talk – Alternative Paths to Living The Indie Dream

Guest Details

• Scotty from iDeveloper Podcast, Twitter: @macdevnet, App.Net: Scotty
• John Fox from iDeveloper Podcast, Twitter: @djembe, App.Net: @djembedemora

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here
Or Subscribe in iTunes.

Show Sponsors

Many thanks to our show sponsors who help cover the costs of running the show.

Use Coupon Code  IDEVTV-2013 to get $200 off.

Company: Invasivecode, Training: Invasivecode Training Courses, Twitter: @invasivecode

Links

• Startups For The Rest Of Us Podcast
• MicroConf Conference
• MicroConf 2012 Videos
• KickOffApp
• Invasive Code Coupon Code :  IDEVTV-2013

Guest Details

• Scotty from iDeveloper Podcast, Twitter: @macdevnet, App.Net: Scotty
• John Fox from iDeveloper Podcast, Twitter: @djembe, App.Net: @djembe
• Saul Mora from NSBrief Podcast,  Twitter: @casademora, App.Net: @casademora

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here
Or Subscribe in iTunes.

Show Sponsors

Many thanks to our show sponsors who help cover the costs of running the show.

Use Coupon Code  IDEVTV-2013 to get $200 off.

Company: Invasivecode, Training: Invasivecode Training Courses, Twitter: @invasivecode

Links

• Startups For The Rest Of Us Podcast

Guest Details

• Scotty from iDeveloper Podcast, Twitter: @macdevnet, App.Net: Scotty
• John Fox from iDeveloper Podcast, Twitter: @djembe, App.Net: @djembe
• Simon Wolf from Otter Software, Blog: Simon Wolfs Writings Twitter: @sgaw, App.Net: @sw

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here
Or Subscribe in iTunes.

Show Sponsors

Many thanks to our show sponsors who help cover the costs of running the show.

Company: Invasivecode, Training: Invasivecode Training Courses, Twitter: @invasivecode

Links

• Plants

Guest Details

• Scotty from iDeveloper Podcast, Twitter: @macdevnet, App.Net: Scotty
• John Fox from iDeveloper Podcast, Twitter: @djembe, App.Net: @djembe
• Georg Tuparev from Tuparev Technologies, Twitter: @tuparev, App.Net: @tuparev

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here
Or Subscribe in iTunes.

Show Sponsors

Many thanks to our show sponsors who help cover the costs of running the show.

Company: Invasivecode, Training: Invasivecode Training Courses, Twitter: @invasivecode

The Proxy Pattern

While the proxy pattern may have been around for quite a number of years, the most influential formal definition of the proxy pattern is in the classic book “Design Patterns” by the Gang of Four, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. The Proxy pattern is a simple pattern that defines an object that stands in for another object. But behind this simple concept lie some interesting tricks. Looking through the other patterns, we also notice that the proxy pattern is key for implementing a flyweight pattern.

I sometimes think of proxy objects as a middle object between the source and destination objects. Indeed, when you extend this thought to everyday (for developers like us) concepts such as a Proxy Server for your Web Browser, you are telling Safari that there is a server on your local network that is allowed to send and receive requests to the wider Internet on your behalf. Indeed the network proxy server is very analogous to a proxy object in a language rooted in the concept of message passing. When you send a message to another object, this is like sending a network request to a site on the Internet. And, just like the network proxy, your proxy object can intercept the request, translate it, alter it, or simply deny the request altogether. Proxy objects can keep your app running, and not crashing, when the intended receiver either doesn’t exist, or is separated from your app’s process space by time or distance. That is, proxies are useful for sending delayed requests to other objects either in the same process, or in other processes and memory spaces. The way Objective C plays into this role is due to its nature as a message passing language.

Message Passing

One of the key differences between Objective-C and its subset counterpart, C is the fundamental method of calling functions or methods. At first glance, there seems to be no difference other than syntax. Indeed, it’s actually a good thing that this difference is subtle. This familiarity allows new developers to easily catch on to the mechanics of the language and get to writing apps. But the fundamental difference between message passing and method or function calling is quite important, and vital to our understanding of why NSProxy exists, and how it works.

When you call a function in a language like C or C++, the function call goes onto the call stack. When you call a method, or rather, send a message to an object in Objective-C, the message gets interpreted by a series of methods to determine how the message should be handled. This is where the difference between static and dynamic languages lie.

Normally in Objective-C, when a message is passed, the message leads to a method call on the object that received the message. This is the most common case in everyday coding. It’s easy to see why message passing seems the same as function or method calling. However, since the object is receiving a message, the object to which the message is sent has the opportunity to figure out what it really wants to do with the message. It can interpret the message, forward it, or simply drop the message.

The NSObject protocol defines some methods that allow the object to handle the message how it chooses. This ability to handle the message is why message passing is not the same as method or function calling. An excellent and detailed explanation of how an object resolves messages is on this Stack Overflow question.

One caveat to message forwarding is that methods that have variable arguments are not forwarded. That means methods such as stringWithFormat: on NSString cannot be forwarded. (See comment in Apple Code Sample ForwardInvocation)

NSDistantObject

Before we get into explaining NSProxy itself, it is useful to explain an example implementation in the Cocoa Framework.

The Cocoa Distributed Object Programming Guide introduces the mechanism for connecting separate processes via a series of objects forming a communication pipeline to a separate (eg. server) process. Indeed, if you take a look at these objects, the nomenclature seems similar to that of a network with terms like ‘connection’ and ‘port’ right in the class names.

NSDistantObject is a concrete implementation of NSProxy that defines proxies for objects in other applications or threads. The default implementation of NSDistantObject is to forward any messages passed to it on to an object at the other end of the NSConnection. NSDistantObject also defines the method setProtocolForProxy: that establishes the set of methods the remote object implements. This is primarily for optimization as you can still pass messages not in the protocol, but there will be some communication involved to determine if the remote object does indeed respond to that message.

NSProtocolChecker is another concrete subclass of NSProxy that also accepts any message from other objects. However, as the name implies, NSProtocolChecker will only accept messages that are part of a given protocol.

NSDistantObject is an example of a message proxy in that it doesn’t implement any methods itself save for those that create and establish the proxy connection. NSDistantObject can handle any message that is passed to it. The effect is that an instance of NSDistantObject looks and acts just like the remote object. If the remote object ever became local, the caller would likely not know the difference at runtime.

There are several other objects in the collection of objects that support Cocoa distributed object architecture. I won’t spoil the fun here, but I do recommend reading the Cocoa Distributed Object Programming Guide for more information.

NSProxy

NSProxy is a special class since it lives next to another popular object, NSObject. Like NSObject, NSProxy is a root level object, meaning that it has no parents. But while NSProxy does not extend from NSObject, it does implement the NSObject protocol. This may be perplexing until you remember what we’ve just learned about NSDistantObject. NSDistantObject is an object that accepts messages on behalf of another, remote object. (Remote or distant in these terms means an object that is separate from your app by time or distance.) Thus, NSProxy is intended to be a class that gives you the absolute minimum functionality in order to accept any Objective-C message on behalf of another object.

One of the other peculiarities of NSProxy is that it does not have an init method. That means, when you’re implementing a subclass, you don’t have to implement the standard Objective C initialization code pattern:

- (id)init
{
self = [super init];
if (self)
{
//do init stuff here
}
return self;
}

This reveals that NSProxy is a lighter-weight version of NSObject. As there is nothing to initialize in the base class, it implies that you get a collection of methods at your disposal that help your object implement the NSObject protocol, and nothing else. This means you don’t get default methods for Objective-C message handling.

As Objective-C developers, there is no doubt you’ve run across the following error message when debugging your app:

Object does not implement selector: [MyObject someNonExistantMethod]

This error occurs because the default behavior of NSObject is such that when it is passed a message that is not a method, this exception is thrown, and your app crashes.

(What happens when we send an unimplemented method to an NSProxy subclass without any message handling methods?).

Using NSProxy

It’s important to keep in mind when you decide to use NSProxy, the class that inherits from NSProxy should accept any and all messages, especially messages that don’t directly correlate to a method in your subclass. Any dropped messages should be due to your own internal message handling logic. With that in mind, let’s take a quick look at creating a class that simply accepts messages, and logs them to the console.

(Example NSProxy subclass)

// MesageInterceptor.h
@interface MessageInterceptor : NSProxy

@property (nonatomic, readonly) NSArray *interceptedMessages;

@end

// MessageInterceptor.m
@interface MessageInterceptor ()

@property (nonatomic, readonly) NSMutableArray *interceptedMessageStrings;

@end

@implementation MessageInterceptor

- (id) init
{
//no need for [super init], it does not exist
if (self)
{
_interceptedMessageStrings = [NSMutableArray array];
}
return self;
}

- (void) forwardInvocation:(NSInvocation *)invocation;
{
NSString *message = NSStringFromSelector([invocation selector]);
[self.interceptedMessageStrings addObject:message];

[invocation invokeWithTarget:nil];
}

@end

When to use NSProxy?

Chances are, you’ll use NSProxy very little as its uses are limited and very specialized. But I’ve scoured the Internet for a couple of examples to share, as well as come up with one I’ve found useful myself.

Mock Object Libraries

When writing unit tests for your apps, you’ve no doubt run across the need for a mock object. Mock Objects are object stand-ins that respond to messages of real objects in your app. Mock objects are useful because they look and act like a real implementation save for the fact that any complex setup or external dependency (like network or database connections) doesn’t exist in a mock object.

If you’ve unit tested code in Cocoa and Objective-C, you’ve no doubt used OCMock. OCMock is a useful set of objects and routines that let you mock your objects as previously explained. Another mock object library for Objective C testing is OCMockito by Jon Reid (@qcoding) of QualityCoding.com.

Have a look at the OCMockObject.m file in the OCMock project, or the MKTBaseMockObject.m file for examples on how mock objects work using NSProxy.

Delegate manager

In researching example uses of NSProxy, I came across the MDelegateManger by @borkware. The delegate manager solves a simple set of problems when implementing the delegate pattern in your own code.

When implementing your own delegates, you have to verify that an object responds to the delegate message every time a delegate message is passed to a delegate. Often times during development you’ll forget this check. In many cases it just seems like boilerplate, repeated code and should be extracted elsewhere. By adding a proxy between the source object and the delegate, you can extract the boilerplate code, and treat your delegate like any other local object. There are also other nice things you can add such as logging when an object doesn’t implement a delegate method, or even that the delegate has not been set in the first place! Since you have a proxy object that is always present, when the delegate is not, you can have something to check that there is an object to which to send messages.

Conclusion

While the NSProxy class has some rather handy features such as being its own root level class, your use of NSProxy will likely be minimal, if ever. The need for a proxy object in your apps probably doesn’t arise often. The delegate manager and mock object libraries are great predefined uses of NSProxy. However, it’s worth noting that if you think you ever need an object to stand in, and accept messages on behalf of another object, then NSProxy is still a great tool to keep in your developer toolbox.

About the Author:

Saul Mora

A software journeyman, Saul thrives on creating well crafted code on his continuous quest to become a Master Developer. Saul is an active member of the Cocoa developer community and contributes by blogging, producing NSBrief, a Cocoa developer podcast, contributing to open source projects, and helping to teach others about the wonders and methods of developing applications. Saul’s software development business, Magical Panda Software, seeks to create well crafted and productive applications for the Mac and iOS platforms. Saul is also an avid cyclist and has recently relocated to Denver.

Twitter: @caasedemora
App.net: @saulmora
Website: iDeveloper.tv

Guest Details

• Scotty from iDeveloper Podcast, Twitter: @macdevnet, App.Net: Scotty
• John Fox from iDeveloper Podcast, Twitter: @djembe, App.Net: @djembe
• Uli Kusterer. Website: Zathras, Twitter: @uliwitness, App.Net: @uliwitness
• Martin Pilkington from MCubed Software, Twitter: @pilky, App.Net: @pilky

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here
Or Subscribe in iTunes.

So get put your cape on, grab a ticket and we’ll see you there.

Visit the NSConference site

Guest Details

• Scotty from iDeveloper Podcast, Twitter: @macdevnet, App.Net: Scotty
• John Fox from iDeveloper Podcast, Twitter: @djembe, App.Net: @djembe
• Saul Mora from NSBrief, Twitter: @casademora, App.Net: @casademora
• Brent Simmons from Identical Cousins, Twitter: @brentsimmons, App.Net: @brentsimmons
• Guy English from DEBUG, Twitter: @gte, App.Net: @gte
• Manton Reece from Core Intuition, App.Net: @manton

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here
Or Subscribe in iTunes.

The UI state restoration API was introduced into UIKit in iOS 6. This is Apple’s way of making it easier (and hence encouraging developers) to have applications restored to their previous state, regardless of whether the app was in the background or terminated. Watching the WWDC video (Session 208, 2012) really gives the impression that they would like all apps to adhere to this, and therefore users will come to expect this kind of behaviour in apps.

This article will cover an overview of the process and a gentle introduction to the basics; the basics will get you reasonably far, although there is a lot to consider – the Apple doc for state preservation and restoration approaches 6000 words on the subject. This isn’t supposed to be a step-by-step tutorial. If people are interested in this topic, and would like more indepth coverage of this, let us know and we’ll look at making a course on this.

Plan First

Before you start implementing preservation and restoration in your application, it’s important to consider how the app works currently; specifically how the different view controllers are created.

The API demonstrates (again) Apple pushing storyboards as the way to implement UI using interface builder. If you’re using storyboards, a section of work is removed, specifically UIKit can use the storyboard (whose state is preserved by UIKit, when app state is preserved) to find or recreate the view controllers, rather than requiring it to be provided either by the app delegate, or by using the restoration class protocol.

Don’t like storyboards?

Aside: We’ll discuss this in more detail later, but the restoration class is a protocol to enable you to preserve/restore view-controllers which weren’t created from a storyboard e.g they were loaded programatically or from a NIB in the course of the app’s execution.

You are still able to specify a restoration class for a view controller, even if it was created from a storyboard, the order of priority means that UIKit will search the saved storyboard information last.

Priority of searching for restoration Info:

1. Restoration Class
2. App Delegate
3. Existing VC with correct Restoration Path
4. Saved Storyboard

So when you’ve thought about where your view controllers come from, and therefore the type of preservation/restoration that will be required, you can start implementing it!

Implementation

Opening interface builder, the most noticable thing about this addition to iOS is the presence of the Restoration ID field in the Identity Inspector. This field is fairly important: When examining what to restore, the operating system will ignore any control, view etc. which has not been assigned a Restoration ID. This is the first way to indicate what you want to happen when your application is restored. Additionally the parent view controller of any view must have a Restoration ID, or the child object will not be restored (Restoration ID or not!).

This is important, because how you want to implement restoration, and the precise nature of what needs to be restored will determine which views need restoration IDs.

To take a simple example:

A simple, single view app, with a UITextView.

The viewcontroller has a restoration ID; the UITextView does not.

First of all, I need to opt into state preservation/restoration, by implementing the following two methods in my AppDelegate

I then need to perform some kind of preservation. Assigning my viewController a restoration ID means it is opted into preservation, but it currently doesn’t contain any state which requires restoring.

My UITextView potentially does; if you look at the documentation of UITextView however,  you’ll notice that two properties are saveable/restorable – the range of selected text, and the current editing state of the view. Not the text that is in the process of being entered when the application is terminated.

Preserving and restoring that text is the responsibility of the view controller:

In the viewController I need to implement two methods to preserve and restore any necessary state:

These methods can be used to encode any necessary state information. Apple is very keen to stress that only information which can’t be recreated in other ways should be restored e.g. information which is already saved by the app, or is part of the standard setup of a view controller.

Apple’s documentation on this is quite useful, and I’m not just going to regurgitate it here – it’s worth checking out.

For my UITextView, I want to be able to save any text that is in the process of being entered. (Any objects being encoded must adopt NSCoding)

The corresponding implementation of decodeRestorableStateWithCode should therfore be fairly obvious:

It’s worth noting at this point the potential difficulties in establishing if your preservation/restoration is actually working, for a couple of reasons:

1. Sometimes when apps enter the background and are immediately restored, their state is preserved without any of this (subject to memory).
2. The most obvious way of clearing an app from memory, for testing this, doesn’t work as you’d expect:

Using the double-tap on the home button, to force quit your app, will not demonstrate your lovely new state preservation code. When an app is forced to quit, any preserved state is deleted. It’s clear why if you think about it: the current state of the app causes it to lock up. Leaving and returning to the app just restores that state. If force-quitting also restored the state, the app could never return to a usable state without deleting the app (and therefore all user data) and reinstalling.

Apple’s advice is to either use Xcode to stop the running app, or to programmatically exit your app. So far, in my experience it hasn’t always been easy to debug these behaviours, and identify exactly what is happening behind the scenes, and real device testing is probably far superior to testing using the simulator.

The final thing I’m going to briefly look at, is the restoration class. As mentioned earlier, if you’re using storyboards for all of your view controllers, this may not be necessary (although it adds a lot of power and flexibility). If you’re not using storyboards, either for all or even part of your app, you’ll need to get familiar with the restoration class.

My view controller (that isn’t from a storyboard) needs to adhere to the UIViewControllerRestoration protocol.

It has one required method, which is to return the requested viewController:
+ (UIViewController *) viewControllerWithRestorationIdentifierPath:(NSArray *)identifierComponents coder:(NSCoder *)coder. The viewController also needs to specify it’s restorationClass (usually itself) and restorationIdentifier.

The restoration class is passed an array giving the full ancestry of viewControllers for the required viewController, and the keyed archive of all saved state for the app.

The simplest example of using a restoration class would just be to restore to the actual viewController itself e.g from a nib file or storyboard, so that the app can be restored in the same state it was left in.

E.g if a viewController is loaded programtically, from a nib file. The restoration class could be just recreating the viewController from the nib, and then returning it.

Apple’s documentation on the protocol is here:

Finally, it’s worth mentioning, if you need to maintain state where it relates to a data source e.g the selection in a UITableView, tableViews and collectionViews are able to preserve the information as long as the data source implements `UIDataSourceModelAssociation`.
Again, I’m not going to regurgitate the Docs here, so if this applies to you – go and check them out!

Hopefully this has been a useful overview of the features Apple has added to iOS6 in this area. If you have a large and complex app, you’re probably not going to be running out to switch wholesale to this new system, but as you start new projects, or even add new features to existing apps, it’s worth checking out. Don’t forget to let us know if you’d be interested in seeing this topic get the full iDTV video course treatment.

About the Author:

Matt Tancock

After spending many years as a teacher and hobby developer Matt has now made his way full time into iOS and OSX development as a researcher and developer for iDeveloper TV.

Twitter: @mtancock
App.net: @mtancock
Website: iDeveloper.tv

Links

•  All The C You Need
• Top To Bottom; Bottom To Top (Blog Post)
• Masters of The Void C Tutorial

Guest Details

• Scotty from iDeveloper TV, Twitter: @macdevnet, App.Net: Scotty
• Bill Dudney, Twitter: @bdudney, Bill’s Website

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here

We’re all familiar with the geometry of views. Usually we interact with them by setting or getting the frame to have the view appear where we want it on screen. The frame is actually a derived property, stored as the bounds and center of the view. When you set the frame of a view it sets the bounds and the center and when you later ask for the frame it gets calculated from those values.

Layers work almost the same, they have properties for the frame (derived), bounds, position and anchor point. By default the anchor point is in the center of the layer, in which case the position corresponds to the center property of the view. But the anchor point can be moved and then the above statement is no longer true.

The anchor point is defined in the unit coordinate space of the bounds which means that its x and y value both go from 0 to 1 within the bounds of the layer. The x value is 0 at the left edge of the layer and 1 at the right edge and similarly for the y value. Note that the screen coordinate space is different between iOS and OS X. On iOS, y increases downwards while it increases upwards on OS X. So the anchor point (0, 0) is either in the top left or bottom left depending on your platform.

Why is there an anchor point?

All transforms are applied relative to the anchor point, by default it is the center of the layer. Scaling down makes the layer shrink in all directions keeping the same position. Applying a rotation makes the view turn around the center. This is the same behavior as you get when applying an affine transform on a view but layers are more powerful than that. If the anchor point was changed to the lower left corner and the same scale and rotation transforms were applied we would get very different effects.

Layers also support 3D transforms so you could move the anchor point to the edge and apply a rotation around the y axis (hold your open hand straight up and twist it back and forth) to create an effect that looks like an opening door.

But something else is happening…

If you’ve experimented with the anchor point before you may have been confused by one thing. When you change the anchor point, the layer actually moves as well. This is because the anchor point and the position is always the same point, only in different coordinate spaces (the anchor point in the bounds’s unit coordinate space and the position in the superlayer’s coordinate space). Since the frame (where the layer appears on screen) is being calculated from the bounds, position and anchor point and only one of them changes then the frame will also have to change.

We can’t have the anchor point move to the corner and the frame stay the same without changing the position so that the frame calculations still are valid. We could calculate and set the correct position ourselves but if we know the frame then we can simply set it and have the correct position (given our anchor point) be calculated for us. Now the layer appears where we want it and the anchor point has moved to the corner.

It may seem strange and stupid that the frame should change if all you wanted was to change the point that the layer transforms relative to. You could argue over whether it makes more sense that the position changes or that the frame changes. You could also argue over whether or not the anchor point should affect the frame calculation at all. Couldn’t the layer have a frame, bounds and center, just like the view so that the anchor point would only be related to the transform? If you stop and think about it for a while the current way starts to make more and more sense.

Say for example that you wanted to make an analog clock inside your app. After having set the anchor point of the hands, setting their position to anything other than the center of the clock-face would simply feel wrong. The hands (in the coordinate space of the clock-face) are anchored in the center, just as they would be in the physical world.

Not only for transforms

As indicated by the clock example above, sometimes the center is not the anchor point you want to use. Have you ever subtracted half the width or height to calculate the position of that layer (or view)? By setting the anchor points to the edge and the positions to the same point you can align multiple layers no matter the size of their content. If the size increases or decreases you can still be sure that the views will stay aligned.

iPhoto for iOS

iPhoto for iOS gives us two beautiful examples of rotation around non-center anchor points. When choosing what kind of effect to apply to an image, the effect controls fan out like a swatch book and on selection they rotate back leaving you with the selected effect control visible at the bottom of the screen.

There is a similar rotation for brushes. By default all brushes lie next to each other on the tool bar and when it comes to selecting a brush they all fan together. A rotation is applied to each brush and all their positions are changed to the same point. This makes them look like a fan. This example is slightly more advanced since it involved more movement (both position and rotation). When selecting a brush the rotation is reversed and each brush gets their own position again so that they end up next to each other.

Thinking outside the box

So far the anchor point has always been within the bounds of the layer but it doesn’t have to. Within the bounds of the layer the values go from 0 to 1.

What would a x-value of 2 mean? Starting from the left edge, 1 is the full width of the layer so a value of 2 would mean 2 full widths of the layer to the right from the left edge. This is the same as 1 full width of the layer to the right from the right edge. Similarly a value of –1 would mean being anchored the full width of the layer to the left of the left edge. As mentioned above, the frame of the layer moves when the anchor point changes so it is quite easy to accidentally move the layer off-screen when using anchor points outside the range of 0 to 1.

All this doesn’t make much sense for positioning, we very rarely want to align things a distance proportional to their size from a point but we sometimes want to transform relative to a points outside our own bounds. Doing a rotation around a points outside the bound without using the anchor point would require calculating the circular path ourselves and using a key-frame animation for the position with that path. For a true rotation we would also have to apply a rotation of the layer (relative to its center). If we instead changed the anchor point we would only rotate and be done with it.

We could also scale a layer relative to an outside point but we would have to keep in mind that everything about the layer scales relative to the anchor point, both the size and the distance. This means that if we scale to twice the size the distance would also double.

The anchor point is animatable

If you read through the documentation you will see that the anchor point is actually animatable. This means that you can have a fixed point in space (if the position doesn’t change) that you can push the layer trough. You could of course do the same thing by animating the position instead (as long as transforms are not involved) but the anchor points allows you to describe the movement relative to the size, e.g. “I want the layer to move from the center all the way to the bottom”.

Finishing up

If you didn’t know of the anchor point before reading this post, I hope that you learned enough to know when to use it.

If you’ve used the anchor point before but felt that its behavior was strange and have avoided using it since, I hope that this post explained some of that behavior and caused you to reconsider.

Finally, if you knew all this, good for you!

About the Author:

David Rönnqvist

David is a graphics and animations development enthusiast from Stockholm, Sweden. He fell in love with Mac and iOS development with the introduction of OS X 10.5 Leopard and the iPhone SDK. When he is not writing code he practices and teaches kung fu.

Twitter: @davidronnqvist
Website: David’s Blog

Developing your app to support in-app purchase will* increase your revenue.

* okay; may.

When Apple opened the App Store to developers in 2008 developers could sell software either with an up-front cost or for free. Apple rules state that each app must be functional. Demo (or time-limited) software wasn’t and still isn’t allowed in the store. There was no option to sell anything else from within the app. That came later, announced at WWDC in 2009. But only for paid apps. Many apps dropped in price to “tier 1″ ($0.99 USD), enabling them to offer in-app purchase. Then in October Apple removed the restriction, allowing free apps to offer paid content or features.

To be accepted into the store at all, even a free app needs to offer some functionality. Inside the app you can sell additional functionality, or “premium features”. Now you’re giving the app away it’s a statistics game: what percentage of your users will make purchases?

Why Use In-App Purchase?

Selling software is more difficult if your users can’t give it a try first. Reputable developers such as Apple can charge a higher price for theirs because people know the quality they produce. But what if you’re not widely known? Are enough people going to take a gamble on you? If they have to pay you a reasonable price probably not. Outside the App Store we’re used to 30-day trial software, we’ve had it for years. This allows people to see whether your software is worth what you say its worth without taking a risk up-front. But as Apple don’t allow demo software, they expect people to gamble their money on apps based purely on screenshots and user reviews. I use the number of reviews as a gauge for how many copies have been sold. Ever noticed how many reviews there are for higher-priced apps? And by higher-priced I mean $10. Not many. I believe this situation has contributed to the “race to the bottom” as developers lowered prices to a point where users would be prepared to lose the money just to try it out. If the software was decent, they got an excellent deal.

By allowing the app to install for free, users can experience the quality of your work as a developer without risk. It gives them confidence to purchase what you have to offer in-app. Even some negative reviews might not hurt your sales because people can judge for themselves without cost. You can price more fairly (to you) having taken away the risk to the user.

When In-App Purchase Works (and when it doesn’t)

I develop Easy Books, a bookkeeping app for iOS and Mac for contractors and small businesses. It’s free to download and uses in-app purchase for different elements of the app. Not everyone uses all the features. I could have produced three different apps, but I decided to make one app and charge separately for the features people want. It’s worked well for me because it keeps the cost down for users who only need basic bookkeeping, while allowing others to make use of invoicing and time tracking.

The model works really well if your app behaves in a fully functional way, so in the case of a game you may get the first 10 levels and purchase more later. Personally I don’t like to see it used in kid’s games though.

If your app does one thing, or is likely to be used only once, it probably won’t make good sense to add in-app purchase.

If you already have a paid app in the store, it’s probably not a good idea to add in-app purchase, unless you’re adding a new feature to the app. It isn’t possible to tell when your app was first purchased, so it isn’t possible to unlock features to users who paid the full price if you want to move to a free + paid in-app purchase model.

You can only sell virtual goods (see Apple Developer Documentation for StoreKit). So selling real-world products and services such as customer support isn’t allowed by Apple. Specifically they say “You must deliver a digital good or service within your application. Do not use In-App Purchase to sell real-world goods and services”.

The same revenue split applies when selling in-app purchase items. After taking off any VAT, Apple keep 30% and pay developers 70%, paid monthly.

As a developer you receive a daily report from Apple in iTunes Connect that lists the in-app purchase products and the numbers sold. It isn’t possible to determine who purchased what, or even whether the same user purchased more than one of your in-app purchase items. You can however break down sales by region. It’s worth mentioning this because many people falsely assume their relationship is with you the developer, whereas in fact it’s with Apple. This is most likely to become a problem if a user contacts you directly about getting a refund: developers have no way of telling whether the user has paid for anything and have no power to credit a user’s Apple ID. I recommend directing people to Apple’s support page because Apple offer refunds if the purchase was made by mistake.

Be aware that making your app free to download means any user can leave a review for your app without paying anything. You’ll get a lot more reviews this way, but it can skew your star rating because you’ll tend to get more negative reviews if it cost your users nothing (see Post Purchase Rationalisation).

Types of In App Purchases

There is also now a free subscription for Newsstand apps.

Okay, How do I Start?

The Apple Documentation is good and provides some code examples. Essentially you’ll need to follow these steps, and I’m assuming here that you are already an iOS developer, familiar with Xcode, App IDs, Provisioning Profiles and setting up a product in iTunes Connect.

• Create an explicit App ID (not a wildcard App ID). In-App Purchases cannot be made from an app associated with a wildcard App ID.
• Create the In-App Purchase item in iTunes Connect from your app’s detail page. The Product Identifier is what you’ll refer to in your code.
• Write an app.
• Validate the receipt received from StoreKit (optional).
• Provide content/premium feature.

Writing the app is obviously the hard part. I can’t really help you there. For the in-app purchase code, see the example code shown in the Apple docs which I suggest following.

Reachability Class

While I recommend using the Apple example code, I also make use of the Reachability Class provided by Apple. Combine the call to [SKPaymentQueue canMakePayments] with a check on the reachability state. If your app has network connectivity, go ahead and request the products in your call to [[SKProductsRequest alloc] initWithProductIdentifiers:]. If not, the store is not available. The Reachability class will call you back if the network becomes available, and you can request the products then.

When the list of products is returned to you in the delegate method productsRequest:didReceiveResponse: you should keep hold of them because you’ll need each SKProduct object later when purchasing. I prefer to make the calls when the app starts (and each time it returns from the background) because you’ll have the current prices and product descriptions available when the user visits your purchasing screen. The user experience is better if they don’t have to wait for prices to appear.

Transaction Observer

You should register as a transaction observer so that StoreKit can call your implementation of the delegate methods when purchases are successful, products are restored and so on. When you register a transaction observer with StoreKit, do not be tempted to un-register. I used to register as an observer when the product list was returned, then de-register if the network became unreachable. Doing this on a Mac App causes the app to crash if the network is intermittent. And there really isn’t any need to de-register, so just register once and leave it at that.

Handling Purchases

When the user taps (or clicks) your buy button, update the UI to show a spinner or give some feedback that you’re in the process of purchasing the product they’ve tapped on. Call [[SKPaymentQueue defaultQueue] addPayment:payment] and wait. StoreKit will call your delegate methods. On failure, inform the user and return the button to its “buy” state because they may be able to fix the problem and try again. On success, your implementation of paymentQueue:updatedTransactions: will be called with an array of SKPaymentTransaction objects. For each one, determine the product identifier from transaction.payment.productIdentifier. It is your choice now whether to provide the content/feature straight away, or whether to validate the receipt first.

Validating Receipts

A Russian hacker set up a server, explained how to install a root certificate and change the DNS settings so he could provide access to in-app purchase items for free. Quite what he had to gain from this, nobody knows. One has to hope he will one day appear at NSConference to explain how clever it all was. Anyway, Apple responded by trying to shut down his system, and explained to developers what they should do in their apps. The vulnerability affects iOS 5.1 and earlier. Apps running on iOS 6 cannot be hacked using this method.

You may wish to validate receipts on your server, especially if you provide access to content at a cost to yourself, perhaps by licensing costs or access to web services. This is not trivial to do, and requires you set up a protocol between your app and your server. NSURLConnection is probably going to come in handy here. Assuming you have that set up, here are the basic steps to validate an in-app purchase receipt on iOS.

The transaction receipt is an NSData object that exists for each transaction passed to you in paymentQueue:updatedTransactions:. This data should be encoded in base64 format and passed to your server. Your server should follow Apple’s recommended steps by creating a JSON object containing the base64 encoded receipt and sending it to https://buy.itunes.apple.com/verifyReceipt or https://sandbox.itunes.apple.com/verifyReceipt. It is useful to try the production URL first, and if that fails to try the sandbox URL. When your app is in review, Apple test using the sandbox so trying both is a good idea to avoid rejection.

The response from Apple is a decode of the receipt (if valid). This gives access to some key properties:

• bid. Bundle ID. Check this is your app.
• transaction_id. Check this hasn’t been used for verification before.
• product_id. This is your product identifier.
• original_purchase_date. This is the date of purchase.

If everything looks good, return a positive response to the device. The device should then take this as a cue to unlock the feature.

Validating in-app purchases on Mac is slightly different. Apple documentation states the process is the same, but many of us were confused because there is no transactionReceipt property returned in the method paymentQueue:updatedTransactions:. I used one of my DTS tickets to find out more and wrote about what I found on StackOverflow. Essentially the process is the same, except that your Mac app’s receipt file is updated with each purchase. This binary file should be base64 encoded as before and passed to your server. Note the format returned by Apple is different from the iOS receipts, which contain one in-app purchase product. The Mac App Store receipt file contains information about the app itself, plus an array of in-app purchases. Also note the different names of the properties such as Bundle_ID on Mac App Store as compared to iOS App Store.

• bundle_id
• in_app[n]->transaction_id
• in_app[n]->product_id
• in_app[n]->original_purchase_date

If you’re interested in testing this process for Mac App Store receipts, follow these steps:

• Find an app you’ve downloaded from the Mac App Store in your Applications folder.
• Use “Show package contents” to find the receipt file in the folder Contents/_MASReceipt.
• Start Terminal and use the command base64 -i <path-to-receipt-file>
• Next type curl -d '{ "receipt-data":"<base64-text-from-above>" }' https://buy.itunes.apple.com/verifyReceipt
• You should get a response from Apple’s server that looks something like this:
  {"status":0, "environment":"Production", "receipt":{"adam_id":"408921426", "bundle_id":"com.apple.Aperture", "application_version":"3.4.3", "download_id":"80001897676463", "in_app":[]}}

Unlocking Features

On iOS, users don’t have easy access to the file system and it’s safe just to store the fact that a product has been purchased by an entry in NSUserDefaults or as a file stored in the app library.

On the Mac, users can easily edit a text file, perhaps changing the user default for their purchases from N to Y. So if you want to lock this down a little, you could consider obfuscating the storage of this flag. Perhaps couple the value with a hash of the machine’s unique identifier, preventing the file from being simply passed to other users and copied to another machine. Or have a look at my initial modifications on AquaticPrime. I started this work to remove the hundred or so warnings when building with AquaticPrime on Lion. Apple deprecated the openssl framework APIs when linked dynamically, so it was either update the code to remove the warnings or statically link openssl. I opted for the former because I didn’t want to add to the size of the binary. The resulting AquaticPrime class now uses the Apple Security Framework instead and can validate AquaticPrime license files (but has problems producing them: that still needs to be done elsewhere).

Problems

When thinking about moving from a paid app to a free app with in-app purchase there are potential problems. You’re adding a lot of complexity.

This is especially true if you’re validating receipts on your own server: now you need to implement a transfer mechanism to pass the receipt to your server and handle the response. What if your server is down? Now you’ll need to store the receipt somewhere and implement a queue so they get passed to your server later. For the consumable product type you don’t have the option of asking the user to use the restore button if the purchase succeeded but your server failed to validate it.

There are other things that can go wrong too:

Didn’t I Purchase this Already?

Expect to provide a lot more support. Users have a hard time understanding why their purchases are not automatically available on all devices. Come to think about it so do I. It should be possible for Apple to call your delegate methods, passing past purchases through to your app without your user needing to do anything. But for whatever reason this isn’t how it works. You’ll need to add a restore button somewhere in your user interface. Users can tap that to restore their past purchases if they’ve purchased non-consumable products. They will be asked for their Apple ID password though, so you can’t perform the tap on their behalf.

Too Many Apple IDs

When a user installs your app they enter their Apple ID and password to begin the download. Any in app purchases must also be from this same Apple ID. People seem to be using more than one Apple ID more often, and this causes quite a few support issues along the lines of “I can’t seem to purchase add-ons”.

I Disabled In-App Purchases. Why I Can’t Purchase In App?

On iOS, users can disable in-app purchases globally on the device. This is a system setting under Settings > General > Restrictions. With this restriction setting turned on, you cannot purchase anything via StoreKit. But you also cannot restore past purchases either. Quite a few support discussions have eventually turned out to be due to the user turning this setting on.

Validate All Your Incoming Data

Of course that’s just good general advice. But I’ve made this mistake in the past and it bit me on 21 June 2012. If you were trying to use my app on that day it crashed shortly after launch. The problem was traced to the delegate method productsRequest:didReceiveResponse: and specifically the localizedTitle property of each SKProduct object in the array passed from Apple’s StoreKit. It suddenly started to be passed as a nil value, and since I was using it as the key in an NSMutableDictionary, both the iOS and Mac app crashed when they received the response from StoreKit. Apple fixed the problem at their end towards the end of the day. It was our busiest day at work; we just answered support questions and tried to keep everyone updated with what we were doing to fix it. The app had a number of one-star reviews that day too, and I believe it’s unusual, but Apple agreed to remove them. They also credited my DTS incident back to me.

Conclusion

By adding IAP to your app, you can start small and add features as time goes on. That should get you into the store sooner so you can start making some money to fund all those other features you wanted to add. But be careful to avoid bloating your app: most iOS apps are tightly focused on doing one thing well.

From my own experience, carving the app into modules of different (but related) functionality has allowed me to set the price for each feature so people don’t need to make a big purchase at the start. They may later have a need for – and decide to buy – something else from me.

Implementing in-app purchase for free apps is a great way to increase the number of downloads. The more people try it out the better for you. Even if your app isn’t right for someone, they may show someone else who later becomes a customer. By taking away the initial risk barrier, you go some way to level the field between you and established developers: if you take reputation out of the buying decision, you can compete on the quality of your app.

About the Author:

Mathew Waters

Mathew has had a passion for technology ever since he began to take things apart. Having left corporate life a few years ago, he now concentrates on developing for iOS and the Mac. He has recently discovered that the “i” in iDeveloper stands for indie, is easily excited by shiny new things, and enjoys flying R22 and R/C helicopters.

Twitter: @mathew_waters
App.net: @muddy
Website: Geode Software

Links

• Objective Cloud
• Objective-Cloud FAQ

Some Objective-Cloud Sample Code

Guest Details

• Scotty from iDeveloper TV, Twitter: @macdevnet, App.Net: Scotty
• John Fox from Memory Miner, Twitter:@djembe, App.Net: djembe
• Amin Negm-Awad, Twitter: @cocoading, Amin’s Website
• Christian Kienle, Twitter: @cocoapimper, Christian’s Website

Please follow our guests on twitter / App.net and show them some developer love.

Audio can be downloaded here

Show Sponsors

Many thanks to our show sponsors who help cover the costs of running the show.

Company: Invasivecode, Training: Invasivecode Training Courses, Twitter: @invasivecode

To get started I feel like I need to give you a short pitch to explain what we do and the complexities of our environment:

Shindig is a platform for events like conferences, festivals or student orientations that let’s you produce mobile apps for your attendees. These mobile apps are true native experiences for iPhone, iPad, Android and HTML. They empower attendees to browse schedules, sessions, speakers, venues, maps, and more. Our apps have features for custom itineraries, push notification and real-time updates that you’d make through our Shindig Manager web application.

So the Shindig product itself is pretty vast. It’s implemented over a number of sub-projects using Rails (Manager), Sinatra (API), Objective-C (iPhone, iPad), Java (Android) and Ruby (various tools). We have five founders who make up the skill set that implement this code base.

Shindig started as a very small, one event, one platform project back in 2010 and over time has grown fairly organically. In the fall of 2011 we made plans to invest more time into the company leading into January of 2012 where we became an LLC. During this transition we assigned various rolls to the five founders and I took over as Project Manager. As Project Manager I wanted to see us become more mature in how we handled the code we wrote.

Certain members of the team had already embraced unit testing and I wanted to see that expand to everyone. I also wanted to expand our testing into functional tests of the user experience. There was no need to do a full stop and add testing for everything, but the idea was it should become a natural part of new code additions and refactoring.

Team members and the projects they were working on were very isolated. Most people didn’t have a firm understanding of how their coworkers were implementing things. I wanted to introduce a code review process that would have team members evaluate one another’s code before it was introduced into the main development branch. The purpose here is to help us find bugs and infrastructure problems early on and to make it clear that code is owned by the team and not a single individual.

Finally we were going to be more formal with our quality assurance practices, including consistent code repository management styles and a release procedure that contained feature freezes and proper testing environments.

This article will review what we came up with, how it’s working for us, and some of our ideas for the future.

Repo Design

We use Git and GitHub for our source control management though I suspect similar patterns can be had in others like SCMs like Mercurial and other hosts like Beanstalk.

For each repo we have the following branches:

•  Master — what is deployed to the public.
• Testing — what is deployed to our testing environment (pre-public launch)
• Development — what is deployed to our development environment
• Feature(s) — feature branches being worked on for future integration into development

Ideal Feature Branch Workflow

Let’s say we have a feature we are ready to work on. The typical workflow for this would be to create a branch off of development and start coding. The general goal is to have the feature scoped so it doesn’t take longer than 1-3 days, and the shorter the better. We dislike large changesets since they are harder to review and since many features interact with one another it’s good to get them into development as soon as possible so we notice problems faster.

!

After the feature is done a pull request is made requesting integration into development. Making a pull request in GitHub is pretty simple. From the repo page click Pull Request:

To define a pull request you choose the destination branch and the source branch:

Once created you can assign a pull request to a specific person. (GitHub will actually email everyone on the repo’s team when the pull request is made. Sadly, there is no way to assign someone during pull request creation.)

The pull request detail page also has helpful sections for all the commits that are contained within this pull request as well as a master diff for the entire pull request.

How Reviews Work

For our team we have five people and we use the buddy system to pair off people and repos, assigning who will do which reviews. The idea is over time we’ll switch things up every so often so the same people aren’t reviewing the same code all the time.

While there is one person assigned to the pull request it’s not uncommon to see people stop by to answer questions or offer feedback. For us it’s a great way to make sure the team is all on the same page early in the development cycle. GitHub is particularly good about notifying people when we using their `@name` shorthand in a comment.

Approving a pull request generally involves:

• Checking out the branch
• Building the product to make sure the new feature or enhancement works as expected.
• Review the new code and tests for overall quality and style.
• Verify all tests pass.

If there is something wrong or not understood there will be a back and forth between the coder and the reviewer. Any new code added to the branch is automatically appended to the pull request. If there has been significant changes on development that might disallow a clean merge the pull request page will say so. To fix this usually all that is usually required is merging development back into the feature branch and working out any conflicts.

Once everything is good to go you can hit the Merge button right on GitHub to merge the feature branch into development.

Dependent Feature Branches

Sometimes (particularly early in the lifespan of a project) features are dependent on one another and so you’ll end up with a branch tree where features are dependent on one another like this:

There is nothing inherently wrong here but the practice is discouraged when possible. The problem this introduces for a code reviewer is that now we have to approve the pull requests in order and if there is a hang up in one pull request it will delay the others.

The other thing you’ll probably want to do is if there are features X, Y and Z to review and X gets approved you’ll want to update the Y branch to get the feature X changes out of the diff (as they are already in development). To do this go into the Y branch and merge in the updated development. This will make it so the Y feature pull request only shows the real changes that Y will introduce to development and remove all the X changes which have already been approved. (This sounds more complex than it is.)

Testing and Release Workflow

When we are approaching a release we’ll merge development into a testing branch. There it will be the source of our testing environment and is considered under feature freeze. While we can still fix bugs on this branch they are held under a higher scrutiny and once applied will reset our testing procedures to make sure the bug fix hasn’t broken other things.

One must also make sure to apply the bug fix to testing as well as development.

Hotfix Workflow

Sometime we discover bugs that are causing system availability problems or data corruption and for these we have a hotfix workflow. It’s very similar to our other practices but is done directly on master. Obviously these are discouraged and only used under special circumstances.

Room for Improvement

We’ve been executing this for a while now and overall are pretty pleased with it. We do have some things we’d like to improve.

Automated deployment for master/development

Particularly for our web systems, we want it so when a pull request is approved and merged into development or master the deployment just happens. Our deployments are scripted so they aren’t terribly difficult but this is something that deserves to be automated.

In time we’d like to completely automate our iOS internal builds.

Automated testing for pull requests

Part of the review process is to run all tests. For some of our more mature products with lots of tests this can take longer than is comfortable. We’d like to see our Jenkins server (which we already use for running tests on development nightly) auto test pull requests. This does require a little more scripting between GitHub and Jenkins but is doable and on our calendar to do so.

Hopefully you’ve found this article helpful and informative. Even if you are a solo coder I would encourage you to reach out to friends (maybe through a local meet up like CocoaHeads and try to set up some sort of peer code review process. Even if it’s only on a fifth of your code changes I think you’ll be surprised in how much you can learn having your code reviewed and reviewing others as well.

If you have any feedback or questions let me know. Thanks.

With Auto layout, Apple has introduced a way of reducing some of the previous pain in this process. Generally, localized xibs should be a thing of the past. Or at least only required in exceptional circumstances.

String Localization

It’s not usually the translation part of the process that causes the pain, it’s those words you get back from your translator (whether that is someone you’ve paid, a friend or relative or google translate).

Sometimes the words are much longer than the originals. German is often singled out for this, but several languages have longer words. Likewise the reverse can be true, going from a language that has longer words to one which is shorter. These are often design problems that need thinking about early, not as an afterthought just before submitting your app for review. If your’re planning on localizing your app, the interface needs to be designed with the necessary fluidity from the beginning.

With that in place, along with the use of auto layout, localization can become reasonably straight forward. You still need to have localized strings, but you don’t need a separately compiled nib for each language.

The single most important step in getting this to work effectively is to avoid hard-coding the widths of controls which contain localized strings. This can be a large task in itself. (See my previous article for some tips – but no promises!)

I’ve created a very basic app to demonstrate. Here you can see the interface. I’ve managed to avoid hard-coding the widths of the views, although some have a >= width on to ensure clipping doesn’t occur.

I’m going to localize this into three languages – English, French & Arabic. The iDeveloper.tv translator is on holiday this week, so I’m going to have to rely on Google Translate and hope it does a reasonable job!

In project settings, navigate to Localizations. I started off by ticking the Use Base Internationalization, to avoid the multiple xibs, and then added the other languages I wanted. Auto Layout is going to take care of the rest.

This is what I’ve ended up with.

A word of warning: It seems that the strings generated are based on whatever strings are in your xib files at the point of performing this option. That means if you start by adding your languages, and then set-up your layout, the strings files will not contain all of the necessary strings, and you’ll have to regenerate those files.

Your strings files will be grouped under your xib files. Initially, their values will all be the same as the base – whatever strings you included when creating the xib file.

Here are my final localized strings files:

English:

French:

Arabic: