Announcing – Create Surveys via Email

Some of you may have noticed that the flow of posts (and apps) has slowed down a bit. That’s because, among other things, I’ve been busy working on a little side project.

I am extremely happy to announce that that side project is now ready for public consumption, so go check it out at!


Surveylitics is a SaaS app for creating online surveys. It’s main selling point is the ability to create surveys via email. Feel free to try it out and send along your thoughts – feedback is always appreciated.

Now that the Surveylitics launch is out of the way, I’ll hopefully be able to spend a bit more time on the iOS side of things. I’ve already got a nifty new app in the works, and a few other ideas in the pipeline.

Nested push animation can result in corrupted navigation bar

While updating one of my apps a while back, I suddenly started receiving a bizzare error message:

nested push animation can result in corrupted navigation bar

Like most iOS error messages, this one doesn’t really tell you anything about what the problem is or how to fix it. Nested push animation? Huh? Am I somehow calling push from within a call to push? Does ‘can result in’ really mean ‘results in’? Why should I care?

It turns out that the problem was quite simple, and was indeed my own fault. I had a segue hooked up in my storyboard… but I happened to have added some code that was manually calling pushViewController. Removing the old segue from the storyboard solved the problem.


Calculating averages and sums using Core Data

Core Data has built-in support for a number of different functions – which it calls expressions – including average, sum, min, and max.

Let’s have a look at how easy it is to use them.

Suppose we have an entity called ‘Product’, and we want to retrieve the average price of all products that are currently in stock. We start off by creating our typical NSFetchRequest object.

NSFetchRequest* request = [[NSFetchRequest alloc] init];
request.entity = [NSEntityDescription entityForName:@"Product"

We the set up our filter, to make sure we only retrieve items that are in stock. Obviously a real application would likely have a much more complicated predicated here; this is just for demonstration purposes.

request.predicate = [NSPredicate 
             predicateWithFormat:@"StockStatus = %@", @"InStock"];

Next, we have to specify what type of results we want to be returned. The documentation for this property doesn’t seem to be all that good, so we’ll just do what Apple says and ask for a dictionary.

request.resultType = NSDictionaryResultType;

Now we’re on to the actual average calculation code. We need to create a NSExpressionDescription as the top-level thingy that we are requesting the average with. We give it a name so that we can read it out of the dictionary that we get back.

NSExpressionDescription* averageExpressionDescription =
        [[NSExpressionDescription alloc] init];
[averageExpressionDescription setName:@"thisIsTheAverageThatIWant"];

Here’s where it gets a little strange. We have to give our expression description an NSExpression which specifies that we want the average (this is where’ you’d stick in “sum”, “max”, etc. if you wanted them instead). Then, we have to give that expression an NSExpression to specify what field we want to calculate the average on.

    setExpression:[NSExpression expressionForFunction:@"average:"
                                            arguments:[NSArray arrayWithObject:
[NSExpression expressionForKeyPath:@"Price"]]]];

The last thing we have to do to our expression description is set the return data type. In this case, our field is a float, so we’ll specify NSFloatAttributeType.

[averageExpressionDescription setExpressionResultType:NSFloatAttributeType];

We then tell our original fetch request that we want to fetch the average object that we just created.

request.propertiesToFetch = [NSArray arrayWithObject:averageExpressionDescription ;

Finally, we’re ready to execute our fetch request!

NSArray* results = [myContext executeFetchRequest:request error:nil];

Remember how we specified that we wanted a dictionary above? That dictionary is inside the results array, so we’ll extract it, and then read out the value using the key that we specified earlier.

NSDictionary* fetchResultsDictionary = [results objectAtIndex:0];
double finallyIHaveTheAverage = [[fetchResultsDictionary
                objectForKey:@"thisIsTheAverageThatIWant"] floatValue];

And that’s all there is to it! You are now ready to go calculate averages and sums with this simple 17 step proces!

Alternately, you could just use ios-queryable, and do it in one line:

double wowThatWasEasy = [[[myContext ofType:@"Product"]
                                      where:@"StockStatus = %@", @"InStock"]

JavaScript string literals and </script> tags don’t mix

What do you think happens if you try to open up a web page containing the following HTML and JavaScript? Give it a try – the results may surprise you!


It turns out that web browsers are very indiscriminate when parsing closing script tags. The browser will find the </script> tag, even though it’s inside of a string literal in a <script> tag, and consider it to be the end of the script. The result is a few leftover characters and an unmatched </script> tag, which the browser chokes on.


Chrome throws an “Uncaught SyntaxError: Unexpected token ILLEGAL” error.

This was definitely not the behavior I was expecting. After thinking about it, though, it makes perfect sense. The HTML parser doesn’t know anything about the contents of the script. It doesn’t understand that quoted strings should be treated differently. And why should it? The stuff inside the script tags could be anything, in theory.

Sure, this isn’t iOS-specific, but I thought it was interesting enough to be worth sharing anyway.

Undefined Symbol “_OBJC_CLASS_$_NSManagedObject”

I stumbled across this compilation error while adding Core Data support to my latest app-in-progress.

 Undefined symbols for architecture i386:

“_OBJC_CLASS_$_NSManagedObject”, referenced from:

_OBJC_CLASS_$_Show in Show.o

“_OBJC_METACLASS_$_NSManagedObject”, referenced from:

_OBJC_METACLASS_$_Show in Show.o


Fortunately, it’s an easy fix – my project was missing the Core Data framework. After adding it and rebuilding, everything was fine.

The ridiculous part, though, is that despite adding a new Core Data model to my project, creating an entity, and generating an NSManagedObject subclass, Xcode wasn’t smart enough to actually add the Core Data framework for me.

I’m gonna let you in on a little secret, Apple. If someone adds a new Core Data model to their project, and then adds an entity, and then generates NSManagedObject subclasses, it’s probably because, you know, they want to use Core Data. So just add the add the stupid framework automatically and save us all some headaches.

By comparison, Visual Studio does it right, and automatically adds the necessary Entity Framework references for you when you add a new Entity Data Model. There is no reason Xcode shouldn’t do it too (aside from Apple’s general apathy towards their developer tools, that is).