Summary
Walletify does not require an account or login. Card designs you save in the app stay on your
device. When you generate a pass for Apple Wallet, the app sends pass fields to Walletify's
server so a signed .pkpass can be created. The server also stores a per-device pass
count and purchase entitlement data needed to enforce the free allowance and paid access.
Data stored on your device
The following stay on your iPhone unless you choose to generate a pass:
- Card designs (store/loyalty cards, boarding passes, Wi-Fi passes), including text fields, colors, barcode values, and optional relevant locations, stored locally with SwiftData.
- Photos or files you use only to detect a barcode. Detection runs on-device; the image is not uploaded for signing.
- Local caches of pass-count and entitlement status (for example in UserDefaults), and App Attest key material in Keychain when App Attest is available.
Device identifier
The app uses Apple's Identifier for Vendor (IDFV) via DeviceManager as a stable
device identifier for API calls. On Simulator, or if IDFV is unavailable, the app generates a
fallback UUID and stores it in UserDefaults. This identifier is used to associate pass-generation
counts, App Attest state, and subscription linkage for that device. It is not used for advertising.
Devices, App Attest, and abuse prevention
Pass-generation requests include an hourly client token used as a lightweight request check. Where supported, Walletify uses Apple's App Attest service to register an app-specific key. Registration sends the device identifier, App Attest key identifier, and Apple's attestation data to the server. Firestore stores the key identifier, public key, attestation date, and security counter. These mechanisms help enforce free limits and reduce automated misuse. They are not used for advertising profiling.
Pass content sent to the server
To produce a signed Apple Wallet pass, the app sends a JSON request to
POST /api/v1/generate-pass. Based on the current client and server code, that
payload can include:
- Your device identifier.
- Pass text fields and metadata (for example description, logo text, store name, cardholder or passenger name, boarding details, barcode message and format, colors, serial number, grouping identifier, transit type, relevant date, and optional location coordinates). A Wi-Fi barcode payload can contain the network name, authentication type, password, and hidden-network flag.
- Flags such as whether to generate a background image from the chosen colors, or whether to link the pass back to the Walletify app.
The server uses that content to assemble and cryptographically sign a .pkpass
file and returns the signed pass to your device. Template artwork used in the pass package
comes from server-side pass models. The current app does not upload custom logo or photo binary
attachments for signing; barcode images used for scanning remain on-device, and only the
resulting barcode payload string is sent.
Walletify's application code processes pass content in memory to create the response and does not store that content in Firestore after the request. Hosting providers may temporarily process request data while delivering and securing the service.
Pass content must reach the server to create a valid signed pass. Do not put secrets in pass fields that you are unwilling to transmit for signing.
Pass generation count
For each device identifier, the server stores a passesGenerated count in Firestore
and enforces a free allowance of 3 successful pass generations per device
unless an active subscription or lifetime purchase applies. Related temporary fields (for
example a pending generation confirmation id) may also be stored during the generate/confirm
flow.
Subscriptions and StoreKit data
Purchases use Apple StoreKit. When the app validates or restores a purchase, it can send your
device identifier and Apple-signed transaction JWS strings to
/api/v1/subscription/validate or /api/v1/subscription/restore. The server verifies
those transactions with Apple and may store entitlement records such as product id, original
transaction id, status, expiration date (when applicable), environment, and linked device ids.
Apple may also send App Store Server Notifications to update subscription status. Billing
details (payment card, Apple Account email, etc.) are handled by Apple, not by Walletify.
Network and security data
API requests include an IP address and standard request information. Walletify uses the IP address for rate limiting and stores it in Firestore with recent request timestamps. The current application does not set an automatic deletion time for inactive rate-limit records. Server and hosting logs can also contain an IP address, request time, method, endpoint, response status, request identifier, device identifier, product identifier, pass-limit outcome, and error details. These records are used to secure, operate, and debug the service, not for advertising.
Support communications
If you email support, Walletify and its email provider receive your email address, message, and any information or attachments you choose to send. This information is used to answer and keep a record of your request.
Third parties
- Apple - App Store distribution, StoreKit purchases, PassKit / Apple Wallet, and App Attest.
- Google Cloud - Cloud Functions hosts the Walletify API; Firestore stores device, rate-limit, attestation-challenge, and purchase records described above.
- Cloudflare - delivers and protects this website and can process IP addresses, request information, and security signals.
- Email provider - receives support messages sent to the support address.
The current iOS app and API codebases do not integrate separate analytics, advertising, or crash-reporting SDKs. Walletify requires service providers that process personal data to protect it with the same or an equivalent level of protection described in this policy and required by applicable data-protection law.
Legal bases
Walletify processes pass requests and purchases to provide the service and perform its agreement with you. Optional device location is processed with your permission, which you can withdraw in iOS Settings. Security, rate limiting, service logs, and support records are processed for the legitimate interests of preventing abuse, maintaining the service, and answering requests. Purchase records may also be kept where required to meet legal obligations. Walletify does not perform automated profiling or make automated decisions that have legal or similarly significant effects on you.
Retention and deletion
Pass content is not stored by the application after the signed pass response is produced. Device records, purchase records, pass-generation counts, and inactive rate-limit records have no automatic deletion window in the current application. They remain while needed to enforce limits, honor purchases, prevent abuse, meet legal obligations, and operate the service, unless removed through a deletion request or operational cleanup. Server logs follow the retention configured by the hosting provider. Support messages remain while needed to answer and document the request.
App Attest challenges expire after five minutes. They are deleted after use or when an expired challenge is checked, and a new challenge for the same device replaces the previous one.
To request deletion of server-side data associated with your device identifier or purchases, email alex@apvl.dev with enough detail to locate the record (for example the device identifier if you have it, approximate purchase date, or other purchase evidence). Local card data can be removed by deleting cards in the app or deleting the app. Uninstalling the app does not by itself erase server-side device or subscription records.
Your privacy rights
Depending on applicable law, you may request access to, correction of, deletion of, restriction of, or portability of your personal data, and may object to certain processing. You may withdraw location permission in iOS Settings. Email alex@apvl.dev to exercise a right. Because Walletify has no account system, you may need to provide your device identifier or purchase evidence so the correct records can be found without disclosing another person's data.
You may also lodge a complaint with Romania's National Supervisory Authority for Personal Data Processing (ANSPDCP) or the data-protection authority where you live or work.
Children
Walletify is not directed at children under 13, and we do not knowingly collect personal information from children under 13.
International processing
Google Cloud, Apple, Cloudflare, and the email provider may process data outside Romania or the European Economic Area. Where required, transfers rely on a lawful safeguard available under applicable data-protection law, such as an adequacy decision or contractual safeguards.
Changes
We may update this policy as the product changes. The "Last updated" date will change when we do. Material changes will be reflected on this page.
Contact
Data controller: Apăvăloaiei Alexandru, Romania. Privacy and deletion requests: alex@apvl.dev. Also see Terms of Use and Support.