So now we have a LinkShare clicksynergy link with our custom signature attached. Right? If not then go back and read the last post on setting this up. All that we need to do in order to start tracking clicks is to start using our links in strategic places. Some ideas on tracking data is to use custom signatures for links off of your website, links used in press releases, links you send out on Twitter, and of course ‘Buy Now’ links from within a Lite or Free version of your app. It is the later case that I’ll be using for this discussion. The astute reader may recognize that this could be an opportunity to explore pay-per-click advertising with Google Adwords or the like since the clicks can be tracked all the way to a sale (needed to monitor profitability). However, with the low price of most apps in the AppStore I have my doubts as to the efficacy of this approach.

You could start using the clicksynergy links directly and be able to get the needed data. However, a slight improvement in the method can give you some real-time stats to feed your need to monitor app activity. Quite simply you can plug the clicksynergy link into a url shortening service, such as bit.ly, that allows you to track clicks on the link. For example, I have created a signature for clicks from a Lite version of my app, Mathemagics, and plugged the link into bit.ly. I then use this shortened URL within the app itself. Whenever a user clicks on the ‘Buy’ link within the app bit.ly picks up on that click and tracks it immediately. No need to wait for the LinkShare report in order to get an idea of click-through activity for the day.

There are a lot of url shortening services out there these days and bit.ly is only one of them. Be sure to use one that allows you to track stats and even better has an API that you can play with. It should be noted that using a url shortening service adds one extra level of redirection into the path between the user click and showing your app in the AppStore. It also will ensure that mobile Safari is launched and then redirect to the AppStore for links within an iPhone app. It’s not absolutely necessary to use such a service but being the data junkie that I am it allows me to keep a close watch on activity with my apps.

Ok, enough about setting all of this up. Let’s get at the data. After you’ve been tracking stats for a while it’s possible to download the raw click and sales data from the LinkShare website. Simply login to LinkShare, click the ‘Reports’ tab, Advanced Reports, and then select ‘Signature Orders’ from the report type drop list. Also, be sure to set your desired date range. Here’s an example of what the data looks like:

The ‘Member ID’ column is actually the signature used in your link (in this case ‘mathemagics_lite’). There are other interesting columns in the report such as the transaction date, commissions, and sales. It would be great if the SKU was actually useful but it appears to be mostly the same for every transaction with only a few variances. Ideally, it would be the actual SKU of the product purchased (remember those mostly useless SKU’s that you entered in when submitting your iPhone app?). This is probably a good place to mention the Achilles’ heal of this whole methodology. You pretty much have to take it on faith that a purchase at the price point of your app is in fact a purchase of your app. This gets even more complicated if you’ve been changing around the price of your app. Keep records and you should be able to use the transaction date to sort it out. At the time of this report Mathemagics Lite was on sale for $1.99. So, I know that those sales for $22.95, $.99 et al are not for my app. I still get commissions off of the sales (yea!) but they need to be removed when analyzing the data with respect to my app.

To get the data and actually use it take a look at the bottom of the table and find the ‘Download’ link. You can download to Excel, as data, or as MHTML. I’ve been downloading ‘as data’ which gives me a file with a .csv extension. But a csv extension is about all I get since the data is actually tab delimited. A quick pass through “tr ‘\t’ ‘,’” and all is right with the world since I like to import the data into Numbers. One final bit of peculiarity with LinkShare is that the download link only grabs the data from the visible page. If you want all of the data from your entire report then you’ll need to navigate to each page, download the data, and then merge it all together. Draconian, I know. But, at least it can be had.

The final missing piece of the metrics puzzle is the total number of clicks on the link. This can be had via the same LinkShare reporting tool by running the ‘Signature Activity’ report over the same time period. Simply find the intersection of your signature and the clicks column. If you used a url shortening service you may also be able to get this data there as well.

In the next and final article I’ll present the above numbers from Mathemagics Lite for the month of March 2009 and calculate the Conversion Rate for sales of the full version as well as a few other stats for the app.

]]> http://shanecrawford.org/2009/145/tracking-appstore-conversions-part-2/feed/ 5 http://shanecrawford.org/2009/119/tracking-appstore-conversions-part-1/ http://shanecrawford.org/2009/119/tracking-appstore-conversions-part-1/#comments Tue, 31 Mar 2009 21:52:21 +0000 shane http://shanecrawford.org/?p=119 As developers we tend to live in our code bases. However, in order to make a living, so we can write more code, it is important to focus at least some of our time on the dreaded marketing side of app publishing. To be honest, just using some of the terminology weirds me out a bit. But if you’re going to make a run at app development be it iPhone, Mac, or whatever you need to get wet so why not dive in feet first.

If you’re like me you like optimizing things. Tweaking the sales of your apps upward is no different and can be accomplished through effective marketing (and a little luck). The key word here is “effective”. Without data to support our efforts we’re really just shooting blindly in the dark. In this series of posts I’ll outline a way that we can get raw data on the effectiveness of our online and in-app marketing efforts for iPhone apps. The technique to be discussed was originally mentioned on MobileOrchard and if you want a good overview of the process I highly suggest you take a look at the article. I’ll be doing a deep dive into creating the necessary links, obtaining the data, and finally analyzing it. We’ll start with details on collecting data and end with some real numbers for one of my iPhone apps.

Our ultimate goal, at least for this article, is to determine how many application sales result from a particular marketing effort. On the web this is fairly easy to do with the help from our friends at Google. However, on the iPhone the sales channel is obscured by the iTunes AppStore. Once a user clicks into the AppStore their actions enter a black hole and we can no longer determine if they bought our app. Or so we thought. There is in fact a way to determine if a particular user click resulted in a sale of our application. This mechanism is found in the iTunes affiliate program available through LinkShare.

If you haven’t signed up for the iTunes affiliate program through LinkShare go do it now. Not only will it allow you to track your app marketing efforts but you’ll get an additional 5% on each and every sale that you refer as defined by their program. This not only includes your own app but any other app, song, movie, or whatever the user purchases after clicking your link. Even better you will continue to garner 5% from all purchases of that user for the next 120 days or until someone else refers them back to iTunes (these are known as ‘Return Days’ in LinkShare terminology).

So the extra 5% is great but how does that help our marketing data efforts? LinkShare provides an additional mechanism known as ‘Signatures’ that thankfully Apple supports. Signatures are the missing link that will allow us to see into the iTunes AppStore and determine whether a particular user click resulted in a purchase of our application. This linkage will then allow us to calculate a Conversion Rate from which we can begin to understand how effective our marketing effort is.

It should be noted at this point that there are a few gotchas and the system is not perfect. In fact, due to some reporting peculiarities with LinkShare signature reports the data can really only be taken in aggregate over a longer period of time (say a month or more). From the LinkShare help manual, “Most reports are based on the transaction date—the date the transaction actually occurs. The Signature Orders report, however, is based on the process date —the date that LinkShare receives and processes the transaction data sent by the advertiser“. As it works out it happens to be the Signature Orders report that we’re looking to use. So, since the data slides slightly based on the process date we can aggregate the data over a longer period of time and any temporal issues should be minimized. With that being said I have observed that the data from Apple appears to be processed within a day or so (as in all things YMMV).

Now, it’s finally time to set up a LinkShare signature so that we can start collecting some data. It’s really pretty easy. The first thing to do is create the standard LinkShare referral link. Basically, all that you need to do is grab an iTunes link for your product and then paste it into the LinkShare link builder.

The LinkShare link builder is available after logging into your account on the ‘Links’ tab. From this tab I have been using the ‘Deep Linking’ feature to just plug in my iTunes URL, fill in a signature and generate the clicksynergy URL. If you already have clicksynergy links created never fear. All you really need to do is add a ‘&u1=<your_custom_signature>’ to the end of the url. You can also modify the signature value whenever you want without ever going back into LinkShare since it will get picked up and tracked automatically. The value of the signature parameter can be whatever you want but I do suggest making it meaningful since this is all you’ll have in the report to figure out what link was clicked on.

Well, that’s it for now. Next up we’ll get into using our clicksynergy link and getting at the data the signatures give us. Then after we know how to collect and process the data we’ll look at analyzing it. At which point I’ll show real metrics as gathered from one of my iPhone apps.

In most cases a UIView is as large as the iPhone screen or smaller. But, in a few cases you may want a view that is larger than the normal iPhone screen size. Such a case might be when using the view within a UIScrollView which is a view that can manage subviews of arbitrary size. Interface Builder makes it exceedingly easy to configure views in the majority of cases but in special cases it falls flat and specifically in the case of the views size. The issue arises when a UIView is associated directly to a UIViewController.

As you can see from the screenshot the view labeled ‘SampleView’ is shown in IB as a subview to a view controller. Interface Builder seems to like to treat a UIViewController as some sort of pseudo view which can contain subviews. This is fine from a conceptual standpoint but this pseudo view has no controlls for size, location, etc. What ends up happening is that the views size is locked into a maximum size of 320 x 480. Again this is fine for most cases but falls short for those times when you want a view larger than is standard. What’s worse is that the Inspector for a UIView will allow you that change the width and height of a view attached in this way but in reality it is limited. You can see this when running your application. This behavior also makes it impossible to design anything but the top 480 pixels of your view in Interface Builder since it will only display a view design window that is fixed to what it thinks is the maximum size. In short attaching a view as a direct ’subview’ of a view controller in Interface Builder can lead to some major limitations.

The solution to all of this is actually quite simple. Simply do not add your view as a subview to the view controllers ‘pseudo view’. Instead add your view as a standalone view in your NIB.

As you can see from the second screenshot my view is not listed as a subview of the view controller but rather as a standalone view in its own right. You can then associate your custom view with the ‘view’ outlet of the controller. Now, your view can be resized to any size that you want, you can design the entire view in IB, and it will show up with the correct size when you run your app.

“However, the NDA has created too much of a burden on developers, authors and others interested in helping further the iPhone’s success, so we are dropping it for released software.”

Since I have been mainly focusing on iPhone development for the past few months my posts of Cocoa related development have fallen off. Now that it appears that we can write about released portions of the iPhone SDK I hope to be writing more about Cocoa Touch and of course Cocoa. I truly hope that the lifting of the NDA will help to build the iPhone developer community along a path parallel to that of the Mac developer community. I think that a golden opportunity has been missed to create the same sort of Mac developer goodwill and attitude in the iPhone developer community because of the NDA. Hopefully, now that developers are free to discuss the platform a rich and vibrant developer community will form with the same dedication to helping each other out.

I have always promoted open communication and discussion and I am no stranger to feedback. Yet, the one-way, anonymous, and often eviscerating nature of AppStore reviews shut down open communication and further degrade any sense of community. Both positive, negative, and often misguided reviews suffer from this affliction. I guess I could chalk it up to human nature in an anonymous environment, competitor “App Rolling”, or even immaturity. But, I think the system itself could be tweaked in order to increase the quality of reviews without compromising users ability to express themselves.

First, identify users in the reviews that have purchased the product from those who have not. I don’t necessarily agree with the often bandied about idea of blocking out anyone who has not purchased a product. Users may see a feature that they need or some interface peculiarity that they would like resolved prior to purchasing. While the best way to communicate this type of information is to contact a products support team directly folks seem reluctant to do so, whether for time and effort of for other reasons. Clearly identifying users who have purchased a product from those who have not would allow review readers to mentally place a weighting on the validity of a review. All of the information is in the system to make something like this work it just needs to be made a priority.

Second, make reviews semi-anonymous. Allow the public facing nickname of a review to stay in place and remain anonymous. However, give access to reviewer email addresses to the owner of a product. In this way, a developer can directly encourage or rebut reviews by directly communicating with the reviewer. Alternatively, in order to address privacy concerns in this area a form could be enabled for developers which would send an email or message to a reviewer by keeping their direct contact info private.

Finally, encourage reviews to be revisited from time-to-time. This could be handled in several ways from deleting old reviews to notifying a reviewer when a new version of an app has been released. In addition, reviews could be removed, hidden, or the user notified when a certain threshold of ‘No’ responses has been obtained to the “Was this review helpful?” question. Currently it seems that a review made in the AppStore is immortal but even bad credit will roll off of a credit report in seven years.

As a developer I like to communicate directly with my users as anyone who has emailed Babelingo’s support well knows. A lot of that communication can and does happen via email and a products blog. However, AppStore reviews are by far the most direct and most read form of product communication. Software is not like most songs or movies. The best stuff comes from community involvement by feeding back constructively into the work itself. The AppStore review system short-circuits the needed feedback loop by being both anonymous and one-way. While the list of improvements that I’ve outlined here is by no means exhaustive I think it would provide a good start at helping us all to both create and purchase quality software on the AppStore.

This year for the keynote I stepped into line outside of Moscone at 5:30 am. As fortune or fate would have it I was just barely ahead of the same place in line last year when I had arrived at around 7:00 am. So, maybe that could be used as some sort of judgment on the size and enthusiasm of the crowd this year.

Why get in line so early and would I do that again? Yep, I think I would. Just being able to get up somewhat close to the stage for the big event makes it that much more exciting. Even more than that though you have some fun and make some friends as the line compresses and expands exposing you to different groups of people. If none of that matters to you though you can show up an hour or less prior to the keynote and watch it from one of the overflow rooms.

Unfortunately I can’t talk about the content of any of the WWDC sessions that I attended. However, I will say that, for me at least, most of the content seemed to be either way too high level (getting started) or way too low level (audio API’s). In any case, good info is there to be had and I picked up a lot of tips and got exposure to parts of the platform that I haven’t touched yet. Amazingly at every WWDC I have attended the speakers are first rate. They’re developers, managers, evangelists, and the like and I must say they all do an excellent job at presenting.

I spent a lot more time this year taking advantage of the labs that were available. The labs were divided out into major platform components and each had a dedicated area of the conference floor. Within each lab experts on a particular topic would be scheduled to be on hand during a particular time slot and all that you needed to do, in most cases, was just drop by and talk with them. Bring questions, code, or design ideas and it’s a good bet that you can talk with the guy or gal who actually wrote the code for some part of the system that your interested in. That in itself is worth the price of the conference ticket in my opinion.

Outside of the conference sessions, labs, and lunchtime speakers there are still plenty of Apple and non-Apple sponsored events. As for non-Apple events this is where your networking comes into play. Keep your ear to the ground because every night after the normal WWDC hours the real party begins. This year I made it to the VMWare party at ‘The Thirsty Bear’, the Cocoa Heads meeting at the Apple store (awesome), the Austin area Cocoa Coders get together at the ‘W’ (hi Jim!), and the Big Nerd Ranch party. Each and everyone was a lot of fun and I didn’t even scratch the surface of the events that I could have attended.

On the Apple sponsored events side of the coin you’ve got the ADA awards (not to be missed), Stump the Experts (which I did miss this year in preference to sleep), and of course the Thursday night beer bash. Apple’s beer bash is the ‘must do’ event of the week. The food and drink selection is a couple of notches above what you’ve had all week and, prior to the entertainment coming on stage, is a decent networking opportunity. I mean when you’re standing shoulder to shoulder its kinda hard not to meet the person next to you. This year the entertainment blew me away. I’ve always been a Barenaked Ladies fan and guess who stepped on stage? Yep, BNL! I was right down front just about center stage and managed to take this shot with my iPhone:

… tons of fun and the Barenaked Ladies were a blast as they talked and jibed about Apple.

All in all it was a great conference. I’ll definitely be back next year. Now to sleep for a few days and dream of that new code I’ll be writing.

I’ll be at WWDC again this year and I can’t wait. It should be a blast assuming that the sold out conference doesn’t take away from the overall experience. June is going to be one hectic month. I’ll be flying from Mexico back to Austin and then hopping on a plane 3 hours later for WWDC. A late arrival in San Fran will be followed by an early rise to sit in line for check-in and wait for the SteveNote. I’m a bit bummed that I’ll have to miss some Sunday night get togethers but c’est la vie. Post WWDC holds more travel as well but it’ll be more of a local nature.

If you’re going to be at WWDC drop me a line and maybe we can hook up for a beer or three.

Update

The latest Mac Developer Roundtable covers some really great tips if you’re attending WWDC for the first time (or even if you’re a veteran). Marcus Zarra,  Bill Dudney, John Chaffee and of course Scotty all provide some excellent insight into WWDC from an attendee perspective. Highly recommended.

The Good,

When I think of that quote I imagine what kind of feedback the exec was talking about. For me it meant feedback from peers and end users. Depending on the crowd that you hang out with it can actually be quite difficult to get good constructive criticism. I know, I know, what you’re thinking. This guy is asking for it? Yea, as long as it contains that operative word constructive and is meant with sincerity. Feedback is often the only way for you to see beyond your own narrow view of the world. Think of the Truman Show. Here you have this guy who has known nothing else but a little island for his entire life. Then little by little he starts to notice inconsistencies which make him think about the world around him. Had those quirks never happened or had he failed to notice them he would still be sitting there on his TV show. Feedback is the express train to realization.

Constructive criticism coming from your peers can take you to new levels of your craft. Of course, it’s up to you to decide if any one piece of feedback takes you in the direction you want to go as a developer, individual, astronaut, or whatever. This requires some introspection on your part. Developing a bit of a rhinoceros skin and a good humor about yourself also helps to digest the horse pill that can be peer feedback. However, the best peer feedback is often of the positive persuasion. A simple, “Good job” or “Man, that’s great” can do wonders to spur someone on in their current direction.

Assuming that you’re a software developer/publisher, you can have feedback from end users. Feedback of this sort can put greenbacks in your pocket book. When a user emails to notify you that there is a UI bug or that they don’t understand the usage of some feature it is your clue that something may be up. The same or similar item coming from two, three, or even more people should start to perk up your spider senses to a potential improvement in a design or work flow. Again, introspection is the order of the day when deciding if a request or issue falls along the direction and intent of your particular flavor of software.

the Bad,

Being the bearer of feedback can be just as tough as receiving it. That is, if your intent is to be constructive (and I hope that it is). Simply blurting out your observation of flaws comes across as strictly criticism and that’s bad. Instead, hold back the thought for a bit and think of ways to improve on the subject at hand. I mean, you see a flaw so you must have an idea of how things could be better. Right? Reverse roles with the person and think about how you would want to hear the news that you are about to deliver. Finally, provide your critique along with a suggestion on how to improve. Running through this sequence becomes second nature once practiced for a while. Some people will do it naturally and don’t even think about it. Others need a process to follow. Some characteristics of good feedback include:

• Transfer of information rather than the giving of advise
• Covers a specific issue rather than a general one
• Focuses on the content rather than the person
• Offered with empathy

Just as bad as not being able to take feedback is never giving it. Floating merrily along accepting the status quo lies in a direct line towards failure. Yours or someone else’s. It could take years or even decades to materialize but sooner or later such a static nature will break down. Often an unwillingness to provide feedback is really masking a desire to avoid receiving it. If that’s you then start small. Give yourself time to develop the skills of giving and receiving feedback. I think you’ll be better for it in the long run.

and the Ugly

Trolls and flame warriors need not apply. We all know the type of inflammatory feedback that a supposedly anonymous internet can elicit. There is something about the feeling of anonymity that can draw out some of the more basal aspects of human nature. In short, there is little you can do but surround yourself with as many upstanding people as possible and simply ignore the occasional flame. Responding to outright deleterious comments or feedback usually only fans the flames and invites more of the same. Use that rhinoceros skin and good humor to the best of your ability and ignore it.

That’s a wrap

There you have it. The good, the bad, and the ugly of feedback. Sometimes it takes stepping outside of yourself in order to see the larger picture but feedback is a great way to grow an idea, a product, or yourself.

Feedback. It’s not just for breakfast anymore.

There is a way out of this quandary and its called peer review. The mere mention of “peer review” can strike fear and foreboding into the hearts of developers. But, like it or not, this egoless programming practice has the power to deliver.

Outside input can lead to an increase in production quality and ultimately product appeal. Here’s a few ways to get outside input and ideas if you’re flying solo:

• Direct communication with friends. Friends that you’ve made through previous jobs, ventures, or virtual contacts made real are great sources of input. When in the same industry they can provide a unique perspective. If it has been a longtime since you’ve touched base then invite them out for lunch, or better yet a beer, in order to reconnect.
• End Users. The end users of your product are an extremely valuable source of feedback. While a user may not be privy to the nitty gritty code details they will have an opinion about what is good or bad about your interface. Running a public or private beta will give you the chance to gather valuable feedback and roll it into a product before going live with it.
• User groups. There is a good chance that there is a Cocoa developer group that meets regularly in your area. A few places to start would be CocoaHeads, NSCoder Night, and if you’re in Austin CocoaCoder. Getting out and mingling with other developers is a great way to cultivate ideas, get feedback and make a few friends. Try giving a short presentation to the group on some code or a technique that you’ve been working on. Not only will this give the group a chance to discuss a topic but it can help you validate ideas or to open up new avenues of thought.
• Virtual community. Participation in online forums, email lists, IRC channels, and of course blogs can be another source of outside input. While readily available the quality of this sort of feedback can tend towards the inflammatory. Be sure to research your questions and always interact per the guidelines of your chosen group. Oh, and be sure to don your flame retardant suit before dipping your toes in.

Whatever avenue you pursue to gain outside input it has the ability to not only improve on your own designs but to also increase your creativity. New ideas yield more new ideas and so on. So, if you’re feeling like you’ve hit a brick wall or that you need a second opinion try getting some outside input.

A Means to An End

One of the great things about CoreData is the ability to model your entity objects in XCode’s data modeler and automatically have access to its attributes and relationships via Objective-C 2.0 properties or the standard Key Value Coding (KVC) methods. Simply gain access to an NSManagedObject instance for your entity and away you go. This magic is pulled off by virtue of CoreData dynamically generating efficient accessor methods for the properties that you define. These internally generated methods take the form primitiveKey (e.g. for the property ‘title’ the method ‘primitiveTitle’ would be generated). CoreData then effectively injects itself into the KVC mechanisms by checking for unbounded property exceptions on calls to valueForKey: and then calling its own generated ‘primitive’ methods in turn.

Another very important part of the CoreData voodoo is that NSManagedObject disables automatic key value observing change notifications. In addition, the generated primitive methods do not fire these notifications for you. Therefore, it is very important for subclasses of NSManagedObject providing their own accessor method implementations to fire the relevant access and change notification methods whenever accessing entity properties. The important methods to note are:

- (void)willAccessValueForKey:(NSString *)key;
- (void)didAccessValueForKey:(NSString *)key;
- (void)willChangeValueForKey:(NSString *)key;
- (void)didChangeValueForKey:(NSString *)key;

Now, finally armed with knowledge of CoreData’s intimate details we can implement our own NSManagedObject accessor methods. More importantly, the properties that those accessor methods represent do not actually need to exist on the entity definition and we can bind to them in Interface Builder.

Virtually Yours

In order to demonstrate this wizardry we evoke our now ubiquitous blog application example. For this incarnation we want to automatically generate a title based on a posts author and date. A dubious example to be sure but it serves our purposes.

Our first order of business is to create a BlogPost entity using XCode’s data modeler. The entity will contain only two real properties, an ‘author’ property of type String and a ‘postDate’ property of type Date. The ‘title’ property will be considered as virtual and will automatically be created as a custom combination of the current value of the ‘author’ and ‘postDate’ attributes. Next, we need to create a subclass of NSManagedObject and assign that class to our entity (See CoreData’s default date value for details on doing this). The primary purpose of our subclass is two fold. First, it defines accessor methods for our virtual ‘title’ property. Second, it overrides the setter methods for ‘author’ and ‘postDate’ in order to notify the system that the ‘title’ property has changed whenever one of these two properties changes. If our title property worked in reverse and was write-only there would be no need to override the author and postDate setter methods. Here’s the code:

@implementation BlogPostEntity

- (NSString*) title
{
    [self willAccessValueForKey:@"author"];
    [self willAccessValueForKey:@"postDate"];

    NSString *titleAuthor = [self primitiveAuthor];
    NSDate *titleDate = [self primitivePostDate];

    [self didAccessValueForKey:@"author"];
    [self didAccessValueForKey:@"postDate"];

    NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
    [dateFormatter setDateStyle:NSDateFormatterMediumStyle];
    [dateFormatter setTimeStyle:NSDateFormatterNoStyle];

    NSString *title = [NSString stringWithFormat:@"%@ (%@)", [dateFormatter stringFromDate:titleDate], titleAuthor];

    [dateFormatter release];

    return title;
}

- (void)setAuthor:(NSString *)newAuthor
{
    [self willChangeValueForKey:@"author"];
    [self willChangeValueForKey:@"title"];

    [self setPrimitiveAuthor:newAuthor];

    [self didChangeValueForKey:@"author"];
    [self didChangeValueForKey:@"title"];
}

- (void)setPostDate:(NSDate *)newPostDate
{
    [self willChangeValueForKey:@"postDate"];
    [self willChangeValueForKey:@"title"];

    [self setPrimitivePostDate:newPostDate];

    [self didChangeValueForKey:@"postDate"];
    [self didChangeValueForKey:@"title"];
}
@end

Take particular note of the usage of willAccessValueForKey:, didAccessValueForKey:, willChangeValueForKey:, and didChangeValueForKey:. In the ‘title’ accessor we notify the system that we will be accessing the values of the author and postDate attributes. Likewise, in the setter methods for author and postDate we notify that we will be changing the requisite property along with title (which we are in effect changing). An additional item of interest are the calls to primitiveAuthor, primitivePostDate, setPrimitiveAuthor:, and setPrimitivePostDate:. These methods are dynamically generated by NSManagedObject and therefore are not known at compile time thus producing warnings. These warnings can easily be taken care of by creating a category which defines those methods.

@interface BlogPostEntity (PrimitiveAccessors)
- (NSString *)primitiveAuthor;
- (void)setPrimitiveAuthor:(NSString *)newAuthor;
- (NSDate *)primitivePostDate;
- (void)setPrimitivePostDate:(NSDate *)newPostDate;
@end

As you can see nowhere did we define an actual ‘title’ property on our BlogPost entity in the data modeler. Yet, we can now bind to that property in Interface Builder and allow our interface to diverge from the underlying data model when needed.

For those that want to take a closer look the example XCode project can be found here: Virtual Accessors Example Project. For the rest, keep this little technique in mind for those occasions when you know that the user interface should be this way or that but you just don’t want to torque your data model. Code on.

Update

Scott Stevenson has provided an improvement to this technique. The end result is the same but the implementation is more elegant and much more maintainable. In essence, instead of overriding the accessor methods for author and postDate we provide an implementation for +keyPathsForValuesAffectingTitle. This lets the system know that a modification to either ‘author’ or ‘postDate’ should also trigger a change to ‘title’ thus eliminating the need to override their accessor methods. Sweet. In addition, since we still need to access the values for author and postDate we go ahead and define them as Objective-C 2.0 properties of our NSManagedObject subclass with the implementation tagged as @dynamic. This prevents compiler errors while still allowing us to access the values as provided by our superclass. Very nice indeed. An updated project can be found here: Virtual Accessors Example Project Improved