The code generation can either be done by the Code Assistant or the Command Line. For the generation you have access to a wide variety of options.
Options
Whichever way you use, you can customize the code generated by using the following options:
| Code Assistant Option | Command Line Option | Comment |
|---|---|---|
| Platform | -o or –os | The targeted platform |
| Bundle Identifier | -i or –identifier | The bundle identifier. On both OS X and iOS, matches the CFBundleIdentifier entry. |
| Bundle Version | -v or –version | The bundle version. On OS X, matches the CFBundleShortVersionString entry; on iOS, matches the CFBundleVersion entry. |
| Code Prefix | -p or –prefix | This options allows to specify a custom prefix for the generated code. This is useful to avoid symbol collision when you include several generated codes. |
| Success Behavior | -s or –success | See table below for an explanation of the options. |
| Failure Behavior | -f or –failure | See table below for an explanation of the options. |
| N/A | -r or –receipt-path | This options allows to specify an external location where the receipt is located. See the Direct Sale guide. |
When the validation succeeds (i.e. the receipt is ok), the following actions can be performed:
| Success Behavior | Description | |
|---|---|---|
| donothing | At the end of the validation, nothing is done. | |
| runapplication | At the end of the validation, call the NSApplicationMain function or the RUNNER macro (only available on OS X). |
|
| checkinapp | At the end of the validation, call the InApp checking block for each request product identifiers. | |
| checkinappandreceipt | At the end of the validation, call the InApp/Receipt checking block for each request product identifiers. | |
| callblock | At the end of the validation, call a block with both the receipt dictionary and the status of the validation. | |
| callfunction | At the end of the validation, call a function with both the receipt dictionary and the status of the validation. |
When the validation fails (i.e. the receipt is missing or is wrongly signed), the following actions can be performed:
| Failure Behavior | Description |
|---|---|
| donothing | If the validation fails at any step, nothing is done. |
| exitwith173 | If the validation fails at any step, the application exits with the code 173 (only available on OS X). |
| refreshreceipt | If the validation fails at any step, a SKReceiptRefreshRequest instance is created and starts with the given delegate (only available on iOS). |
| callblock | If the validation fails at any step, a block that provides both the receipt dictionary and the status of the validation is called. |
| callfunction | If the validation fails at any step, a function that provides both the receipt dictionary and the status of the validation is called. |
| docrash | If the validation fails at any step, crash the application. |
Code Prefix
Due to the nature of the generated code, you cannot use the same header file twice in the same project: it will lead to duplicate symbols. When you integrate several validation header files, you can avoid the duplication problem by using the Code Prefix option.
For example, the Runtime Check code uses RuntimeCheck as default code prefix. The generated code can be invoked this way:
RuntimeCheck_CheckReceipt();
If you specify CustomPrefix as a code prefix, all the symbols will be prefixed with it and the generated code will be invoked this way:
CustomPrefix_CheckReceipt();
RUNNER Macro (OS X)
If you want to use the generated code with APIs other than Cocoa, the generated code contains an extension macro named RUNNER.
The purpose of this macro is to use a function different than NSApplicationMain at the end of the receipt validation.
Check the Using with Mono and the Using with QT guides to see how the RUNNER macro can be used.