What Strongbox for iOS sends to RevenueCat and Superwall

Prologue

Authors

This prologue describes the authors’ personal experience and impressions; the report itself starts under “In brief”.

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, 2). Intrigued, we decided to look into it.

In brief

Summary

This page is the short report. The full report, with all observations, sources and the complete correspondence, is FULL-REPORT.md; the short report as a file is README.md. Section numbers on this page are the same as in both reports; references of the form “(full report, 3.x)” and “(3.x)” point to the same section of the full report. The exhibits (the run table, the data flow, the request logs and the file list) are on the Evidence page.

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 (full report, 3.1). 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 (3.2). The service returns a location derived from the IP address and a purchase propensity score (“demand score”), and the app sends them back in later events (3.5). The same device identifier goes to RevenueCat (3.3).

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 (3.4). 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).

The vendor replied on 14 October 2026 in broad strokes and on 16 October 2026 under each question (quoted in full in the full report, section 6): 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 (section 6). 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.

Labels

Each paragraph below is marked in the margin: F for a fact from a file, with its location; D for a document, with its address and date of access; R for the vendor’s replies to the authors of 14 and 16 October 2026, printed in full on the Correspondence page; I for an inference, a conclusion drawn by the authors; H for a hypothesis. Section numbers are the same as in the short and the full report (FULL-REPORT.md, among the files on record). Document codes (D1–D21, EP1–EP7a, P0) refer to the files and addresses listed in sources/README.md.

Declarations and findings, side by side

Departs from the wording

1. D1"The Application does not use vendors or analytics providers."Strongbox Privacy Policy, Last Update 9 May 2024
2. D4–D8"The following are the possible network connections that Strongbox can make which may be seen if you monitor network traffic while using the features described below."Strongbox support article, version of 8 Oct 2026
3. D16"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."Post on r/strongbox by u/strongbox-support, 26 Jan 2026

Open to interpretation

1. D16"This is only in the free app, and is not linked in PRO or Zero, just like with RevenueCat."Post on r/strongbox by u/strongbox-support, 26 Jan 2026
2. D16"These events all happen on the homepage, before any databases are opened, and there are no further manually tracked events."Post on r/strongbox by u/strongbox-support, 26 Jan 2026
3. D15"we don't have any identifiers that we track."Representative of the vendor, interview published 1 Aug 2026
4. D15"Both of those are effectively in the most limited state they possibly can be."Representative of the vendor, interview published 1 Aug 2026
5. D15"the general rule that we followed throughout all of this is that we haven't added analytics."Representative of the vendor, interview published 1 Aug 2026
6. D8"None of these connections send any of your databases or personal identifying information."Strongbox support article, version of 8 Oct 2026
7. D9"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."App Store release notes, Strongbox 1.60.39
8. D13"Data Not Linked to You: Purchases"App Store privacy label, US and PL storefronts, App Store app on macOS
9. D1"The Application does not use or collect any data related to your geographic location."Strongbox Privacy Policy, Last Update 9 May 2024

Consistent

1. D11"Added automatic opt-in crash reporting."App Store release notes, Strongbox 1.64.0
2. D5"No information is sent, just a connection test."Strongbox support article, version of 8 Oct 2026
3. D6"FavIcon Download - (Opt In)"Strongbox support article, version of 8 Oct 2026
4. D16"Strongbox's free app has a new setup for its paywalls - we're using Superwall."Post on r/strongbox by u/strongbox-support, 26 Jan 2026

1. What was studied, and what was not

Scope

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, 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 (full report, 1).

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 below and in the full report, section 3.

2. How it was studied

Method

Three iPhones owned by the authors: A (annual Pro subscription, active), B (entitlement through Family Sharing until 3 October, then expired; fresh installation on 3 October) and C (never installed before, no purchase). Tools: Proxyman (macOS) with TLS decryption for the RevenueCat, Superwall and Google Fonts hosts and js.stripe.com (HAR: decrypted HTTP log); Proxyman for iOS on the device in A0, S02, S17 and S18; rvictl + Wireshark (PCAP: full packet capture). Apple domains were not decrypted. Runs (full report, 2):

Exhibit 1 / the twelve runs →

“Domain filter”: an export that contains only selected hosts (section 5).

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).

In the published HAR files (data/), identifiers, tokens, addresses, purchase dates and prices are replaced with labels (the same value gives the same label in every file), server addresses with labels of the form <<IP_n>>, and all timestamps are shifted by a constant random value per run, so times should not be compared between files. From the packet captures only extracts are published, without content (full report, 2, “Pseudonymisation”). A “CONNECT” entry in a HAR file is a connection whose content was not decrypted.

Terms

HAR

a log of decrypted HTTP requests and responses, here from Proxyman.

PCAP

a full packet capture; here only extracts are published.

SNI

the server name sent in the clear at the start of a TLS connection; it shows which hosts a capture without decryption reached.

DNS

the lookup of a host name’s addresses.

CONNECT

a HAR entry for a connection whose content was not decrypted.

IDFV (identifierForVendor)

an identifier iOS gives to all apps of one vendor on a device, kept while at least one of those apps stays installed.

IDFA (Identifier for Advertisers)

an identifier requested through App Tracking Transparency; not seen in the traffic.

ATT (App Tracking Transparency)

the iOS consent prompt through which an app requests the IDFA.

StoreKit

Apple’s purchase framework; the receipt comes from it.

Paywall

the purchase screen; Superwall delivers and configures it.

Trigger or placement

a named point in the app at which a paywall can be shown, under rules from the configuration.

Entitlement

an active right to the paid features; here from a subscription or Family Sharing.

Demand score

a number from 1 to 100 that Superwall assigns to each user on every app open (D20).

HTTP/2 coalescing

two host names served over one connection, so that only one name is visible in the capture.

3.1 Connections on every cold start

On every start the app contacts the two services, whether or not the user pays.

F

In each of the 21 cold starts recorded in HAR, the app connected to the following five hosts.

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 and collector and subscriptions-api are absent. In the 6 captures with DNS answers (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. H (T2 only): both hosts share one connection (HTTP/2), so the names would not appear separately. The connections occur whether the user has an active entitlement (A), an expired one (B) or has never made a purchase (C).

Exhibit 2 / where data goes on a cold start → Exhibit 3 / hosts contacted in each run →

D / D1

D1 (privacy policy, “Last Update: 9 May 2024”, in force at the time of the study; wording: 3.12). D4–D8 (article “What Network Connections Can Strongbox Make?”, snapshot of 8 October 2026): the list of connections covered App Store/StoreKit, the duckduckgo.com connectivity test, favicons (opt-in), Have I Been Pwned (opt-in). D1, version of 15 October 2026: “The iOS freemium app uses Superwall to provide upgrade screens, manage offers and measure their performance.”; D4–D8, new version: names RevenueCat, Superwall, Sentry and Apple Ads attribution.

R / 14 and 16 Oct 2026

R (14 October 2026): “the privacy policy update is simply a mistake on our end.” R (16 October 2026): “There is not a release note that mentions Superwall, only the launch post.”

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; whether this differed from the wording of D1 depended on whether a payment operator and a paywall operator are “vendors or analytics providers”. The new versions name both providers; the discrepancy concerns the earlier versions (the vendor had named both publicly in D9/D16 and D15, section 4).

3.2 What goes to Superwall on start

Several dozen events with a device profile go to Superwall on every start; the app’s own statements described only paywall events.

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), 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 device_attributes event has 50–61 fields; the fields are grouped in Exhibit 4.

Exhibit 4 / the fields of device_attributes → Exhibit 5 / one first launch on device C, request by request →

I / from D

This set of events and fields matches the standard behaviour of the Superwall SDK as described in its documentation and code.

D / D16

D16 (r/strongbox post “Strongbox 1.64.0”, 26 January 2026). 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): “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.” (further wording: 3.12)

R / 14 and 16 Oct 2026

R (14 October 2026): “It isn’t a tool for analytics, like Mixpanel, or Amplitude. […] Our usage of Superwall’s events is just for triggering paywalls”. R (16 October 2026), on isExternalDataCollectionEnabled: “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.”

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: the app sends device and account identifiers to both services (3.3) and receives a location derived from the IP address (3.5), but whether the vendor can or wants to use them to find a user does not follow from the traffic, and the assessment “most limited state” cannot be checked from traffic (3.10, 3.11).

3.3 The same device identifier to both services; persistent identifiers

The same device identifier reaches both companies, and the Apple account identifier allows records to be linked after reinstallation.

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/9 files with both fields); according to the code of both SDKs (D17, D18) both values come from UIDevice.identifierForVendor (IDFV). $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). RevenueCat returns original_app_user_id with the same label for B before and after the fresh installation.

Exhibit 6 / one value, two services → Exhibit 7 / identifiers on device A, 1 to 8 October →

D / D9

D9 (release notes 1.60.39, 12 May 2025) and D1 (version of 15 October 2026): wording in 3.12.

R / 14 Oct 2026

R (14 October 2026): “In terms of tying data together, we do not do any extra merging of users.”

I

The $appTransactionId 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; whether the IDFV and appTransactionId fall within “the exact same information … as … Apple” depends on interpretation. The vendor’s statement is consistent with the absence of identify() and of custom user attributes (3.11; section 4, item 11); the new policy describes device identifiers but does not name the Apple Account-level identifier ($appTransactionId).

3.4 First launch: attribution token, consent status, receipt

On the first launch the app sends an Apple advertising attribution token that the app itself had to switch on.

F

On every first launch after installation (S01, S17, A5 ×2, A8, C8; 6 observations) the app sends to RevenueCat 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), including on device C, which never made a purchase. The value of $attConsentStatus is denied in 22/22 receipts.

D / D18a

D18a: in the RevenueCat SDK 5.21.1 code, token collection is off by default and starts only when the app calls enableAdServicesAttributionTokenCollection(). D1 (version of 15 October 2026): “The iOS freemium app also uses RevenueCat for Apple Ads attribution, associating installations and purchases with advertising campaigns.”

R / 14 Oct 2026

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

Sending the token means the app switched this function on; it is not the SDK’s default behaviour, and the versions of D1 and D4–D8 in force at the time of the study did not mention it (the new versions mention Apple Ads attribution). Based on the app’s public code and the vendor’s reply, the app does not ask for ATT consent, and denied does not mean the user refused.

3.5 Location from the IP address and a demand score

Superwall returns a location derived from the IP address and a purchase propensity score, and the app sends them back.

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). None of the 10 paywall rules in static_config refers to demandScore, demandTier or the ip* fields.

Exhibit 8 / the enrich exchange, field names only →

D / D20, Superwall documentation “Demand Score”

D20 (Superwall documentation “Demand Score”): “Demand Score is a number from 1 to 100 assigned to each user by Superwall on every app open.”; the documentation mentions no way to switch it off, and the SDK 4.15.3 code calls enrich unconditionally. D1 (version in force at the time of the study; wording: 3.12). D1 (version of 15 October 2026): “It may derive approximate location from your IP address and estimate the likelihood of a purchase. This is not GPS location tracking.”

R / 16 Oct 2026

R (16 October 2026): “These are simply not used.”

I

The service assigns the device a location derived from the IP address (country, region, city) and a demand score, and the app sends them back in events, with no switch in this SDK version (3.10); no access to GPS location was observed, and 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. The rules evaluated on the device agree with the statement; use of these values on the service’s side is beyond the reach of this method.

3.6 Paywall resources, loaded before any paywall

Purchase screens and their resources are downloaded before any purchase screen is shown, also for subscribers.

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. On later starts the HAR contains 0–1 such entries per start. In the packet captures, one short connection to each of the three resource hosts 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. In A8 the paywall webview fetches js.stripe.com/clover/stripe.js (1.1 MB). 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 not in the published files, which keep only the examined hosts.

Exhibit 9 / resource requests on each first launch →

D / D21

D21 (Stripe documentation “Advanced fraud detection”): Stripe.js collects “risk factors about device characteristics and user activity”. D1 (version of 15 October 2026): “Upgrade screens may load resources from Superwall and third-party hosts.”

R / 16 Oct 2026

R (16 October 2026): “Paywalls are always pre-loaded because an existing pro user may not stay pro at run-time […]”; on the resource hosts: “The revised policy specifically mentions Superwall & RevenueCat, it does not explicitly list fonts etc.”

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); what Stripe.js sends from the paywall webview remains unestablished. The reply explains preloading (a loss of entitlement occurred on B on 3 October), not the device profile and enrich, which the SDK sends for a subscriber regardless of preloading (the vendor gave the purpose of the lifecycle events separately, 3.8); Google Fonts and Stripe are not named.

3.7 Paywall configuration

The configuration allows paywalls after a database is opened, but only for users without an active entitlement; the event collection cannot be switched off by the user.

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. The config_attributes event sent by the app contains $isExternalDataCollectionEnabled: true.

D

SDK 4.15.3 code: 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, 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.

R / 16 Oct 2026

R (16 October 2026): “This cannot currently be turned off by the user. […] External data collection does not mean another third party or similar, it just refers to the events we post-back.”

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, and the app’s public code does not register the triggers database-unlock and retention-discount (3.11). The description of the option agrees with the SDK code and documentation; the app uses neither this option nor the other limiting options (3.10), and the question whether the vendor considered the available restrictions on event collection was not answered.

3.8 A displayed paywall, and a trigger after an unlock

One paywall was shown in 24 starts; one event after an unlock most likely followed a tap on a banner.

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. On B in T3, cycle 3, after the database was unlocked the app sent the event Nudge; the configuration returned a decision to display a paywall (trigger_fire, $result = present); no display event was recorded. The published T3.pub.har ends with the Nudge request (the recording continued for about 3 min, authors’ account); in T3 only one app_close was recorded for three cycles. H: events still queued 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. F: in all 79 app_open/app_close events (9 files with content) the parameters are only $app_session_id, $event_name, $is_standard_event and event_name.

Exhibit 10 / the Nudge sequence after an unlock →

D / D15

D15 (representative of the vendor): wording in 3.12.

R / 14 Oct 2026

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: 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).

R / 16 Oct 2026

R (16 October 2026), on app_open and app_close with a database unlocked: “We believe so, yes. […] It does not contain any database information, or that the database is opened […]”.

I

Nudge, sent after a database is opened, is in Superwall’s vocabulary a place where a paywall can appear; in the app’s public code (1.65.0) it is called after a tap on the “Upgrade to Pro” banner on the database list (3.11), and a tap on the banner in T3 cannot be ruled out (authors’ account, 10 October), so the observation most likely reflects a user action, not the unlock itself; the missing display event remains unexplained. The content of the lifecycle 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

The App Store label lists one data type; the traffic contains data matching three of Apple’s other 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 in the snapshot of 10 October 2026 from the App Store app on macOS and in the archived HTML of the Polish page of 9 October (the web pages show only the type without expanding “See Details”). No other types or purposes.

Exhibit 11 / the label beside Apple's data types, and its history →

D / history of the label

D (history of the label, Wayback Machine snapshots): 22 April 2025 “Data Not Collected” (the archived page may have been out of date); 4 September 2025 “Data Not Linked to You: Purchases”; from 8 January 2026 to 7 October 2026 the state described above. 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; on 18 October 2026 the label was unchanged (authors’ snapshots of the US and Polish listings).

D / D19

D19 (Apple, “App privacy details on the App Store”): “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”, with the types Device ID (“other device-level ID”), Coarse Location (“with lower resolution than a latitude and longitude with three or more decimal places”) and Product Interaction (“app launches, taps, clicks, scrolling information”). D20 (Superwall, “App Privacy Nutrition Labels”): the minimum for an app with Superwall is “Purchases” with the purposes “Analytics” and “App Functionality”; RevenueCat’s guidance requires the same. Neither names Device ID (apart from advertising identifiers), Coarse Location or Product Interaction; RevenueCat’s guidance makes Usage Data (which includes Product Interaction) conditional on the use of an analytics SDK; whether Superwall counts as one is a matter of interpretation.

R / 14 and 16 Oct 2026

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.”; “we updated these when we added RevenueCat to the app.”

I

The traffic contains data that match Apple’s definitions of Device ID (the IDFV to both services on every start), Coarse Location (city and region derived from the IP address) and Product Interaction (launch, session and paywall events), none of them 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, while 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. The history of the label is consistent with the reply; 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”

Within what the app controls, no limiting option is used; most of the traffic has no switch in these SDK versions.

F/D

Superwall: 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), shouldBypassAppTransactionCheck (would remove $appTransactionId; described in the SDK changelog as “useful in testing environments”); expanding options: none enabled; no switch in the SDK: enrich with location and demand score, device_attributes, IDFV, lifecycle events. RevenueCat: the limiting settings 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.

Exhibit 12 / the options of both SDKs, as the traffic shows them →

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.

3.11 The app’s public code

The public code configures both SDKs with defaults, apart from the StoreKit version, and is incomplete.

F

The vendor’s repository (last commit 17 July 2026 labelled “1.65.0”) has no tags, no Xcode project and no package version file; the class that initialises RevenueCat is absent. SuperwallOptions() with one change (storeKitVersion = .storeKit1); 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); the App Tracking Transparency framework is absent.

R / 16 Oct 2026

R (16 October 2026): “This is slightly behind, but most code is visible. Only small commercially sensitive elements are omitted […]”.

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, and the configuration of both SDKs in the code is limited to the StoreKit version. The tested binary is 1.65.2; conclusions from the code concern the 1.65.0 state; the omitted files include the one that passes the RevenueCat API key and enables the AdServices token (3.4).

3.12 Declarations and findings after the vendor’s changes of October 2026

Full report, 3.12

The ledger at the head of this page sets the declarations of 8 October 2026 against the findings; this table adds, for each declaration, the state after the document changes (by 16 October 2026) and the reply of 16 October 2026.

4. What agrees with the declarations

F / I / H / full report, 4

1. Sentry. Requests to *.ingest.us.sentry.io occur only in the four captures with Proxyman for iOS (A0, S02, S17, S18; in S17 and S18 the release field names the Proxyman for iOS bundle, F; for A0 and S02 this is an inference, I) and not in the captures without Proxyman (T1, T2). The Sentry entries are not in the published HAR files (out-of-scope hosts). DNS queries for sentry.io without any TLS connection (S01 1, S02 3, S11b 1) are of unestablished origin. Agrees with D11 and D16 within the scope examined (no crashes during the tests); on a fresh installation crash reporting is on by default (R, 16 October 2026; new policy).
2. Working with a database. In the 6 database unlocks no event with a database-related name was sent; on C, between creating the database and locking it, only app_close and app_open went to Superwall. Exception: Nudge, 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. 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).
4. Favicons (S18): connections to icons.duckduckgo.com and to the hosts from the entries’ addresses only after the option was switched on; agrees with D6.
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.
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; according to the SDK code and the app’s public code, the app does not ask for ATT consent at all (3.4).
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 as to the kind of data; the difference was the recipient.
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.
12. The vendor’s replies agree with the traffic, the public code and the documents on the points marked R in 3.1–3.11; the reply of 14 October acknowledges that the privacy policy and the website articles were out of date.
13. The new versions of the privacy policy and the article 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.

5. Limits of this study

Full report, 5

• The HAR is not complete: the packet capture shows TLS connections on starts for which the HAR has no entries; 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; no packet capture for A5, A8 and C8, so claims that something is absent in these runs rest on the HAR alone.
• HTTP/2 coalescing in T2 (both host names sharing one connection) is a hypothesis, not confirmed by content; in T3 (with Proxyman) and T2 (without) the captures differ in the set of visible connections, so the presence of a proxy may change the app’s behaviour or the capture.
• Region of device B: a region code different from that of A and C, the same with and without the VPN; cause not established; no effect on the findings. Single observations: Nudge (1×), the paywall on C (1×), POST …/redeem (5×, a Superwall request on first launches and in S18).
• Shifted timestamps in the published files prevent comparisons of times between files and with the correspondence.
• 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).
• 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; the content of the connections to m.stripe.com, m.stripe.network, favicons and Apple hosts was not decrypted.
• The vendor’s public code is two patch versions older than the tested binary and incomplete; 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.
• 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);
  • 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;
  • 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.
• The vendor’s statements of purpose cannot be verified with this method; they are quoted in full in the full report, section 6.

6. Correspondence with the vendor

Full report, 6

• 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 messages 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, set the reply deadline at 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), and undertook to send the address of the publication before it appears.
• 14 October 2026, 18:49 CEST (16:49 UTC): the vendor’s reply, signed “Alex”, printed in full on the Correspondence page. 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).
• 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, printed in full on the Correspondence page together with the questions it answers. 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). The sections above set the traffic against both versions.
• 19 October 2026, 23:00 CEST (21:00 UTC): the authors sent the vendor the address of this publication (message 10 in the correspondence file). The publication 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 whole thread, without the senders’ e-mail addresses, is printed message by message on the Correspondence page and is among the files on record (correspondence/).

Company reply

"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…"

Alex, Strongbox / by email / 2026-10-14 / further message 2026-10-16

Read the replies in full →

Epilogue

Authors

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; EP1: text, 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 (Correspondence): “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 (Correspondence); 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, Correspondence; 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.¹ On the other hand, according to the vendor (14 October 2026, Correspondence), 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.

1. Applause, “Let’s Try This Again”, Bartender blog, 10 June 2024: Wayback Machine; EP2: text, PDF. Bartender 5 update feed, release dates of 5.0.52 (14 May 2024) and 5.0.53 (6 June 2024): Wayback Machine; EP6: text, PDF. Release notes of 5.0.53: Wayback Machine; EP7: text, PDF. Release notes of 5.0.52, archived 18 May 2024: EP7a: Wayback Machine, text. A. Engst, “Bartender Developer Explains and Apologizes for Quiet Acquisition”, TidBITS, 5 June 2024: Wayback Machine; EP3: text, PDF. Descriptions of the sources: sources/README.md. All accessed 17 October 2026.

7. Licence and contact

Full report, 7

Text and data: CC BY 4.0. Scripts: MIT. The history of the report’s versions is in CHANGELOG.md among the files on record.

Contact: contact@termsapply.fyi.