Qap Criteria — a Qapable product.
Support & Data Deletion
Delete local application content
Qap Criteria does not have a cloud application-content account or administrator database in this release. Everything the app stores is on your own device, so you can remove all of it yourself without contacting us — and you do not need to, because we have no copy to delete.
Two controls inside the app do this:
- Delete a single application from the app’s saved-application list. This removes that application and, when it belongs to the same application, the temporary recovery copy.
- Delete all local data removes all five records the app stores: your saved applications, the temporary recovery copy, the usage count, your colour-theme choice and your legal-acceptance record.
Both controls read each record back after removing it and confirm it is gone. If any record cannot be removed and verified, the app tells you plainly that some data may remain rather than reporting success.
You can also remove everything from outside the app. On iPhone and iPad, delete the Qap Criteria app; its stored data is removed with it. In a browser, clear site data for the Qap Criteria site in your browser or device settings.
Files you exported, downloaded or shared are outside the app’s control. Delete those separately from every destination where you saved or sent them.
Account deletion
There is no persistent Qap Criteria user account to delete in this release. If a future release adds accounts or cloud storage, this page and the Privacy Notice must be updated with a verified account-deletion process before that feature is enabled.
One public mailbox
To keep administration and spam exposure proportionate, the free iOS market-validation release plans to use only support@qapcriteria.com.au. Before the free iOS market-validation release it must be tested for sending, delivery, spam filtering, access protection and regular monitoring. Do not treat it as functioning until this page confirms those checks are complete.
Use the right subject prefix
- [Support] product help;
- [Privacy] privacy questions or complaints;
- [Security] vulnerability reports;
- [Feedback] short product feedback;
- [Accessibility] access barriers; and
- [Brand] suspected brand misuse.
Mailbox rules may route these categories internally without publishing extra addresses. Read the complaints process and vulnerability disclosure page. Never include real application content in a security report.
Spam and attachment controls
The public channel should reject executable attachments, quarantine unexpected files, rate-limit repeat senders where available and use sender-authentication checks. It should not be a catch-all address. Users should be asked to provide a short description and a redacted screenshot only when genuinely necessary.