- We Ask Permission to Access Any Resources Necessary to Function.
If an app needs access to certain resources on your device (for example, the music library, or your contacts list), it will ask explicit permission to do so, and explain, quite clearly, what it needs the resource for.
- We do not retain or store device data outside of the device’s storage facility.
This may sound a bit wonky, but what we are saying is that we will generally leave your data in the locked cabinet, as opposed to taking it out and leaving it on the counter.
For example, if your phone stores your music library in a secure place, we don’t make a copy of that data and store it elsewhere. We will always retrieve your data from the secure enclave on your device.
If we ever need to do anything other than this (for example, a cache), we will explicitly describe what we will do, where it will be stored, why, and for how long.
Of course, it goes without saying (but we’ll say it anyway) that we will not export your secure data beyond the confines of the device or the app’s “sandbox” (the secure memory container in which the app runs).
In some cases, the operation of the app may require extracting one element of data from a secure location, and sending it to another location on the device (like a login string that may be required to access a secured element in another device service). If so, we use the element exactly as prescribed, and delete it when we are complete.
- We Don’t Bypass System Policies.
Very simply, we follow the rules and stay in our lane. Apple has a lot of fairly strict policies regarding data access, use, distribution and storage. These are generally made clear in their Developer Documentation.
Many of these policies are enforced by the system API, and we promise to use these system APIs exactly as Apple decrees.
- We Are Extremely Careful About Using Third-Party Code.
By “third-party code,” we are generally referring to “dependencies” on libraries written by developers other than ourselves (or Apple, as we depend heavily on the code they ship with the development system and device).
Whenever we include code from a third party, we are taking a big chance. We are giving that code a powerful execution thread, and it will have access to all the resources the app can reach.
That’s a big responsibility. One that we take seriously.
The Great Rift Valley Software Company writes “native” code, in Apple’s dedicated programming language (Swift), and relies on Apple’s built-in code libraries and adapters.
That means that our code is small, ultra-high-quality, and lickety-split fast.
It also means that we are aware of what every line of code in our apps does. In some cases, we may be required to use a third-party library in order to provide a premium user experience, or interface with certain services (some service providers require that their services only be accessed by their libraries, or use of their SDK may greatly enhance the ability to use their service).
In these cases –which we strive to keep few and far between– we research the included library carefully, and examine the licensing and data access/retention policies.
We won’t use them if we are not satisfied that they are completely aboveboard, and meet our standards of quality, transparency and ethics.
Upon deciding to integrate their code with ours, we will make their policies clear to you, in addition to ours, and we will describe the need for the library.