# Strongbox for iOS (in-app purchase variant): a study of its network traffic

This is the full report. A short report is `README.md` (same directory).

**Version 1.0 of 19 October 2026.** Vendor documents as of the time of the study: 8 October 2026; on 15 October 2026 the vendor changed the privacy policy, and between 14 and 16 October 2026 (authors' account) it changed the article on network connections; both changes followed the authors' questions, and both versions are given in section 3. The vendor's replies of 14 and 16 October 2026 are quoted in full in section 6.

Authors: paying Strongbox users, anonymous. Contact: see section 7.

## Prologue

*This prologue describes the authors' personal experience and impressions; the report itself starts in section 1.*

We are active Strongbox users. We chose it because it met all our functional requirements. The privacy policy, linked from the app and the App Store, and the support article the policy linked to, answered our doubts. The article also encouraged users to check the connections themselves. We had no concerns.

At the end of September 2026, entirely by chance, one of us was using the iOS App Privacy Report to see how many domains a different app, one used for testing connections, was contacting, and noticed a strangely large number of connections from Strongbox to domains the app's documentation did not mention (two screenshots: [1](sources/P0_app-privacy-report_domains_2026-09-30.png), [2](sources/P0_app-privacy-report_most-contacted_2026-09-30.png)). Intrigued, we decided to look into it.

## Summary

On every launch, the tested version of the app connects to two external services: RevenueCat (purchase handling) and Superwall (purchase screens), whether or not the user has a subscription. On every start, several dozen events with a device profile go to Superwall, including the device identifier (IDFV), the App Store transaction identifier, model, operating system, language, region, currency, time zone, dark mode and connection type. The service returns a location derived from the IP address and a purchase propensity score, and the app sends them back in later events. The same device identifier goes to RevenueCat.

On the first launch after installation, the app sends an Apple AdServices attribution token to RevenueCat, which in this SDK version has to be switched on by the app. The content of password databases is not sent. After a database is opened, in the 6 observed unlocks the app sent no events concerning the database (one exception, most likely triggered by the user, is described in 3.8). No connection from Strongbox to Sentry was observed (DNS lookups of `sentry.io` without a connection, of unestablished origin: section 4).

The privacy policy in force at the time of the study (as of 9 May 2024) stated that the app uses no vendors or analytics providers and collects no location data. The vendor's article on network connections did not list these services. The vendor's public statements (post of 26 January 2026, D16; interview of 1 August 2026, D15) described the data as limited to paywall events. After the authors' questions, the vendor changed both documents (policy: 15 October 2026; article: between 14 and 16 October 2026, according to the authors' account): the new versions name RevenueCat and Superwall, device identifiers, approximate location derived from the IP address, an estimate of purchase likelihood, and operation with an active subscription (3.1, 3.5).

Most of the observed behaviour matches the default settings of both SDKs; in the app's public code (state 1.65.0) both SDKs are configured with defaults apart from the StoreKit version, and none of the available options to limit data collection is used (3.10, 3.11). The flow to Superwall is the same on the device with an active subscription, to which, under the configuration, no paywall can be shown.

The App Store privacy label lists one data type ("Purchase History", purpose "Analytics", not linked to the user) and, according to web archive snapshots, has not changed since 8 January 2026, including after Superwall was added (as of 18 October 2026); the traffic contains data that match Apple's definitions of Device ID, Coarse Location and Product Interaction (3.9). This report describes traffic leaving the phone. It does not describe what the recipients do with the data, and it attributes no intent to the vendor.

The vendor replied on 14 October 2026 in broad strokes and on 16 October 2026 under each question: the privacy policy remained out of date by mistake; the AdServices token serves Apple Search Ads attribution; App Tracking Transparency is not used; the vendor does not use the location derived from the IP address or the demand score; paywalls are preloaded for subscribers too, in case the entitlement is lost; the user currently cannot turn the event collection off; no release note named Superwall, only the launch post on Reddit (D16). Several questions remained unanswered; see section 6.

## 1. What was studied and what was not

- App: Strongbox - Password Manager, App Store, bundle `com.markmcguill.strongbox`, version 1.65.2 (build 152), in-app purchase variant. SDKs according to request headers: RevenueCat 5.21.1, Superwall 4.15.3.
- Out of scope: Strongbox Pro (one-off purchase), Strongbox Zero, the macOS version.
- Subject: connections made by the app to the RevenueCat and Superwall services and to paywall resources (`user-content.superwalleditor.com`, Google Fonts, `js.stripe.com`), set against the wording of the vendor's public declarations.
- Other connections (Sentry, favicons, the `duckduckgo.com` connectivity test) were observed but are not the subject of this report. Within the scope examined, no discrepancy with the declarations was found in them (section 4).
- The report describes what the app sends and when. It does not describe what a recipient does with the data, and it attributes no intent to the vendor.

## 2. How it was studied

**Devices** (three iPhones owned by the authors):

| Device | Model, system | Account state in the app |
|---|---|---|
| A | iPhone16,1, iOS 27.0.1 | annual Pro subscription, active; from 3 Oct, Strongbox Pro and Strongbox Zero also installed |
| B | iPhone13,2, iOS 26.5 | until 3 Oct, entitlement through Family Sharing (from A); on 3 Oct the authors turned sharing off and the entitlement expired; fresh installation on 3 Oct |
| C | iPhone14,5, iOS 26.7.1 | never installed before, no purchase |

**Tools:** Proxyman (macOS) with TLS decryption for the RevenueCat, Superwall and Google Fonts hosts and `js.stripe.com`; Proxyman for iOS on the device in A0, S02, S17 and S18 (identified by connections to `proxyman.com` in the packet captures; the attribution of the Sentry traffic in section 4 and the comparison of T2 and T3 in section 5 rest on this); `rvictl` + Wireshark (full packet capture from the device, `rvi0`). Apple domains were not decrypted.

**Runs** (dates only; exact times omitted, see "Pseudonymisation"):

| Run | Date | Device | Activity | Capture | VPN |
|---|---|---|---|---|---|
| A0 | 1 Oct | A | launch, 1.5 min on the home screen | HAR (domain filter), PCAP | no |
| S02 | 1 Oct | A | 3 cold starts, database locked | HAR (domain filter), PCAP | no |
| S01 | 1 Oct | B | first launch after installation | HAR, PCAP | no |
| S11b | 1 Oct | A | 6 app openings, including 2 cold starts; crash reporting option off/on | HAR, PCAP | no |
| S17 | 3 Oct | B | fresh installation without entitlement, 1 cold start, background/foreground transitions | HAR, PCAP | yes |
| S18 | 3 Oct | B | cold start, unlock of a test database, browsing entries, favicons | HAR (domain filter), PCAP | yes |
| T1 | 3 Oct | B | 5 min, app closed, without Proxyman | PCAP | yes |
| T2 | 3 Oct | B | 3 cold starts, without Proxyman | PCAP | yes |
| T3 | 3 Oct | B | 3 cycles: cold start, unlock, 2 entries, lock, background | HAR, PCAP | yes |
| A5 | 5 Oct | A | 2 × (installation, first launch) | HAR | yes |
| A8 | 8 Oct | A | installation, first launch, 3 starts | HAR | yes |
| C8 | 8 Oct | C | first launch, 2 cold starts, database creation, 2 unlocks | HAR | no (mobile connection) |

A VPN on the router, with its exit in another country, was active in the runs of 3, 5 and 8 October on A and B. This was established from the country derived from the IP address that the Superwall service returns, and from the authors' account. In total, 24 cold starts (A 12, B 9, C 3).

**Pseudonymisation.** In the HAR files in `data/`, identifiers, tokens, addresses, purchase dates and prices are replaced with labels of the form `<<TYPE_hash_Llength>>` (HMAC with a local salt; the same value gives the same label in every file). Field names, hosts and paths are unchanged. Server addresses are replaced with labels of the form `<<IP_n>>`, numbered in order of first appearance, the same for the same address in every published file (HAR fields `serverIPAddress` and the address columns of the packet capture extracts), so that "same address" comparisons between hosts and runs remain possible (the sets of CDN addresses in the runs with and without the VPN are disjoint, so they could have pointed to the exit country of the VPN). The CloudFront point of presence, which indicates an approximate location, is masked in both headers that carry it (`X-Amz-Cf-Pop` and `cdn-pop` in `Server-Timing`). All timestamps in every published file (the HAR and the extracts of the same run) are shifted by a constant random value of at least 3 and less than 31 days (forward or backward), different for each run. Intervals within a file are preserved and the entries are sorted by time. Where a request carries a date and a time of day next to a full timestamp (`utcDate` and `utcTime` next to `utcDateTime` in the `device` object of `enrich` requests), both are derived from the shifted timestamp; any other bare time of day would be replaced with `<<MASKED_CLOCK>>` (none occurs in the published files). Times should not be compared between files. The time shift limits the matching of the authors' records on the services' side; the vendor knows the test days from the correspondence. The content of paywall resources was removed. Entries of other apps were removed. The published files carry the run codes from the table above (`data/A0.pub.har` … `data/C8.pub.har`), because the Proxyman export names contained the export time. Scripts and their change log: `tools/`. From the packet captures only extracts are published (DNS, SNI, SYN/QUIC, connection statistics), without content. The 13-digit `sw_cache_key` parameter in paywall resource URLs (most likely the publication time of the paywall version on the service side, H) cannot be shifted with the run, so it is masked in every place where it occurs (request URL and `queryString`, `Referer` header, `$paywall_url` in events, `url` fields of the configuration) with the same placeholder `<<MASKED_NUM>>` for every value.

**Checksums** of the published files: `data/SHA256SUMS.txt`, `sources/SHA256SUMS.txt`.

## 3. Observations next to the wording of the declarations

Labels: **F** (fact from a file, with its location), **D** (document, with address and date of access), **R** (the vendor's replies to the authors of 14 and 16 October 2026, quoted in full in section 6), **I** (inference: a conclusion drawn by the authors), **H** (hypothesis). Document codes (D1–D21, EP1–EP7a, P0) refer to the files and addresses listed in `sources/README.md`; codes not used in this report are not listed there separately.

### 3.1 Connections on every cold start

F: In each of the 21 cold starts recorded in HAR, the app connected to `api.revenuecat.com`, `api.superwall.me`, `collector.superwall.me`, `enrichment-api.superwall.com` and `subscriptions-api.superwall.com`. In the 3 starts of T2 (packet capture only, without Proxyman) the names `api.revenuecat.com`, `api.superwall.me` and `enrichment-api.superwall.com` are visible; the names `collector` and `subscriptions-api` are absent. In the 6 captures with DNS answers for these hosts (S01, S02, S11b, S17, S18, T3), `collector` resolves to the same addresses as `api.superwall.me`, and `subscriptions-api` to the same as `enrichment-api` (`data/pcap-extracts/*_dns-answers.csv`). In T2, on every start one connection to an `api.superwall.me` address carries 77–87 kB towards the server; like every app connection in T2, it stays open for 61–65 s (60.7–65.3 s; `data/pcap-extracts/T2_tcp-conversations.txt`). H (T2 only): both hosts share one connection (HTTP/2). In the captures with Proxyman the app opens separate TLS connections to `collector` (1 to 12 per capture: A0 1, S01 3, S02 5, S11b 12, S17 5, S18 4, T3 6), so there is no such sharing there. The connections occur whether the user has an active entitlement (A), an expired one (B) or has never made a purchase (C).

D1 (privacy policy, strongboxsafe.com/privacy/, "Last Update: 9 May 2024", snapshot taken 8 October 2026, `sources/D1_privacy-policy_strongboxsafe.com_2026-10-08.pdf`; text: `sources/D1_privacy-policy_strongboxsafe.com_wayback-20261001190802.txt`; the version in force at the time of the study): "The Application does not use vendors or analytics providers."
D4–D8 (article "What Network Connections Can Strongbox Make?", snapshot taken 8 October 2026, `sources/D4-D8_network-connections_reamaze_2026-10-08.pdf`; text: `sources/D4-D8_network-connections_reamaze_wayback-20261001191012.txt`): the list of connections covered App Store/StoreKit, the `duckduckgo.com` connectivity test, favicons (opt-in), Have I Been Pwned (opt-in); "None of these connections send any of your databases or personal identifying information."
D4 (the same article): "For your own verification purposes you can use Wireshark, Charles or Surge […] to monitor all network traffic". The method used in this study matches that invitation. The new version of the article keeps this invitation ("You can inspect network activity using tools such as Charles, Wireshark or a device firewall.").
D1, version of 15 October 2026 ("Last Update: 15 October 2026 – Updated information on purchases, service providers, analytics, crash reporting and optional integrations.", accessed 16 October 2026; `sources/D1_privacy-policy_strongboxsafe.com_2026-10-16.pdf` and `.txt`; Wayback: web.archive.org/web/20261016171629/https://strongboxsafe.com/privacy/): "We use Apple and RevenueCat to manage purchases and subscriptions, check access to paid features, restore purchases and determine offer eligibility."; "The iOS freemium app uses Superwall to provide upgrade screens, manage offers and measure their performance. This integration can run even when you already have an active Pro subscription." D4–D8, new version (changed between 14 and 16 October 2026 according to the authors' account, section 5; accessed 16 October 2026; `sources/D4-D8_network-connections_reamaze_2026-10-16.pdf` and `.txt`; a Wayback Machine capture requested on 16 October 2026 resolves to the archive's copy of 9 June 2026, the old version, so the record of the new version is the PDF and the text file): names RevenueCat, Superwall, Sentry and Apple Ads attribution; "These connections can occur when the app starts, including for users with an active Pro subscription."
I: the RevenueCat and Superwall hosts appeared neither in D1 nor in D4–D8 in the versions in force at the time of the study (RevenueCat in the app since 12 May 2025, Superwall since 26 January 2026). The vendor named both providers publicly in D9/D16 (release notes and a post, 2025–2026) and in D15 (interview, 1 August 2026). Whether this differed from the wording of D1 depended on whether a payment operator and a paywall operator are "vendors or analytics providers"; the Superwall documentation describes the data collected and an analytics purpose (`sources/sdk-source-notes_2026-10-09.md`). The new versions (policy of 15 October 2026, article changed between 14 and 16 October 2026 according to the authors' account) name both providers; the discrepancy concerns the earlier versions.
R (14 October 2026): "the privacy policy update is simply a mistake on our end. We updated the app’s privacy labels on the app store, and made sure any changes were clearly communicated in our Launch posts & release notes, but we didn’t push an update to the policy. We'll publish this update shortly to explicitly mention that freemium will contact RevenueCat & Superwall. Some articles on the website are outdated, and we're sweeping through them all in the same pass." I: on 14 October the vendor confirmed that D1 and the website articles were out of date and announced an update; both changes were made by 16 October 2026 (above). Of the channels named: the App Store release notes for 1.60.39 (D9) mention RevenueCat; the notes for 1.64.0 (D11) do not mention Superwall, the post D16 of the same day does; the history of the label: 3.9.
R (16 October 2026): Superwall has been in the app since version 1.64.0, "we included this in the launch post at the time"; "There is not a release note that mentions Superwall, only the launch post." I: of the vendor documents checked (D1, D4–D8, release notes D9–D11, label D13), none named Superwall before the October 2026 changes; post D16 and interview D15 (1 August 2026) did. Other vendor posts on Reddit and screens within the app were not checked for this. The reply narrows the statement of 14 October about communication "in our Launch posts & release notes".

### 3.2 What goes to Superwall on start

F: On every cold start the app sends 41 to 73 events to `collector.superwall.me` (window from 1 s before `app_launch` to 20 s after, or to the next `app_launch`; `tools/findings_table.py` counts with the same window), including `app_install` (first launch), `app_launch`, `app_open`, `session_start`, `app_close` on going to the background, `device_attributes`, `config_attributes`, `user_attributes` and paywall preloading events. The `user_attributes` events (45 in 9 files) carry only the Superwall alias, a `seed` value and the installation date; according to the SDK code they are created by the SDK itself, not by the app (no custom attributes, 3.11). The `device_attributes` event has 50–61 fields (37 events: 59 in 24, 61 in 2 on C8 after the paywall view, 58 in 2 on S11b, 51 in 2 on S01 and S17, 50 in 7 on A5, A8 and C8). On first launches, the events sent before the `enrich` response (within 0.2 s of `app_launch`; 50 fields on A and C, 51 on B) have no `ip*`/`demand*` fields; on later starts these fields are present from the first event. The 9 events with 50 fields (first launches in A5, A8, C8) or 58 fields (second start in S11b) have no `$appTransactionId` (H: sent before the transaction read completed). Fields include: `$vendorId` (IDFV), `$deviceId` (`$SuperwallDevice:` + IDFV), `$appTransactionId`, `$appInstallDate`, `$deviceModel`, `$osVersion`, `$deviceLanguageCode`, `$regionCode`, `$deviceCurrencyCode`, `$timezoneOffset`, `$interfaceStyle` (dark mode), `$radioType` (connection type), `$isLowPowerModeEnabled`, `$daysSinceInstall`, `$totalPaywallViews`, `$subscriptionStatus`, and, apart from the events sent before the `enrich` response, `$ipCountry`, `$ipCity`, `$ipV4`, `$demandScore`, `$demandTier` (see 3.5). Files: all `data/*.pub.har`, requests `POST /api/v1/events`. I (from D): this set of events and fields matches the standard behaviour of the Superwall SDK as described in its documentation and code (`sources/sdk-source-notes_2026-10-09.md`); the app does not use the available options to limit data collection (3.10).

D16 (r/strongbox post "Strongbox 1.64.0", u/strongbox-support, 26 January 2026 12:08 UTC, snapshot taken 9 October 2026, text: `sources/D16_post-text_2026-10-09.md`): "we get almost the same data we get from RevenueCat, which is the same as we get from Apple. The only addition is lifecycle events for the paywall itself, i.e paywall viewed, closed. These events all happen on the homepage, before any databases are opened, and there are no further manually tracked events."
D15 (statement by a representative of the vendor, "VP of Engineering at Applause, the company behind Strongbox" according to the video description, in a Techlore conversation published on 1 August 2026, 32:57–40:56 [^d15]): "Both of those are effectively in the most limited state they possibly can be. So to give you a bit more information on that, we don't have any identifiers that we track. So if you wrote me an email and you said, why is my subscription not working? I couldn't go into anywhere and find you. I have no way to know who you are." and "And the only information I get is how many people paid and how many didn't. I don't get telemetry on who did it, who they are, anything like that." and "the general rule that we followed throughout all of this is that we haven't added analytics."
I: the events sent on start cover the app lifecycle and the device profile, not only paywall events. This differs from the wording "the only addition…" (D16). The D15 statement is about what the vendor sees and whether the vendor can find a user; network traffic shows what the app sends. The app sends device and account identifiers to both services (3.3) and receives a location derived from the IP address (3.5); whether the vendor can or wants to use them to find a user does not follow from the traffic. The assessment "most limited state" cannot be checked from traffic; for a comparison with the options of both SDKs and with the app's public code see 3.10 and 3.11. Agreement with "before any databases are opened": see section 4, item 2, and 3.8.
R (14 October 2026): "Superwall allows us to grow our app with paywall testing, price testing, and running sales without shipping new builds. It isn't a tool for analytics, like Mixpanel, or Amplitude. […] Our usage of Superwall's events is just for triggering paywalls". I: the statement concerns the purpose for which the vendor uses the events; the set of events and fields sent is defined by the SDK and its options (3.10) and does not depend on that purpose. The App Store label itself declares the purpose "Analytics" (3.9).
R (16 October 2026), on the `isExternalDataCollectionEnabled` option: "This property generally describes which events we post-back to Superwall, and is used in reporting so we can see which paywalls drove conversions, i.e did a paywall get opened 1000 times but only 1 person paid." D1 (version of 15 October 2026): heading "Upgrade screens and related analytics"; "Superwall processes technical information, app-usage events and purchase status for these purposes." I: both statements describe measuring the performance of paywalls from events; for the comparison with "isn't a tool for analytics" (R, 14 October) and "we haven't added analytics" (D15) see 3.12.

### 3.3 The same device identifier to both services; persistent identifiers

F: The value of the `X-Apple-Device-Identifier` header in requests to RevenueCat equals the value of `$vendorId` in Superwall events on A, B and C (9 files with both fields, 9/9).
D17, D18 (source code of both SDKs in versions 4.15.3 and 5.21.1, GitHub, accessed 9 October 2026): both values come from `UIDevice.identifierForVendor` (IDFV); the Superwall `deviceId` = `"$SuperwallDevice:" + IDFV` (`sources/sdk-source-notes_2026-10-09.md`, line numbers and permalinks).
F: The IDFV on B changed between 1 October and the fresh installation on 3 October; on A it changed between 1 and 5 October, and between 5 and 8 October (three reinstallations) it stayed the same. Authors' account: from 3 October, Strongbox Pro and Strongbox Zero from the same vendor are also installed on A; no other apps from the vendor were installed on B or C. D: Apple documentation for `identifierForVendor`: the value stays as long as at least one app from the same vendor remains on the device. I: the observations agree with the documentation; the persistence of the IDFV on A comes from the presence of other apps from the vendor, not from the behaviour of the tested app.
F: `$appTransactionId`, sent to Superwall on every start, has the same value on A on 1, 5 and 8 October (despite the change of IDFV) and the same value on B on 1 and 3 October (despite the fresh installation and the change of IDFV). D: developer.apple.com/documentation/storekit/apptransaction/apptransactionid (accessed 3, 16 and 17 October 2026): "The App Store generates a single, globally unique `appTransactionID` for each Apple Account that downloads your app and for each family group member for apps that support Family Sharing. This value remains the same for the same Apple Account and app if the customer redownloads the app on any device […]". I: the value allows records from the same account to be linked after reinstallation, independently of the IDFV, and according to Apple's documentation also across devices.
F: RevenueCat returns `original_app_user_id` with the same label for B before and after the fresh installation (S01, 1 October; S17, 3 October) and for A on 5 and 8 October. I: the subscriber record is linked to the previous installation.

D13 (App Store privacy label, US and PL, snapshot taken 8 October 2026 (US, `sources/D13_app-store-listing_2026-10-08.pdf`) and 9 October 2026 (PL, Wayback Machine: https://web.archive.org/web/20261009193211/https://apps.apple.com/pl/app/strongbox-password-manager/id897283731?l=pl)): "Data Not Linked to You: Purchases"; "Dane, które nie są z Tobą powiązane: Zakupy" (Polish storefront label, in English "Data Not Linked to You: Purchases"; same content as the US label). Screenshot from the App Store app on macOS (10 October 2026, `sources/D13-macAppStore_2026-10-10.png`): "Data Not Linked to You" → purpose "Analytics" → "Purchases: Purchase History"; no other purposes or types. D9 (release notes 1.60.39, 12 May 2025): "The exact same information is provided to RevenueCat as it would be directly to Apple, and no extra analytics or tracking is added as a result of this change."
I: the label does not mention device identifiers (comparison with Apple's definitions: 3.9). Whether the IDFV and `appTransactionId` fall within "the exact same information … as … Apple" depends on interpretation; Apple receives these values within its own store, here they go to two third parties.
R (14 October 2026): "In terms of tying data together, we do not do any extra merging of users. Apple's receipts contain some identifiers, which let you restore someone's subscription across devices & ensure they get the correct trial entitlements etc, and this is strictly used for that purpose. This makes sure we don't show a paywall to someone who already paid." I: consistent with the absence of `identify()` and of custom user attributes (3.11; section 4, item 11). The statement describes what the vendor does with the identifiers; the traffic shows that `$appTransactionId` goes to Superwall and the receipt to RevenueCat.
D1 (version of 15 October 2026): "These services use SDK-generated identifiers and may process device identifiers to associate purchase status and related events with an installation or device. The absence of a Strongbox account does not make this information anonymous." I: the new policy describes device identifiers; it does not name the Apple Account-level identifier (`$appTransactionId`).

### 3.4 First launch: Apple AdServices attribution token, ATT consent status, receipt

F: On every first launch after installation (S01, S17, A5 ×2, A8, C8; 6 observations) the app sends to RevenueCat `POST /v1/subscribers/<id>/adservices_attribution` with an Apple AdServices token (560 characters), and `POST /v1/receipts` requests with the App Store receipt and the attribute `$attConsentStatus` (App Tracking Transparency consent status). This includes device C, which never made a purchase (1 receipt, response without a product). Receipt posts per first launch: on A and B 4 (S01: 5), of which 3 with the initiation source `restore` within 2 s and 1–2 from the StoreKit transaction queue; on C 1 (`restore`). In the app's public code the first launch calls one restore and two purchase syncs (3.11); according to the RevenueCat SDK code, the later posts are skipped when the receipt contains no transactions and the cached subscriber record already has an original purchase date, which matches C.
D18a: in the RevenueCat SDK 5.21.1 code, token collection is off by default (`automaticAdServicesAttributionTokenCollection = false`) and starts only when the app calls `enableAdServicesAttributionTokenCollection()`; the RevenueCat documentation "Apple Search Ads attribution" (accessed 9 October 2026) describes it the same way. F: in the Superwall configuration, `attribution_options.apple_search_ads.enabled = false`.
I: sending the token means the app switched this function on; it is not the SDK's default behaviour. The token is used to determine whether the installation came from an Apple Search Ads campaign. It was not mentioned in the versions of D1 and D4–D8 in force at the time of the study; the new versions mention Apple Ads attribution (below). The D13 label does not mention it; D9 does not settle whether it is "the exact same information". The value of `$attConsentStatus` is `denied` in 22/22 receipts; according to the SDK 5.21.1 code this is also the value returned when the app does not include the App Tracking Transparency framework, and the app's public code does not include it (3.11). With the framework present, `denied` would also be the value after a refusal or when the user has turned off "Allow Apps to Request to Track" in the system settings, so the value alone does not settle the question. I: based on the app's public code and the vendor's reply (below), the app does not ask for ATT consent, and `denied` does not mean the user refused.
R (14 October 2026): "the Ad services token is used to tell us which Apple Search Ad someone saw before they purchased ( we run ads on the App Store like most iOS apps ). We're not using ATT, so that property just stays as false for everyone." I: the vendor confirms that the app enabled the token, names its purpose (Apple Search Ads attribution) and confirms the absence of ATT; the value observed in the receipts is `denied`, the SDK's name for that state. The token is sent on every first launch, including on C, which made no purchase.
D1 (version of 15 October 2026): "The iOS freemium app also uses RevenueCat for Apple Ads attribution, associating installations and purchases with advertising campaigns." D4–D8, new version: "The iOS freemium edition also enables Apple Ads attribution through RevenueCat."

### 3.5 Location from the IP address and demand score

F: On every start the app sends `POST enrichment-api.superwall.com/api/v1/enrich` with a device profile; the response contains the fields `ipCountry`, `ipRegion`, `ipCity`, `ipContinent`, `ipV4`, `ipV4ObservedAt`, `demandScore`, `demandTier`. The app sends these values back in later events (`device_attributes`, `enrichment_complete`; the demand score and tier also in `paywall_open`). 20 responses with content in 9 files (A0: connection only). The values are replaced with labels or masked in the published files; `ipV4ObservedAt` is a timestamp and is shifted like the other times of the file.
D: the Superwall documentation "App Privacy Nutrition Labels" (accessed 9, 10, 16 and 17 October 2026) lists `ipCountry`, `ipCity`, `ipRegion`, `ipContinent`, `ipTimezone` as data "derived from the device's IP address"; "Demand Score" (docs/dashboard/dashboard-demand-score, accessed 10 and 17 October 2026): "Demand Score is a number from 1 to 100 assigned to each user by Superwall on every app open."; "Some signals used include device model, OS version, device age, App Store country, connection type, number of app opens, and paywall views."; the documentation mentions no way to switch it off, and the SDK 4.15.3 code calls `enrich` unconditionally (3.10).
D1 (privacy policy, version in force at the time of the study, section "How do you handle location data?"): "The Application does not use or collect any data related to your geographic location."
I: the service assigns the device a location derived from the IP address (country, region, city) and a demand score; the app accepts these data and sends them back in events. No access to GPS location was observed. We leave it to the reader to judge whether a location derived from the IP address was "data related to your geographic location" in the sense of D1; no declaration mentioned the demand score before the documents were changed (8–16 October 2026).
D1 (version of 15 October 2026): "Superwall processes technical information, app-usage events and purchase status for these purposes. It may derive approximate location from your IP address and estimate the likelihood of a purchase. This is not GPS location tracking." D19 (Apple, accessed 16 October 2026): "You collect and store IP address from your users. Declare the relevant data types based on how you use IP address, such as precise location, coarse location, device ID, or diagnostics."
R (16 October 2026): "These are simply not used. They're something you can use to work out "is this person likely to subscribe" or not, but we don't use them." F: none of the 10 paywall rules in `static_config` (6 responses with content) refers to `demandScore`, `demandTier` or the `ip*` fields; the rules use only the entitlement state and the storefront country. I: the rules evaluated on the device agree with the statement; use of these values on the service's side (dashboard, reports) is beyond the reach of this method. Regardless, Superwall computes them on every start and the app sends them back to it, with no switch in this SDK version (3.10).

### 3.6 Paywall preloading

F: On the first launch after installation the app downloads paywall resources: 127–206 requests to `user-content.superwalleditor.com`, `fonts.gstatic.com`, `fonts.googleapis.com` and `js.stripe.com` (S01 163, S17 198, A5 206 and 176, A8 127, C8 160; counted as HAR entries to these four hosts, including CONNECT). On later starts the HAR contains 0–1 such entries per start (C8: one CONNECT to `js.stripe.com` on each of starts 2 and 3; A0, an export with a domain filter and one entry per host: 3 CONNECT). In the packet captures, one short connection to each of `user-content.superwalleditor.com`, `fonts.gstatic.com` and `fonts.googleapis.com` appears in T2 (without Proxyman) on each of the 3 starts, in S18 and A0 on the single start, and in S02, S11b and T3 (with Proxyman) only on the first start of the capture; on the later starts of S02, S11b and T3 there is no connection to any resource host (`data/pcap-extracts/*_tls-connections.csv`). In T2 each `user-content` connection received about 5 kB and each `fonts.googleapis.com` connection 6.8–8.2 kB; `fonts.gstatic.com` used QUIC and is not in the connection statistics (`T2_tcp-conversations.txt`). The events `paywallPreload_start`/`_complete` and `paywallWebviewLoad_*` occur on every start. In A8 the paywall webview fetches `js.stripe.com/clover/stripe.js` (1.1 MB, Referer header from `user-content.superwalleditor.com`); in A5 and C8, at the same time, there are connections to `m.stripe.com` and `m.stripe.network` (CONNECT only; attributed to the app by timing and the Referer header; these entries are in the authors' HAR files but not in the published ones, which keep only the examined hosts).
I: paywall resources (including Google Fonts and the Stripe script) are downloaded before the user sees any paywall, including on the device with an active subscription (A). D21 (Stripe documentation "Advanced fraud detection", docs.stripe.com/disputes/prevention/advanced-fraud-detection, accessed 10 October 2026): Stripe.js collects "risk factors about device characteristics and user activity" and transmits them "by periodically making requests to the `m.stripe.com` endpoint"; switching this off requires the parameter `advancedFraudSignals=false` in the script URL, which the fetched URL does not have. The content of the Stripe connections was not decrypted; what Stripe.js sends from the paywall webview remains unestablished (section 5).
R (16 October 2026): "Paywalls are always pre-loaded because an existing pro user may not stay pro at run-time, for example, their sub may expire, or their family share may be removed by someone else. We pre-load to make sure users don't have to stare at a loading screen before paywalls."; on the resource hosts: "The revised policy specifically mentions Superwall & RevenueCat, it does not explicitly list fonts etc." D1 (version of 15 October 2026): "Upgrade screens may load resources from Superwall and third-party hosts." I: the reply explains preloading (a loss of entitlement occurred on B on 3 October); it does not cover the device profile and `enrich`, which the SDK sends for a subscriber regardless of preloading (3.10; section 4, item 3); the vendor gave the purpose of the lifecycle events separately (checking for entitlement changes, 3.8). Google Fonts and Stripe are not named.

### 3.7 Paywall configuration

F: The response to `GET api.superwall.me/api/v1/static_config` contains 7 paywalls and 7 triggers (`database-unlock`, `Nudge`, `Onboarding`, `retention-discount`, `session_start`, `Settings`, `transaction_abandon`) with 10 rules in total; every rule contains the condition `size(device.activeEntitlements) == 0`, one of them additionally a storefront country condition. The `config_attributes` event sent by the app contains `$isExternalDataCollectionEnabled: true`.
D: the Superwall documentation for `SuperwallOptions` (accessed 3 October 2026): `isExternalDataCollectionEnabled` is `true` by default. SDK 4.15.3 code (accessed 10 October 2026): the value `false` blocks only `trigger_fire`, `user_attributes` and the app's own events (5–10 % of the events in the examined files); `device_attributes`, `enrich` and the lifecycle events are still sent. A switch covering all events (`eventTrackingBehavior`) appeared in Superwall 4.16.0 (30 June 2026); it does not cover the `enrich` request (device attributes with the IDFV), which has no switch in any version up to 4.18.0 (15 October 2026). The tested app version (App Store, 1 September 2026) contains 4.15.3; before that date Superwall had also released 4.15.4, 4.16.1, 4.16.2 and 4.16.3 (github.com/superwall/Superwall-iOS/releases, accessed 17 October 2026).
I: paywalls can be triggered at the places named `database-unlock` and `Settings`, that is after a database is opened, but only for users without an active entitlement. The app uses neither this option nor the other limiting options (3.10); the app's public code does not register the triggers `database-unlock` and `retention-discount` (3.11).
R (16 October 2026): "This cannot currently be turned off by the user. This property generally describes which events we post-back to Superwall […]. External data collection does not mean another third party or similar, it just refers to the events we post-back." I: the description of the option agrees with the SDK code and documentation; the question whether the vendor considered the available restrictions on event collection was not answered.

### 3.8 A displayed paywall and a trigger after unlock

F: On C (first launch, 8 October), 22 s after `app_install`, the app sent `Onboarding`, `trigger_fire` (result `present`), `paywall_open`, `paywall_page_view`; after 9 s, `paywall_decline` and `paywall_close`. Authors' account: the paywall was closed by the user. The only paywall in 24 starts.
F: On B in T3, cycle 3 (3 October, about 2 min after the third cold start), after the database was unlocked the app sent the event `Nudge` (`$is_standard_event = false`); the configuration returned a decision to display a paywall (`trigger_fire`, `$result = present`), followed by a `confirm_assignments` request; no display event was recorded. The published `T3.pub.har` ends with the `Nudge` request, and the T3 packet capture extracts end within 1 s of it; the authors' HAR export contains one later entry, about 3 min later, to a host outside the scope (removed from the published file), so the recording continued for about 3 min (authors' account). In T3 only one `app_close` was recorded for the three cycles, although the app went to the background in each; H: events still queued on the device at the end of the recording were not sent, so the missing display event cannot be told apart from an unsent one. Authors' account: the user did not observe a paywall.
D15 (representative of the vendor [^d15]): "I have a very firm policy that nothing like this is allowed to be after the database is opened. So Strongbox's paywalls and syncing purchases and so on happens when you open the app. It's not when you open a database, it's when you open the app."
I: `Nudge` is an event sent by the app after a database is opened; in Superwall's vocabulary such an event is a place where a paywall can appear. Whether it falls within "lifecycle events for the paywall itself" (D16) depends on interpretation. Against the wording "before any databases are opened" (D16) and "nothing like this is allowed to be after the database is opened" (D15; "like this" refers to paywalls and purchase syncing), the difference concerns one observation. The configuration also provides the triggers `database-unlock` and `Settings` (3.7), which did not occur in the 6 unlocks. In the app's public code (1.65.0) `Nudge` is called after a tap on the "Upgrade to Pro" banner on the database list, not by the unlock itself (3.11); authors' account (10 October): a tap on the banner in T3 cannot be ruled out. I: the observation most likely reflects a user action, not the unlock itself; the missing display event remains unexplained.
R (14 October 2026): "we can trigger a paywall on app launch, which we do for sales, or when someone taps our "nudge" banner that says they could get better experiences with PRO. We've purposefully ensured we're not sending events with the database unlocked." I: consistent with the `session_start` trigger (3.7) and with `Nudge` called from the banner (3.11). The last sentence agrees with the data for the app's own events (none in the 6 unlocks apart from `Nudge`); the SDK's lifecycle events `app_open` and `app_close` were sent on C while a database was unlocked (section 4, item 2), independently of the database state.
R (16 October 2026), on `app_open` and `app_close` with a database unlocked: "We believe so, yes. The app lifecycle events are used as stated to determine subscription updates, i.e, if someones entitlements have changed since they last opened the app. It does not contain any database information, or that the database is opened, and we do not send any events like "database_open" or "database_closed"." F: no events with database-related names were recorded (section 4, item 2). In all 79 events (47 `app_open`, 32 `app_close`, 9 files with content; one `app_close` in S11b was sent twice, in two requests with the same event identifier, and is counted once), the parameters are only `$app_session_id`, `$event_name`, `$is_standard_event`, `event_name`. I: the content of the events agrees with the statement; the events reveal when the app is entered and left, not the state of the database.

### 3.9 The App Store privacy label and Apple's definitions

F: The label (D13, snapshots of 8, 9, 10 and 18 October 2026) contains one data type, "Purchases", in the category "Data Not Linked to You"; the subtype "Purchase History" and the purpose "Analytics" are visible only in the snapshot of 10 October 2026 from the App Store app on macOS; the web pages of 8, 9 and 18 October show only the type without expanding "See Details"; the archived HTML of the Polish page of 9 October (Wayback Machine, 20261009193211) also contains the subtype "Purchase History" and the purpose "Analytics" behind that control. No other types or purposes.
D (history of the label; snapshots of apps.apple.com/us/app/strongbox-password-manager/id897283731 in the Wayback Machine, read on 16 October 2026): 22 April 2025 (version 1.60.35 shown on the page, although 1.60.36 had been released on 27 March 2025 according to the version history, `sources/D9-D11_appstore-version-history_2026-10-09.txt`; the archived page may have been out of date) "Data Not Collected", "The developer does not collect any data from this app."; 4 September 2025 (1.61) "Data Not Linked to You: Purchases"; 8 January 2026 (1.63.2), 5 March 2026 (1.64.1), 3 September 2026 and 7 October 2026 (1.65.2): the state described above. Snapshots: https://web.archive.org/web/20250422150213/https://apps.apple.com/us/app/strongbox-password-manager/id897283731, https://web.archive.org/web/20250904033117/https://apps.apple.com/us/app/strongbox-password-manager/id897283731, https://web.archive.org/web/20260108191434/https://apps.apple.com/us/app/strongbox-password-manager/id897283731, https://web.archive.org/web/20260305192347/https://apps.apple.com/us/app/strongbox-password-manager/id897283731, https://web.archive.org/web/20260903025419/https://apps.apple.com/us/app/strongbox-password-manager/id897283731, https://web.archive.org/web/20261007214753/https://apps.apple.com/us/app/strongbox-password-manager/id897283731. I: the label changed between 22 April and 4 September 2025; RevenueCat was added within that interval (1.60.39, 12 May 2025); after Superwall and crash reporting were added (1.64.0, 26 January 2026) there is no change in the snapshots up to 7 October 2026. On 18 October 2026 the label was unchanged (snapshots of the US and Polish listings, `sources/D13_app-store-listing_2026-10-18.pdf`, `sources/D13-PL_app-store-listing_2026-10-18.pdf`).
D19 (Apple, "App privacy details on the App Store", developer.apple.com/app-store/app-privacy-details/, accessed 10 and 16 October 2026): "You need to identify all of the data you or your third-party partners collect, unless the data meets all of the criteria for optional disclosure"; "Device ID: Such as the device's advertising identifier, or other device-level ID"; "Coarse Location: Information that describes the location of a user or device with lower resolution than a latitude and longitude with three or more decimal places"; "Product Interaction: Such as app launches, taps, clicks, scrolling information […] or other information about how the user interacts with the app". The exemption from disclosure requires, among other things, that collection occurs "only in infrequent cases that are not part of your app's primary functionality, and which are optional for the user". "Not Linked" requires that the developer and partners do not link the data to identity "via their account, device, or other details"; the same section adds: "Data collected from an app is often linked to the user's identity, unless specific privacy protections are put in place before collection to de-identify or anonymize it" and "Note: "Personal Information" and "Personal Data", as defined under relevant privacy laws, are considered linked to the user." (accessed 17 October 2026). On the IP address: 3.5.
D20 (Superwall, "App Privacy Nutrition Labels", accessed 9, 10, 16 and 17 October 2026): the minimum for an app with Superwall is "Purchases" with the purposes "Analytics" and "App Functionality"; the page lists, among others, `vendorId`, `ipCountry`, `ipCity`, `ipRegion`, `totalPaywallViews` as collected. RevenueCat ("Apple App Privacy", revenuecat.com/docs/platform-resources/apple-platform-resources/apple-app-privacy, accessed 16 October 2026): "If you are using RevenueCat, you must disclose that your app collects 'Purchases' information", with the purposes "Analytics" and "App Functionality"; identifiers when purchase history is linked to identity (Device ID for advertising identifiers such as the IDFA); "Usage Data | If you are using analytics SDK's such as Mixpanel, Firebase, PostHog, or Amplitude, this may be required" (accessed 17 October 2026; Product Interaction belongs to the category Usage Data; Superwall is not named). Neither provider's guidance names the types Device ID (apart from advertising identifiers), Coarse Location or Product Interaction.
I: the traffic contains data that match Apple's definitions: the IDFV to both services on every start (Device ID), city and region derived from the IP address, returned by Superwall and sent back by the app (Coarse Location), launch, session and paywall events (Product Interaction). None of these types is declared. Collection occurs on every start and without an option for the user, so the condition "infrequent cases […] optional for the user" is not met; whether the remaining conditions of Apple's exemptions apply, and whether the data are in fact linked to identity on the services' side, the authors do not decide.
I: the label has fewer purposes than the minimum in the guidance of both providers (no "App Functionality"). The providers' guidance does not name the three types; the requirement follows from Apple's definitions (D19). RevenueCat's guidance makes Usage Data conditional on the use of an analytics SDK; whether Superwall counts as one is a matter of interpretation (the vendor: "It isn't a tool for analytics", R, 14 October 2026). The label itself declares the purpose "Analytics" for purchase data, which in Apple's vocabulary ("Using data to evaluate user behavior […] or measure audience size or characteristics") is analytics. The label is the developer's declaration, not verified by Apple (notice on the page).
I: the new policy (15 October 2026) describes device identifiers, app-usage events and approximate location derived from the IP address (3.3, 3.5) and states that the absence of an account "does not make this information anonymous"; the label places the data in the category "Data Not Linked to You". Pseudonymous data are not anonymous but need not be linked to identity; the Superwall guidance (D20) notes, on the question of identifying users, "Note that the Superwall SDK does not do this.", and RevenueCat requires a linking disclosure for a custom app user ID tied to contact details, which the app does not use (3.11). Whether the two conflict depends on Apple's definition of linking; the authors set the two wordings side by side without deciding.
R (14 October 2026): "We updated the app’s privacy labels on the app store". R (16 October 2026): "When we added these, we checked the guidance from the various providers to see what they reccomended to add. If this changes, we'd add more labels to the app store"; "We do not have the exact date these were recorded to hand, but we updated these when we added RevenueCat to the app." I: the history of the label is consistent with the reply (a change within the interval that includes the addition of RevenueCat); adding Superwall did not change it. Neither provider's guidance names the three types (above), which agrees with the reply, apart from RevenueCat's conditional entry for Usage Data; both, however, require the purpose "App Functionality", which the label does not have. The reply does not address the three data types in Apple's definitions.

### 3.10 The options of both SDKs and the "most limited state"

F/D: The authors compiled the options of the Superwall-iOS 4.15.3 and purchases-ios 5.21.1 SDKs that affect the data sent from the device (default value from the SDK code with line numbers, value used according to the traffic): `sources/sdk-options_2026-10-10.md`. Summary:
- Superwall: the app sends `config_attributes` with 22 options, identical in 20/20 starts. Limiting options available and unused: `isExternalDataCollectionEnabled` (partial effect, 3.7), `paywalls.shouldPreload` (would remove paywall preloading and about 35 of the 41–73 events per start, 3.6), `shouldBypassAppTransactionCheck` (would remove `$appTransactionId`; described in the SDK changelog as "useful in testing environments"). Expanding options: none enabled (no `identify()`, no custom user attributes, no IDFA; the `user_attributes` events in the traffic are created by the SDK, 3.2). No switch in the SDK: `enrich` with location and demand score, `device_attributes`, IDFV, lifecycle events.
- RevenueCat: the limiting settings (anonymous user, no subscriber attributes, diagnostics off) are the defaults. Expanding settings enabled by the app: the AdServices token (3.4) and, on every first launch, one restore and two purchase syncs, including without a purchase (C); on A and B this produced 3 receipt posts with the initiation source `restore` (plus 1–2 from the StoreKit queue), on C one post (3.4). No switch: the IDFV in the header, automatic requests on start.
- Versions: Superwall 4.16.0 with a switch covering all events (not the `enrich` request, 3.7) was released on 30 June 2026; the tested app version was released on 1 September 2026 with 4.15.3.
I: within what depends on the app, no limiting option is used and two expanding ones are enabled; most of the observed traffic, however, has no switch on the app's side in these SDK versions. Settings on the services' dashboards are beyond the reach of this method. The vendor stated that the user currently cannot turn the event collection off ("This cannot currently be turned off by the user", R, 16 October 2026, 3.7).

### 3.11 The app's public code

F: The vendor's repository (github.com/strongbox-password-safe/Strongbox, branch `master`, last commit 17 July 2026 labelled "1.65.0", accessed 10 October 2026) has no tags, no Xcode project and no package version file; the class that initialises RevenueCat (`RCStrongboxBridge`) is absent from the repository (only its calls are present). I: this class passes the API key and the flag enabling the AdServices token (the SDK default is off, the token is sent, and the vendor confirmed enabling it, 3.4). The tested binary is 1.65.2; conclusions from the code concern the 1.65.0 state.
F: `Purchases/SuperwallService.swift`: `SuperwallOptions()` with one change (`storeKitVersion = .storeKit1`); a custom purchase controller; no `identify()` and no calls setting user attributes; the app registers three placements: `Onboarding`, `Settings` and `Nudge` (after a tap on the "Upgrade to Pro" banner on the database list). `Packages/StrongboxPurchases/…/RCStrongbox.swift`: anonymous `appUserID`, StoreKit 1 (the SDK default is StoreKit 2), the AdServices token enabled by a parameter passed from the missing file; `syncPurchasesIfNeeded()` calls `restorePurchases()` followed by `syncPurchases()`, and a second `syncPurchases()`, each once until a flag in the app's settings storage is set (a reinstallation clears it); a subscriber attributes function exists but is never called in the public code. The App Tracking Transparency framework is absent from the repository. `StrongBox/AppDelegate.m`: in the branch for the Pro bundle, RevenueCat is initialised when the build flag `SUBSCRIPTIONS` is defined; whether the flag is defined in Pro builds cannot be determined without the Xcode project.
I: the triggers `database-unlock` and `retention-discount` from the configuration are not registered by the 1.65.0 code, so they cannot fire in it; consistent with the absence of such events in the 6 unlocks. The configuration of both SDKs in the code is limited to the StoreKit version. The repository as it stands does not allow the app to be built or all configuration decisions to be verified (D14).
R (16 October 2026): "This is slightly behind, but most code is visible. Only small commercially sensitive elements are omitted, and some files that would make it easy for copycats to clone our app." I: consistent with the observation; the omitted files include the one that passes the RevenueCat API key and enables the AdServices token (3.4); the vendor confirmed enabling the token on 14 October 2026.

### 3.12 Declarations and findings side by side

| Declaration | State at the time of the study (documents of 8 October 2026) | After the document changes (by 16 October 2026) and the reply of 16 October 2026 |
|---|---|---|
| D1 "does not use vendors or analytics providers" | differs from the wording (3.1, 3.2) | the new version names RevenueCat and Superwall; the discrepancy no longer applies (3.1) |
| D1 "does not use or collect any data related to your geographic location" | depends on how the location derived from the IP address is classified (3.5) | the new version: "may derive approximate location from your IP address"; the question of classification no longer arises (3.5) |
| D16 "The only addition is lifecycle events for the paywall itself" | differs from the wording (3.2) | post as of 9 October 2026; the new policy describes a wider scope (3.2) |
| D16 "This is only in the free app" | refers to the in-app-purchase variant, which includes paying subscribers; the flow on A with an active subscription is the same as on B and C (3.1, 3.2; section 4, item 3) | the new policy: "This integration can run even when you already have an active Pro subscription" (3.1) |
| D16 "no further manually tracked events", "before any databases are opened"; D15 (interview) "nothing like this is allowed to be after the database is opened" (paywalls, purchase syncing) | one observation, most likely triggered by the user (banner, 3.8); otherwise agrees (section 4, item 2) | R: lifecycle events with a database unlocked are covered by the assurance, without database data; agrees with the content of the events (3.8) |
| D15 (interview) "we don't have any identifiers that we track" | device and account identifiers are sent (3.3); whether the vendor reads them cannot be determined with this method | the new policy: "may process device identifiers […] does not make this information anonymous" (3.3) |
| D15 (interview) "most limited state" | the vendor's assessment; in the app's code no limiting option is set, three available ones are unused, two expanding ones are enabled; most of the traffic has no switch in these SDK versions (3.10, 3.11) | R: the user currently cannot turn the event collection off; the question about considering the restrictions was not answered (3.7) |
| D15 (interview) "we haven't added analytics" | depends on the definition; the App Store label itself declares the purpose "Analytics" (3.9); session and paywall events go to Superwall, as does `demandScore`, computed according to the documentation from the number of app opens and paywall views (3.2, 3.5) | the new policy: heading "Upgrade screens and related analytics", "measure their performance"; R: the events are used to report paywall conversions (3.2) |
| D8 "None of these connections send any of your databases or personal identifying information" | depends on how the IDFV, `appTransactionId` and the location derived from the IP address are classified (3.3, 3.5) | the new versions name device identifiers and the location derived from the IP address (3.3, 3.5) |
| D9 "exact same information … as … Apple" | depends on interpretation (3.3, 3.4) | release notes unchanged |
| D13 label "Purchases / Purchase History", purpose "Analytics" | does not contain the types that match Apple's definitions of Device ID, Coarse Location and Product Interaction (3.9) | unchanged since 8 January 2026, including after Superwall was added (Wayback up to 7 October 2026) and in the snapshots of 18 October 2026; the new policy describes data the label does not list (3.9) |
| D4–D8 list of connections | did not cover RevenueCat, Superwall, Google Fonts, Stripe | the new version names RevenueCat, Superwall, Sentry and "third-party hosting and content services"; Google Fonts and Stripe are not named (3.1, 3.6) |

## 4. What agrees with the declarations

1. **Sentry.** F: requests to `*.ingest.us.sentry.io` occur in 4 of the 10 HAR files: in S17 and S18 as POST requests whose `release` field names the Proxyman for iOS bundle, in A0 and S02 as single CONNECT entries without a bundle. I: the A0 and S02 entries also come from Proxyman for iOS, because TLS connections to Sentry occur in exactly the four captures with Proxyman for iOS (A0, S02, S17, S18; section 2) and in no other. In the packet captures without Proxyman (T1, T2) the Sentry name does not occur. F: DNS queries for `sentry.io` itself, without any TLS connection to Sentry, occur in S01 (1, in the same millisecond as the app's first queries for `duckduckgo.com` and `api.revenuecat.com`), S02 (3) and S11b (1) (`data/pcap-extracts/*_dns.csv`); their origin is not established (H: a connectivity check by a Sentry SDK). The HAR entries for Sentry are not in the published files (out-of-scope hosts). Agrees with D11 and D16 within the scope examined (no crashes during the tests). The vendor explains the wording "automatic opt-in crash reporting" (D11): on a fresh installation crash reporting is on by default, for existing users it stays off (R, 16 October 2026); the new policy (D1, 15 October 2026) says that crash reporting "is enabled by default on a fresh installation and can be turned off in settings", without mentioning existing users. Consistent with the authors' account (the switch was on after a fresh installation).
2. **Working with a database.** In the 6 database unlocks (B: S18 1, T3 3; C: 2) no event with a database-related name was sent (`database-unlock` from the configuration did not occur). On C, between creating the database and locking it (about 6.5 min according to the screen recording), only `app_close` and `app_open` went to Superwall. Exception: `Nudge`, 3.8. The app's public code does not register the `database-unlock` trigger (3.11). The `app_open` and `app_close` events contain only a session identifier, the event name and the standard-event flag (3.8).
3. **Paywall rules** require no active entitlement; device A, with an active subscription, received no decision to display a paywall in any of its 11 starts with recorded content (12 starts in total; A0 without content). The data flow to Superwall on A is the same as on B and C (3.1, 3.2) and, for a user with an active entitlement, serves no function visible to that user; H: default SDK behaviour independent of the subscription status. The vendor explains paywall preloading by a possible loss of entitlement while the app is running (R, 16 October 2026, 3.6); the new policy (15 October 2026) states that the integration "can run even when you already have an active Pro subscription".
4. **Favicons** (S18): connections to `icons.duckduckgo.com` and to the hosts from the entries' addresses (`strongboxsafe.com`, `proton.me`) only after the option was switched on; agrees with D6 (version of 8 October 2026) and with the new version of the article. Content not decrypted.
5. **Connectivity test** `duckduckgo.com`: on A, and in S01 on B, a DNS query when the app comes to the foreground, no content sent; agrees with D5 (version of 8 October 2026) and with the new version of the article.
6. **No connections to HIBP or SimpleLogin** with the options off (not tested with them on).
7. **No IDFA (Identifier for Advertisers)** in requests and no identifying cookies; the ATT consent status sent to RevenueCat is `denied`, without an IDFA; according to the SDK code and the app's public code this follows from the absence of the ATT framework, that is, the app does not ask for ATT consent at all (3.4, 3.11).
8. **App closed** (T1, 5 min): no DNS queries or connections to the RevenueCat, Superwall or paywall resource hosts.
9. **Both providers were named publicly by the vendor** before the study: RevenueCat in the release notes for 1.60.39 (D9, 12 May 2025), Superwall in post D16 (26 January 2026), both in interview D15 (1 August 2026).
10. **The App Store receipt** sent to RevenueCat matched the item "App Store Receipt" in article D4 (version of 8 October 2026) as to the kind of data; the difference was the recipient (RevenueCat instead of Apple alone). The new version of the article names RevenueCat as a recipient of purchase information.
11. **No user identification and no custom attributes** in either SDK: an anonymous RevenueCat identifier, a Superwall alias, no `identify()` and no subscriber attributes in the traffic or in the public code; the Superwall `user_attributes` events contain only values created by the SDK (alias, `seed`, installation date; 3.2, 3.10, 3.11). Consistent with the new policy: "we do not supply RevenueCat or Superwall with a custom Strongbox account identifier".
12. **The vendor's replies.** The reply of 14 October 2026 (section 6) agrees with the traffic and the public code on: no ATT, no user identification or merging of users, the AdServices token enabled by the app for Apple Search Ads attribution, `Nudge` from the banner, paywalls on launch only for sales; it acknowledges that the privacy policy and the website articles are out of date. The reply of 16 October 2026 agrees with the data and documents on: Superwall since 1.64.0 and named in no release note (D11; it was named in post D16 and in interview D15, 3.1), the repository missing some files (3.11), lifecycle events without database data (3.8), the label changed within the interval that includes the addition of RevenueCat (3.9); the paywall rules do not use the demand score or the location derived from the IP address (3.5).
13. **The new versions of the privacy policy and the article** (policy 15 October 2026, article between 14 and 16 October 2026 according to the authors' account) describe both providers, device identifiers, app-usage events, approximate location derived from the IP address, an estimate of purchase likelihood, Apple Ads attribution, operation with an active subscription and crash reporting on by default; they do not name Google Fonts, Stripe or `$appTransactionId` (3.1, 3.3, 3.5, 3.6).

## 5. Limitations and single observations

- **The HAR is not complete.** The packet capture shows TLS connections (resource hosts, Google Fonts) on starts for which the HAR has no entries. "Absent from the HAR" does not mean no connection; claims of absence rest on the packet capture or are marked as such.
- **Exports with a domain filter** (A0, S02, S18) contain only selected hosts.
- **HTTP/2 coalescing** in T2 is a hypothesis consistent with the addresses and the volume, not confirmed by content; in the captures with Proxyman the app uses separate connections (3.1).
- **Clocks:** on A on 1 October the HAR was about 24 s ahead of the PCAP; on B they agreed within 1 s. The end of a capture limits the observation of delayed events.
- **Traffic of other apps** (iCloud, Google, others) occurs in the captures. It was excluded from the HAR files by host and by the app bundle declared in the request, from `*_tls-connections.csv`, `*_dns.csv` and `*_dns-answers.csv` by a host-name pattern, and from the `*_sni-new.txt` lists by a list of the hosts named in this report (the first line gives the number of names removed; `proxyman.com` is kept as the marker of the authors' tool, section 2). From the `*_syn-quic.csv` files the rows of other apps (server addresses that no host of the report pointed to) were removed; the remaining rows are those of the hosts named in this report. From `T2_tcp-conversations.txt` the conversations with servers of other apps and services (11) were removed; the remaining 35 are those with the addresses of the hosts named in this report and those inside the local network (`data/pcap-extracts/README.md`).
- **Region of device B:** the app sends a region code different from that sent by A and C; the code is the same on 1 October without the VPN (S01) and on 3 October with it (S17, S18, T3), so it does not depend on the VPN. The authors saw the region Poland in B's settings. Cause not established; no effect on the findings.
- **Effect of the tools:** in T3 (with Proxyman) and T2 (without), on the same device on the same day, the captures differ in the set of visible connections (host names `collector` and `subscriptions-api`, 3.1; resource hosts on later starts, 3.6); the presence of a proxy may change the app's behaviour or the capture.
- **No packet capture** for A5, A8 and C8: claims that something is absent in these runs rest on the HAR alone.
- **Shifted timestamps** in the published files prevent comparisons of times between files and with the correspondence.
- **Single observations:** `Nudge` (1×), the paywall on C (1×), `POST …/redeem` (5×, on first launches and in S18).
- **Our own correction:** in the first letter to the vendor (2 October) the authors wrongly attributed the Sentry traffic to the app; it came from Proxyman for iOS. Corrected on 8 October (section 6).
- **What cannot be established from these data:** whether the vendor reads the identifiers and the location in the services' dashboards, whether the vendor switched individual functions on deliberately (apart from the AdServices token, 3.4), what the services do with the data on their side, whether the data of both services are combined, how Strongbox Pro and Zero (according to the vendor, without Superwall and RevenueCat, R, 16 October 2026; the public code contains a RevenueCat initialisation for the Pro bundle under a build flag, 3.11) and the macOS version behave, and why, apart from paywall preloading and the lifecycle events (explained by the vendor, 3.6, 3.8), the device profile and `enrich` go to Superwall for a subscriber with an active entitlement, to whom no paywall can be shown (section 4, item 3).
- **Sample:** 3 devices, 24 starts, 6 unlocks, 4 test days (1, 3, 5 and 8 October). Tests without the HIBP, SimpleLogin and sync options active.
- **Content** of the connections to `m.stripe.com`, `m.stripe.network`, favicons and Apple hosts was not decrypted (3.6); the `m.stripe.*` hosts were not on the decryption list.
- **The vendor's public code** is two patch versions older than the tested binary and incomplete (3.11); every "not in the code" means "not in the public code of 1.65.0". Agreement of the repository with the binary was not checked.
- **The vendor's statements of purpose** (price testing, Apple Search Ads attribution, restoring purchases, not using the location derived from the IP address or the demand score, the purpose of lifecycle events) cannot be verified with this method; they are quoted in full in section 6.
- **Changed documents:** both versions of the policy and the article, with the date and record of each, are described in 3.1 and in `sources/README.md`; the times of the label's changes are known only to within the intervals between Wayback Machine snapshots (3.9).

## 6. Correspondence and the vendor's reply

- 2 October 2026, 09:50 CEST (07:50 UTC): the authors sent the vendor 19 questions in five groups (`correspondence/`). The questions are not numbered in the message; this report numbers them in order: A 1–7, B 8–9, C 10–12, D 13–17, E 18–19.
- 5 October 2026, 17:36 CEST (15:36 UTC) and 19:41 CEST (17:41 UTC): two replies from Alex @ Strongbox announcing a full reply and an update of the privacy policy, and asking where the report would be published. In between, at 19:22 CEST (17:22 UTC), the authors wrote that they would wait for a response until 8 October 2026.
- 8 October 2026, 16:13 CEST (14:13 UTC): the authors wrote that they would publish the report in the Strongbox community on Reddit.
- 8 October 2026, 23:46 CEST (21:46 UTC): the authors sent corrections (the Sentry traffic came from the authors' tool, questions 10 and 12 withdrawn; three devices; scope) and further observations; reply deadline 15 October 2026, 23:59 CEST (21:59 UTC; written as "CET" in the message; the authors meant Polish time, which in October is CEST); commitment to send the publication address before publication.
- 14 October 2026, 18:49 CEST (16:49 UTC): the vendor's reply, signed "Alex", quoted below in full. The vendor replied in broad strokes rather than to the 19 questions individually and offered clarifications on request. Eleven questions were not addressed; they were re-sent on 14 October (next entry), and the state after the second reply is given under 16 October. Answered in part: the release notes for 1.60.39 (8; the purpose of the token is given, the wording "the exact same information" is not addressed), combining of data (9; the vendor speaks for itself, not for RevenueCat and Superwall), the completeness and last update of the article on connections (15; "Some articles on the website are outdated").
- 14 October 2026, 20:29 CEST (18:29 UTC): the authors re-sent the 11 unanswered questions (1, 3, 4, 6, 7, 11, 14, 16, 17, 18, 19; in 14, 17 and 19 without the references to the crash reporting provider, after the corrections of 8 October), with two questions about the reply (when the label was updated and what it contained before; which release note mentions Superwall) and one clarification (SDK lifecycle events sent with a database unlocked); text in `correspondence/`.
- 16 October 2026, 12:37 CEST (10:37 UTC), after the deadline of 15 October 2026, 23:59 CEST (21:59 UTC), set on 8 October, and before publication: the vendor's second reply, signed "Alex", with a short answer under each question, quoted below in full. Still not addressed: the countries data is transferred to (17), the macOS version (18; the answer covers Strongbox Pro and Zero), whether the available restrictions on event collection were considered (6, first part), the earlier content of the App Store label; on the data types in 3.9 (16) the answer is general; on "does not collect any of your data" (14) the answer ("We have updated the policy with clearer wording") does not say whether the data were within the scope of the statement. Not re-asked on 14 October and not answered: the legal basis (2, second part) and whether the list of connections was meant to be complete and when it was last updated (15).
- After the questions were sent, the vendor changed the privacy policy ("Last Update: 15 October 2026") and rewrote the article "What Network Connections Can Strongbox Make?" (changed between 14 and 16 October 2026 according to the authors' account; accessed 16 October 2026). Section 3 sets the traffic against both versions.
- 19 October 2026, 23:00 CEST (21:00 UTC): the authors sent the vendor the address of this report (message 10 in the correspondence file). The report was online at that address from the same day, with access restricted to the vendor's e-mail domain; public access from 21 October 2026, 07:00 CEST (05:00 UTC).
- The vendor's reply of 14 October 2026, in full and unchanged:

> Hey again!
>
> Thanks for reaching out to us first -  rather than answer all 19 questions, I'd rather just respond in broad strokes. If you would like clarifications on any specific points, please let me know. This is mostly the same as we've already said publicly, but may be useful to go over again.
>
> First, the privacy policy update is simply a mistake on our end. We updated the app’s privacy labels on the app store, and made sure any changes were clearly communicated in our Launch posts & release notes, but we didn’t push an update to the policy. We'll publish this update shortly to explicitly mention that freemium will contact RevenueCat & Superwall. Some articles on the website are outdated, and we're sweeping through them all in the same pass.
>
> For Superwall & RevenueCat we did aim to be pro-active with announcing their addition, and you'll be able to see a lot of discussion about it on Reddit launch posts, including about us then removing it from PRO. We're not in the business of sneaking tracking in to a password manager.
>
> Superwall allows us to grow our app with paywall testing, price testing, and running sales without shipping new builds. It isn't a tool for analytics, like Mixpanel, or Amplitude. The result of us using Superwall, is most users end up with a better price. For some specifics, if we can see that only 1% of users choose to start a subscription on a paywall, we’ll then adjust the design & price to improve that. We aren’t able to see any information about your databases, unless you send us that as debug info in support. We also can't see anything like "alex@strongboxsafe.com". Our usage of Superwall's events is just for triggering paywalls, so for example, we can trigger a paywall on app launch, which we do for sales, or when someone taps our "nudge" banner that says they could get better experiences with PRO. We've purposefully ensured we're not sending events with the database unlocked.
>
> For RevenueCat's events & networking, the Ad services token is used to tell us which Apple Search Ad someone saw before they purchased ( we run ads on the App Store like most iOS apps ). We're not using ATT, so that property just stays as false for everyone.
>
> I spoke a lot about this, including why not having analytics hurts privacy-conscious apps like Strongbox, and that we're happy to make the sacrifice, in my Techlore interview a while back, which may offer some helpful context ( this should skip to the relevant section ): https://www.youtube.com/watch?v=lxCR8-YsuHU&t=2666s
>
> In terms of tying data together, we do not do any extra merging of users. Apple's receipts contain some identifiers, which let you restore someone's subscription across devices & ensure they get the correct trial entitlements etc, and this is strictly used for that purpose. This makes sure we don't show a paywall to someone who already paid.
>
> We will always offer PRO & Zero for more and extreme levels of “locked down”. PRO can contact Apple if you decide to pay for a tip, but otherwise it'll stay to just the connections that you setup. We did originally use RevenueCat for this, but we heard the community and switched it out for just talking straight to Apple again.
>
> Best,
> Alex
>
> Also just a heads up, your alias tool is leaking emails 😅

[Authors' note, not part of the message: the last line refers to the authors' e-mail setup and is unrelated to the subject of this report.]

- The vendor's second reply of 16 October 2026, in full; the text is unchanged, a blank line has been added between lines so that the quoted questions and the answers display as separate paragraphs (the message as received, without the added blank lines: `correspondence/`):

> Hey again!
>
> Quick responses below for you!
>
> Since which version has the app included the Superwall SDK, and in which user-facing document is this described?
>
> 1.64.0, we included this in the launch post at the time.
>
> Superwall returns the user's IP address, city and region, together with demandScore and demandTier values, and the app sends these back in subsequent events. What are they used for?
>
> These are simply not used. They're something you can use to work out "is this person likely to subscribe" or not, but we don't use them.
>
> Why are paywall screens preloaded at launch for a user with an active Pro subscription?
>
> Paywalls are always pre-loaded because an existing pro user may not stay pro at run-time, for example, their sub may expire, or their family share may be removed by someone else. We pre-load to make sure users don't have to stare at a loading screen before paywalls.
>
> The configuration parameter isExternalDataCollectionEnabled is set to true. Did you consider the event collection restrictions available in the SDK, and can the user turn this collection off?
>
> This cannot currently be turned off by the user. This property generally describes which events we post-back to Superwall, and is used in reporting so we can see which paywalls drove conversions, i.e did a paywall get opened 1000 times but only 1 person paid. External data collection does not mean another third party or similar, it just refers to the events we post-back.
>
> The paywall screens load resources from user-content.superwalleditor.com and fonts.gstatic.com, and reference js.stripe.com. Are these parties covered in your privacy documentation?
>
> The revised policy specifically mentions Superwall & RevenueCat, it does not explicitly list fonts etc.
>
> What does "automatic opt-in crash reporting" in the release notes for version 1.64.0 mean: a feature that requires consent, or a feature that is enabled by default? On a fresh install, the toggle was switched on.
>
> For fresh installs this is turned on by default, for existing users it remains off. This crash reporting is the most stripped down reporting possible. For example, most crash reporting tools allow "breadcrumbs" which would tell us what screens a user was on before the crash. In Strongbox, we only get the exact same stack trace as sent manually by users if they see the in-app pop-up after a crash. Using automatic reporting has already allowed us to catch multiple crashes before users even raised tickets, and we've shipped fixes before it affected more users.
>
> The policy states: "The Company does not collect any of your data". Do you consider the data sent to Superwall and RevenueCat to fall outside the scope of that statement, and if so, why?
>
> We have updated the policy with clearer wording.
>
> The App Store privacy label declares only "Purchases", as data not linked to the user. Were device identifiers, usage data and IP-derived location assessed against the other label categories?
>
> When we added these, we checked the guidance from the various providers to see what they reccomended to add. If this changes, we'd add more labels to the app store, and we stay up-to-date with changes here.
>
> Do you have data processing agreements in place with Superwall and RevenueCat, and to which countries is the data transferred?
>
> - RevenueCat & Superwall have DPA's available. https://superwall.com/legal/dpa & https://www.revenuecat.com/dpa
>
> Do the macOS version and the Strongbox Zero variant include the same SDKs?
>
> PRO & Zero do not include Superwall or RevenueCat.
>
> Does the code published in the repository correspond to version 1.65.2 as distributed on the App Store, including the Superwall and RevenueCat integrations?
>
> - This is slightly behind, but most code is visible. Only small commercially sensitive elements are omitted, and some files that would make it easy for copycats to clone our app. We aim to update the open-source repo shortly after most releases.
>
> You write that the App Store privacy labels were updated. When was that, and what did the label include before? The label we recorded on 8, 9 and 10 October lists "Purchase History" only, with the purpose "Analytics".
>
> We do not have the exact date these were recorded to hand, but we updated these when we added RevenueCat to the app.
>
> You write that the changes were communicated in release notes. The App Store release notes for 1.60.39 mention RevenueCat; the notes for 1.64.0 do not mention Superwall, while the r/strongbox post of the same day does. Is there a release note that mentions Superwall?
>
> There is not a release note that mentions Superwall, only the launch post.
>
> One clarification on your reply. You write that no events are sent with the database unlocked. In our captures, the app's own events agree with that. The Superwall SDK's lifecycle events (app_open, app_close) were, however, sent while a database was unlocked, when the app returned to the foreground. Do you consider these covered by your statement?
>
> We believe so, yes. The app lifecycle events are used as stated to determine subscription updates, i.e, if someones entitlements have changed since they last opened the app. It does not contain any database information, or that the database is opened, and we do not send any events like "database_open" or "database_closed".
>
> Best,
>
> Alex

## Epilogue

*This epilogue describes the authors' opinions and impressions.*

Despite the unpleasant origin of the whole matter, we are very glad about its outcome: the privacy policy and the documentation on network connections have been updated.

On 13 March 2025 the Strongbox website announced that Strongbox had joined Applause ([announcement of 13 March 2025, Wayback Machine](https://web.archive.org/web/20261016232547/https://strongboxsafe.com/strongbox-joins-applause/); EP1: [text](sources/EP1_strongbox-joins-applause_strongboxsafe.com_wayback-20261016232547.txt), [PDF](sources/EP1_strongbox-joins-applause_strongboxsafe.com_wayback-20261016232547.pdf)). Until 15 October 2026 the privacy policy in force was the one dated 9 May 2024, although RevenueCat had been in the app since May 2025 and Superwall since January 2026 (3.1). A representative of the vendor wrote on 14 October 2026 (section 6): "First, the privacy policy update is simply a mistake on our end. We updated the app’s privacy labels on the app store, and made sure any changes were clearly communicated in our Launch posts & release notes, but we didn’t push an update to the policy." This is not fully consistent with what we found: Superwall was named in a launch post on Reddit (D16) and in an interview (D15), but in no release note, as the vendor confirmed on 16 October 2026 (section 6); and the App Store label did not change after Superwall was added (3.9). Even so, we have no grounds to attribute insincere intentions to the vendor. We are only human too, and only those who do nothing make no mistakes.

We will keep using Strongbox, because in our opinion there is no better KeePass client for iOS in terms of features, but only the Strongbox Zero version (according to the vendor it does not include these SDKs, section 6; we did not study this version), because our trust in the vendor has probably been lost irreversibly.

In our opinion, the sequence we observed (a change made first, documentation and explanation following after users asked) resembles an earlier case at Applause. Bartender 5.0.52 (May 2024) added the Amplitude analytics before Applause had announced that it had acquired the app; after users raised concerns, Applause apologised in June 2024 for the missing announcement and removed Amplitude in the next version, about three weeks after it was added.[^applause] On the other hand, according to the vendor (14 October 2026, section 6), Strongbox Pro also used RevenueCat at first, "but we heard the community and switched it out for just talking straight to Apple again." The authors did not test Strongbox Pro; the public code still contains a RevenueCat initialisation for the Pro bundle behind a build flag whose state cannot be determined (3.11).

Terms and conditions are meant to be read and verified.

## 7. Change log and contact

- `CHANGELOG.md`: history of the report's versions. Version 1.0 of 19 October 2026 is the first published version; it was online from 19 October 2026 with access restricted to the vendor's e-mail domain and public from 21 October 2026, 07:00 CEST (05:00 UTC).
- Contact: contact@termsapply.fyi.
- Licence: CC BY 4.0 (text and data), MIT (scripts).
- Repository contents: `data/` (pseudonymised HAR files, check reports, checksums, PCAP extracts), `tools/` (pseudonymisation and analysis scripts, change log), `sources/` (snapshots of the vendor's documents with dates, confirmations from the SDK code), `correspondence/`.

[^d15]: Techlore, "The Password Manager that Took KeePass to the Next Level (Strongbox Interview)", YouTube `lxCR8-YsuHU`, published 1 August 2026, segment 32:57–40:56, accessed 9 October 2026. Interviewee: Alex Logan; role as given in the video description (techlore.tech, accessed 9 October 2026). Transcript made by the authors from the audio: `sources/D15_transcript_32-57_2026-10-09.txt`; selected passages: `sources/D15_transcript-excerpts_2026-10-09.md`. Snapshot of the video page with its description: `sources/D15_youtube-description_2026-10-18.pdf` (snapshot taken 18 October 2026; it replaces a snapshot of 9 October 2026 with the same description). The vendor's reply of 14 October 2026 (section 6) links to 44:26 of the recording; the authors' transcript of the segment from 43:50 to the end: `sources/D15_transcript_43-50_2026-10-14.txt`.

[^applause]: Applause, "Let's Try This Again", Bartender blog, 10 June 2024 ("there has been some concern and uncertainty regarding our acquisition of Bartender"; apology "for not making an announcement earlier"; "We included Amplitude in version 5.0.52 […] Amplitude has served its purpose and has been removed in version 5.0.53 onward"): [Wayback Machine](https://web.archive.org/web/20261016232701/https://www.macbartender.com/B5blog/Lets-Try-This-Again/); EP2: [text](sources/EP2_lets-try-this-again_macbartender.com_wayback-20261016232701.txt), [PDF](sources/EP2_lets-try-this-again_macbartender.com_wayback-20261016232701.pdf). Release dates of 5.0.52 (14 May 2024) and 5.0.53 (6 June 2024) as given by the publisher in the Bartender 5 update feed: [Wayback Machine](https://web.archive.org/web/20251116051042/https://www.macbartender.com/B2/updates/AppcastB5.xml); EP6: [text of the two entries](sources/EP6_bartender-5-update-feed_macbartender.com_wayback-20251116051042.txt), [PDF](sources/EP6_bartender-5-update-feed_macbartender.com_wayback-20251116051042.pdf). Release notes of 5.0.53 ("removing Amplitude product analytics, which was added in version 5.0.52"): [Wayback Machine](https://web.archive.org/web/20250614191649/https://macbartender.com/B2/updates/5-0-53/rnotes.html); EP7: [text](sources/EP7_bartender-5.0.53-release-notes_macbartender.com_wayback-20250614191649.txt), [PDF](sources/EP7_bartender-5.0.53-release-notes_macbartender.com_wayback-20250614191649.pdf); the release notes of 5.0.52, as archived on 18 May 2024, mention neither Amplitude nor Applause (EP7a: [Wayback Machine](https://web.archive.org/web/20240518170255/https://macbartender.com/B2/updates/5-0-52/rnotes.html), [text](sources/EP7a_bartender-5.0.52-release-notes_macbartender.com_wayback-20240518170255.txt)). A. Engst, "Bartender Developer Explains and Apologizes for Quiet Acquisition", TidBITS, 5 June 2024 (the online reaction to a change of the signing certificate and to the addition of Amplitude): [Wayback Machine](https://web.archive.org/web/20261016232732/https://tidbits.com/2024/06/05/bartender-developer-explains-and-apologizes-for-quiet-acquisition/); EP3: [text](sources/EP3_bartender-quiet-acquisition_tidbits.com_wayback-20261016232732.txt), [PDF](sources/EP3_bartender-quiet-acquisition_tidbits.com_wayback-20261016232732.pdf). All accessed 17 October 2026.