# Best practice

## Protecting your app metadata records

Appfigurate generates a unique 2048-bit RSA private key as part of an app's metadata record that is used for signing configuration payloads. To protect app metadata records you should follow these best practices:

### **iOS Simulator**

We rely upon you and your Mac's security. You Mac should be up-to-date with all security patches applied, firewall enabled, FileVault on. You should use a strong password on boot and screen unlock.

### **Physical devices**

Ensure the device has a strong passcode (six-digit) or custom alphanumeric code. Enable Erase Data after ten failed passcode attempts. <https://support.apple.com/en-us/HT204060>.

You should [enable PIN](https://docs.electricbolt.co.nz/appfigurate-user-guide/settings/passcode-lock#passcode-on-launch) and [TouchID/FaceID/Biometrics](https://docs.electricbolt.co.nz/appfigurate-user-guide/settings/passcode-lock#biometrics-on-launch) to unlock Appfigurate each time it is run, or to restrict your app's metadata from being exported. The database will be deleted after 5 incorrect PIN attempts.

### Real device cloud testing services

For supported real device cloud testing services, your pre-packaged Appfigurate instance is uploaded to the vendors servers and you have no control over storage of your apps. We recommend [using wrong app metadata records for development](#using-wrong-app-metadata-records-for-development) in this scenario so your real app metadata record is never revealed.

## Using wrong app metadata records for development

{% hint style="success" %}
In a large development team it may be beneficial to restrict the distribution of real app metadata records to selected team members. Other team members can continue to test debug builds using the following instructions:
{% endhint %}

In Appfigurate [add a new app](https://docs.electricbolt.co.nz/appfigurate-user-guide/add-app) using the real URL Scheme. The newly created app metadata record will have a completely different (wrong) private key from the real app metadata record.

Ensure your app's [<mark style="color:blue;">`APLConfiguration.allowInvalidSignatures`</mark>](https://www.electricbolt.co.nz/api/Classes/APLConfiguration.html#/c:objc\(cs\)APLConfiguration\(im\)allowInvalidSignatures) method returns `YES` for debug builds and `NO` for release builds. **Do not** replace the real public key in the [<mark style="color:blue;">`APLConfiguration.publicKey`</mark>](https://www.electricbolt.co.nz/api/Classes/APLConfiguration.html#/c:objc\(cs\)APLConfiguration\(im\)publicKey) method with the newly generated (wrong) public key.

<table><thead><tr><th width="274.3333333333333"> </th><th width="218">App is debug build (allowInvalidSignatures returns YES)</th><th>App is release build (allowInvalidSignatures returns NO)</th></tr></thead><tbody><tr><td><strong>Real app metadata record</strong> (Selected team members only)</td><td><mark style="color:green;">✓ Configuration applied</mark></td><td><mark style="color:green;">✓ Configuration applied</mark></td></tr><tr><td><strong>Wrong app metadata record</strong> (Other team members)</td><td><mark style="color:green;">✓ Configuration applied</mark></td><td><mark style="color:red;">✕ Configuration not applied</mark></td></tr></tbody></table>

## Sharing app metadata records between team members

If you need to share an app metadata record (with the real private key) across devices in your team, you should limit the ability to re-export the app's metadata record on the new device. You can do this when [exporting from your device](https://docs.electricbolt.co.nz/appfigurate-user-guide/edit-app#export-share-app) by leaving the `Exportable` switch off. When the app metadata record is imported into the new device, it will not be exportable from that device, and it will expire after 180 days.

## Release builds

When including Appfigurate library into release builds (App Store/TestFlight Beta/Enterprise/Google Play/Alpha track/Beta track), you should ensure that:

1. Your [<mark style="color:blue;">`APLConfiguration`</mark>](https://www.electricbolt.co.nz/api/Classes/APLConfiguration.html) subclass doesn't contain any non-public information that could be used for malicious purposes. e.g. internal server names. You should consider using [encrypted strings](https://docs.electricbolt.co.nz/configuration-subclasses/supported-property-types/encrypted-string).
2. If you have overridden the default behaviour of [<mark style="color:blue;">`APLConfiguration.allowInvalidSignatures`</mark>](https://www.electricbolt.co.nz/api/Classes/APLConfiguration.html#/c:objc\(cs\)APLConfiguration\(im\)allowInvalidSignatures), that you've checked it returns the correct value for debug and release builds. To test this, use Appfigurate to read the current configuration of your app. If a release build reports `Debug build - App allows invalid signatures` then your implementation of [<mark style="color:blue;">`APLConfiguration.allowInvalidSignatures`</mark>](https://www.electricbolt.co.nz/api/Classes/APLConfiguration.html#/c:objc\(cs\)APLConfiguration\(im\)allowInvalidSignatures) is incorrect.
3. You can test applying configuration using a wrong signature to a release build by long-pressing the `Apply⌄` button, then tapping the `Apply invalid to this device` action. Your app will be launched with a configuration payload signed by an invalid key. If the configuration is successfully applied, then your implementation of [<mark style="color:blue;">`APLConfiguration.allowInvalidSignatures`</mark>](https://www.electricbolt.co.nz/api/Classes/APLConfiguration.html#/c:objc\(cs\)APLConfiguration\(im\)allowInvalidSignatures) is incorrect.

## Rotate your private key

You should consider [rotating your private key](https://docs.electricbolt.co.nz/additional-reading/security/rotating-your-private-key) occasionally.