Injecting data into Obj-C readonly properties

Lee Winder
Engineering Game Development
4 min readJul 23, 2014

<tl;dr>
If you want to inject data into an object that only has read-only properties, swizzle the synthesised getter function so you can inject the data you need at the point it’s accessed.

For example

// Interface we want to override
@interface SKPaymentTransaction : NSObject
@property(nonatomic, readonly) NSData *transactionReceipt;
@end
//
// Returns an invalid receipt
//
NSData* swizzled_transactionReceipt(id self, SEL _cmd)
{
return @“my receipt”;
}
//
// Test our receipt
//
- (void)test_InvalidTransactionSentViaAPI_VerificationFails
{
// Create an invalid transaction
SKPaymentTransaction* invalidTransaction = [[SKPaymentTransaction alloc] init];
// Replace transactionReceipt with our own
Method originalMethod = class_getInstanceMethod([invalidTransaction class], @selector(transactionReceipt));
method_setImplementation(originalMethod, (IMP)swizzled_transactionReceipt);
}

</tl;dr>

I recently needed to set up some client side unit tests for our iOS receipt verification server. This server takes a payment object and verifies it with Apple to check if it’s actually a legal receipt and if it is, the content is awarded to the player. Server side, this is pretty simple, but it’s an important server step and should anything happen its possible for people to be locked out from getting their content.

So it’s important we have tests that send legal, invalid and corrupt data to the server and we need to test through the client API otherwise it’s not a test that can be 100% reliable.

Our verify API looks something like the following

+(BOOL) queueVerificationRequest:(NSString*)productId withTransaction:(SKPaymentTransaction*) transaction;

It takes an SKPaymentTransaction because thats the object the client deals with. We’re going to use internal data such as NSStrings or NSData, but it shouldn’t be the clients responsibility to query the SKPaymentTransaction to get the relevant information. Should the structure change, our API also breaks and that’s not acceptable.

So we’re stuck with the SKPaymentTransaction and its API looks something like this

@interface SKPaymentTransaction : NSObject
@property(nonatomic, readonly) NSError *error;
@property(nonatomic, readonly) SKPaymentTransaction *originalTransaction;
@property(nonatomic, readonly) SKPayment *payment;
@property(nonatomic, readonly) NSArray *downloads;
@property(nonatomic, readonly) NSDate *transactionDate;
@property(nonatomic, readonly) NSString *transactionIdentifier;
@property(nonatomic, readonly) NSData *transactionReceipt;
@property(nonatomic, readonly) SKPaymentTransactionState transactionState;
@end

Now in our case, we’re interested in using [SKPaymentTransaction transactionIdentifier] and [SKPaymentTransaction transactionReceipt], which both need to be managed inside our verification call so we’ll need SKPaymentTransaction objects that return different values depending on what we’re testing.

And since they’re readonly, we can’t just set them manually.

Initially, I tried to use class extensions, just to add the behaviour I was looking for, as you’ll often add internal extensions to present readonly properties externally but support readwrite properties internally.

@interface SKPaymentTransaction()
@property(nonatomic, readwrite) NSString *transactionIdentifier;
@property(nonatomic, readwrite) NSData *transactionReceipt;
@end

Compiles fine but at runtime it generates an unknown selector error. This is because the read only property has already be synthesised, and while the compiler now thinks it can see a setter, at runtime it’s not present.

So, my second attempt was to derive from SKPaymentTransaction and add the functionality there, passing through the base SKPaymentTransaction but using the derived type to set the value.

@interface SKPaymentTransactionDerived : SKPaymentTransaction
@property(nonatomic, readwrite) NSString *transactionIdentifier;
@property(nonatomic, readwrite) NSData *transactionReceipt;
@end

Fortunately, the compilers a bit smarter this time and warns me before I even start

error: auto property synthesis will not synthesize property 'transactionIdentifier' because it is 'readwrite' but it will be synthesized 'readonly' via another property [-Werror,-Wobjc-property-synthesis]

At this point I was a bit stuck until @pmjordan suggested I swizzled the transaction identifier and receipts to return the values I’m interested in testing, rather than setting the values directly.

But what needs to be swizzled when we’re attempting to override an Obj-C property defined as follows

@interface SKPaymentTransaction : NSObject
@property(nonatomic, readonly) NSData *transactionReceipt;
@end

Properties are automatically synthesised (unless explicitly defined) so we’re actually looking at the following selectors

@interface SKPaymentTransaction : NSObject
// Selector used to return the data
-(NSData*) transactionReceipt;
// This would be defined if we’d specified the property as readwrite
// -(void) setTransactionReceipt:(NSData*)receipt;
@end

So at this point, our tests look like the following

//
// Returns an unique invalid receipt
//
NSData* replaced_getTransactionReceipt_Invalid(id self, SEL _cmd)
{
static int runningId = 0;
++runningId;
NSString* receiptString = [NSString stringWithFormat:@”replaced_getTransactionReceipt_Invalid %d”, runningId];
return [receiptString dataUsingEncoding:NSUTF8StringEncoding];
}
// Checks we fail through the API
- (void)test_InvalidTransactionSentViaAPI_VerificationFails
{
//
// Set up …
//
// Create an invalid transaction
SKPaymentTransaction* invalidTransaction = [[SKPaymentTransaction alloc] init];

// Inject our invalid receipt method instead of using the default [SKPaymentTransaction transactionReceipt]
Method originalMethod = class_getInstanceMethod([invalidTransaction class], @selector(transactionReceipt));
method_setImplementation(originalMethod, (IMP)replaced_getTransactionReceipt_Invalid);
// Test our verification
[HLSReceipts queueVerificationRequest:@”test_InvalidTransactionSentViaAPI_VerificationFails” withTransaction:invalidTransaction];
//
// Test validation …
//
}

As a result of this call, when the library calls [SKPaymentTransaction transactionReceipt] it will instead call replaced_getTransactionReceipt_Invalid which gives us the ability to pass through any receipt we want, including real, invalid and corrupt ones as our tests dictate.

It’s worth noting here that I’m using method_setImplementation rather than the usual method_exchangeImplementations which I’ll explain in a following post soon.

--

--