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.
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:
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.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 reportsDebug build - App allows invalid signatures
then your implementation ofAPLConfiguration.allowInvalidSignatures
is incorrect.You can test applying configuration using a wrong signature to a release build by long-pressing the
Apply⌄
button, then tapping theApply 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 ofAPLConfiguration.allowInvalidSignatures
is incorrect.
Rotate your private key
You should consider rotating your private key occasionally.
Last updated