I was in fact doing this very thing, because of this quote from the Core Data Programming Guide, "Consider an application in which you have a Person entity with attributes firstName and lastName, and a cached transient derived property, fullName". Which is where I believe I came up with the idea that this would be a good thing.
However, it goes on to say, "(in practice it might be unlikely that a fullName attribute would be cached, but the example is easy to understand).", letting me know that this really was just for example of what they were describing but probably not good implementation.
So, after reading more about transient properties and their intended use, I realized that this is probably a bad way of using them. I am gaining no benefit from having it cached for my implementation. I did like the ability of using 'dot' notation (because it's a property) instead of having to send a message to the object, but I don't believe there is any performance gain by using it.
More importantly, I believe the overhead of making it a property that your managed object context must track, actually makes it a bad thing.
So, I will be refactoring my app to now make these simple instance methods on the sub-class for my managedObject entity and just return the results as I can see no real benefit to making them transient properties.
The reason to use one of these, is when you actually need to persist something that does not fit one of the managedObject types. But, you then basically create two properties. One that is transient and is the true representation of your object, for which you write getters and setters, and another that is most likely a Binary Data type that is only used internally by the core data entity sub-class for persisting the other objects value(s) in a storage object.
At least this is my understanding of how this all works. Comments are very welcome if I got any of this wrong as it's been very confusing to me as well.
