Despite the "Unknown class MyClass in Interface Builder file." error printed at runtime, this issue has nothing to do with Interface Builder, but rather with the linker, which is not linking a class because no code uses it directly.

When the .nib data (compiled from the .xib) is loaded at runtime, MyClass is referenced using a string, but the linker doesn't analyze code functionality, just code existence, so it doesn't know that. Since no other source files references that class, the linker optimizes it out of existence when making the executable. So when Apple's code tries to load such a class, it can't find the code associated with it, and prints the warning.

By default, Objective-C targets will have -all_load -ObjC flags set by default, which will keep all of the symbols. But I had started with a C++ target, and didn't have that. Nevertheless, I found a way around this, which keeps the linker aggressive.

The hack I was originally using was to add an empty static routine like:

+(void)_keepAtLinkTime;

which does nothing, but that I would call once, such as:

int main( int argc, char** argv )
{
   [MyClass _keepAtLinkTime];
   // Your code.
}

This would force the linker to keep the whole class, and the error disappears.

As jlstrecker pointed out in the comments, we do not really need to add a _keepAtLinkTime method. Simply calling an existing one, such as:

   [MyClass class];

does the trick (as long as you derive from an NSObject).

Of course, you can call this in any location of your code. I guess it could even be in unreachable code. The idea is to fool the linker into thinking that MyClass is used somewhere so that it isn't so aggressive in optimizing it out.

Xcode 6.3.2 & Swift 1.2

Swift definition of view. Be sure to override init(coder aDecoder: NSCoder). Objective-C definition of view controller. And, a nib in a pear tree.

Add Module Name to Nib details inspector where you pick your class.

Beeblex developer here. The code inside -validateWithCompletionBlock: execute asynchronously (in the background, it needs to talk to our servers, so there's no point blocking your app completely while we wait for the Internet to do its thing).

Therefore, you need to rethink your approach to validating your receipts. Right now you, general workflow is:

1. Complete purchase
2. Call Beeblex
3. Wait for response
4. Check boolean value

But #3 returns right away, so this will never work. You should consider doing something like this:

1. Complete purchase
2. Show a “Please wait…” view, or something similar that advises the user that you're unlocking whatever they've purchased.
3. Call Beeblex
4. Inside the block, determine whether the validation succeeded or not, and then act to unlock the content from there.
5. Sit idle until called by the block

Here's a quick-and-dirty example. I didn't compile it, so it probably has a few bugs, but it should give you the idea behind the intended usage pattern.

- (void) showWaitView {
    // Display a wait view
}


- (void) hideWaitView {
    // Hide the wait view
}


- (void) completeValidationWithValidateReceiptData:(NSDictionary *) receipt isRecoverableError(BOOL) isRecoverableError {
    [self hideWaitView];

    if (receipt) {
        // Unlock the content, tell the user
    } else {
        if (isRecoverableError) {
            // Probably a network error of some kind. Tell user they need to be connected,
            // and ask them to do it again.
        } else {
            // Keep the content locked, tell the user something went wrong
        }
    }
}

- (void) validateReceipt:(SKPaymentTransaction *) transaction {
    if (![BBXIAPTransaction canValidateTransactions]) {
        [self completeValidationWithValidateReceiptData:Nil isRecoverableError:YES];
        return;
    }

    BBXIAPTransaction *bbxTransaction = [[BBXIAPTransaction alloc] initWithTransaction:transaction];
    bbxTransaction.useSandbox = YES;

    [bbxTransaction validateWithCompletionBlock:^(NSError *error) {
        if (bbxTransaction.transactionVerified) {
            if (bbxTransaction.transactionIsDuplicate) {
                // The transaction is valid, but duplicate - it has already been sent to Beeblex in the past.
                [FlurryAnalytics logEvent:@"Transaction duplicate!"];
                [self completeValidationWithValidateReceiptData:Nil isRecoverableError:NO];
            } else {
                // The transaction has been successfully validated and is unique
                [FlurryAnalytics logEvent:@"Transaction verified"];
                [self completeValidationWithValidateReceiptData:bbxTransaction.validatedTransactionData isRecoverableError:NO];
            }
        } else {
            // Check whether this is a validation error, or if something went wrong with Beeblex
            if (bbxTransaction.hasConfigurationError || bbxTransaction.hasServerError || bbxTransaction.hasClientError) {
                // The error was not caused by a problem with the data, but is most likely due to some transient networking issues
                [FlurryAnalytics logEvent:@"Transaction network error"];
                [self completeValidationWithValidateReceiptData:Nil isRecoverableError:YES];
            } else {
                // The transaction supplied to the validation service was not valid according to Apple
                [FlurryAnalytics logEvent:@"Transaction invalid!!"];
                [self completeValidationWithValidateReceiptData:Nil isRecoverableError:NO];
            }
        }
    }];
}