CoreSearch 2.30.1 and 2.30.4 privacy-manifest tracking clarification
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start with the referenced Search SDK PrivacyInfo.xcprivacy and CoreSearch Package.swift for versions 2.30.1 and 2.30.4, then review issue #233 for context. The issue asks for version-specific guidance on tracking behavior, retained data, consent controls, and the manifest discrepancy; it is done when maintainers provide answers that resolve these questions.
Written by the indexing model from the issue text.
Description
We’re preparing an iOS submission using Search SDK/CoreSearch 2.30.1 with Common 24.30.1. We use SearchEngine and CategorySearchEngine with apiType .searchBox and default providers, without deliberately requesting IDFA or enabling advertising tracking.
In the official CoreSearch 2.30.1 and 2.30.4 packages, verified against their published checksums:
- NSPrivacyTracking is true
- The tracking-domain list contains https://events.mapbox.com/
- Precise Location, Coarse Location, and Other Diagnostic Data each declare Tracking=false and Linked=false
The Search Swift wrapper instead declares global tracking=false with no tracking domains.
Could you clarify:
- Does this configuration perform tracking under Apple’s ATT definition? If so, which behavior requires consent gating?
- Is the global declaration intentional, conditional, or erroneous? Is there an official release or configuration that resolves the discrepancy?
- What location, search, diagnostic, or identifier data is retained beyond servicing a request, for what purposes, and with what user/device linkage?
- Is there a supported Search-specific consent or opt-out control covering binary CoreSearch events while preserving required billing functionality?
We understand that manifest declarations alone don’t establish runtime behavior. We’re looking for version-specific guidance to make accurate App Store disclosures and won’t modify vendor manifests as a workaround.
Related issue #233 appears to concern the older false-plus-nonempty-domains validation problem, rather than this combination of declarations.
Reference: https://github.com/mapbox/mapbox-search-ios/blob/2.30.1/Sources/MapboxSearch/Resources/PrivacyInfo.xcprivacy
Reference: https://github.com/mapbox/mapbox-core-search-ios/blob/v2.30.1/Package.swift
- Dominant language
- Swift
- Stars
- 29
- Forks
- 31
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from mapbox/mapbox-search-ios
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
mapbox/mapbox-search-ios#448 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
mapbox/mapbox-search-ios#447 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
mapbox/mapbox-search-ios#444 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
mapbox/mapbox-search-ios#436 ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
mapbox/mapbox-search-ios#391 ·
All issues in mapbox/mapbox-search-ios
Similar issues
-
product / auth product / console product / sites product / storage
Difficulty 1/5 Under an hour Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
稍后再看页面无法下拉刷新Openbug good first issue working on it
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
manaflow-ai/cmux#24829 ·
Maintainers usually reply within 1 day