Best practice
Last updated
Last updated
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:
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.
Ensure the device has a strong passcode (six-digit) or custom alphanumeric code. Enable Erase Data after ten failed passcode attempts. .
You should and 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.
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 in this scenario so your real app metadata record is never revealed.
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 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 method returns YES for debug builds and NO for release builds. Do not replace the real public key in the method with the newly generated (wrong) public key.
Real app metadata record (Selected team members only)
✓ Configuration applied
✓ Configuration applied
Wrong app metadata record (Other team members)
✓ Configuration applied
✕ Configuration not applied
When including Appfigurate library into release builds (App Store/TestFlight Beta/Enterprise/Google Play/Alpha track/Beta track), you should ensure that:
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 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.
Your subclass doesn't contain any non-public information that could be used for malicious purposes. e.g. internal server names. You should consider using .
If you have overridden the default behaviour of , 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 is incorrect.
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 is incorrect.
You should consider occasionally.