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 and Android Emulator

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 and TouchID/FaceID/Biometrics 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 in this scenario so your real app metadata record is never revealed.

Using wrong app metadata records for development

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:

In Appfigurate add a new 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 APLConfiguration.allowInvalidSignatures method returns YES for debug builds and NO for release builds. Do not replace the real public key in the APLConfiguration.publicKey method with the newly generated (wrong) public key.

	App is debug build (allowInvalidSignatures returns YES)	App is release build (allowInvalidSignatures returns NO)
Real app metadata record	✓ Configuration will be applied	✓ Configuration applied
Wrong app metadata record	✓ Configuration will be applied	✕ Configuration not applied

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 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 APLConfiguration 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.

2. If you have overridden the default behaviour of APLConfiguration.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 APLConfiguration.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 APLConfiguration.allowInvalidSignatures is incorrect.

Rotate your private key

You should consider rotating your private key occasionally.