/
Navigation
Chronicles
Browse all articles
Explore
Semantic exploration
Research
Entity momentum
Nexus
Correlations & relationships
Story Arc
Topic evolution
Drift Map
Semantic trajectory animation
Posts
Analysis & commentary
Pulse API
Tech news intelligence API
Browse
Entities
Companies, people, products, technologies
Domains
Browse by publication source
Handles
Browse by social media handle
Detection
Concept Search
Semantic similarity search
High Impact Stories
Top coverage by position
Sentiment Analysis
Positive/negative coverage
Anomaly Detection
Unusual coverage patterns
Analysis
Rivalry Report
Compare two entities head-to-head
Semantic Pivots
Narrative discontinuities
Crisis Response
Event recovery patterns
Connected
Search: /
Command: ⌘K
Embeddings: large
TEXXR

Chronicles

The story behind the story

days · browse · Enter similar · o open

Apple plans to require developers to submit reasons to use certain APIs in their apps starting this fall, to prevent the misuse of those APIs for fingerprinting

The App Store review process is very strict to ensure that apps comply with Apple's guidelines.  And soon, this whole process will get even stricter.

9to5Mac Filipe Espósito

Context & Ripple Effects

Apple has previously used App Review to constrain how developers access platform capabilities, including requiring the official mechanism for app-rating requests. The reported API-justification requirement extends that review model from user-interface rules to the potential privacy implications of underlying technical access.

The move also follows developer reports that App Store updates were rejected over third-party SDKs capable of collecting fingerprinting-related data. By asking for stated reasons up front, Apple can assess the declared purpose of sensitive API use rather than only responding to problematic code in updates.

First-order effects

  • Developers using the designated APIs will need to document a permitted purpose as part of app submission, adding a compliance step before App Store distribution.
  • Apple gains a more explicit review signal for identifying API access that may be used for fingerprinting, while apps relying on unsupported uses face greater approval risk.

Second-order effects

  • Third-party SDK providers will be pressured to explain, narrow, or remove sensitive API calls so customers can continue submitting updates—an issue already visible in rejections tied to fingerprinting-capable SDKs.
  • Development teams may favor documented, platform-sanctioned implementations over opaque SDK behavior, shifting privacy-review work earlier in the release cycle.

Third-order effects

  • If enforcement is consistent, App Store review increasingly becomes a permissioning layer for technical capabilities, not just a check on an app's outward behavior.
  • The pattern could make platform-specific compliance documentation a durable cost of mobile distribution, with Apple able to define acceptable purposes for increasingly granular categories of API access.

The trend: This is one step in the broader shift toward app marketplaces governing privacy through capability-level access controls and review-time justification.

Discussion

  • @fosspatents Florian Mueller on x
    A novel aspect of Apple's stranglehold on app developers: the use of certain application programming interfaces (APIs) must be justified when submitting an app for review. https://developer.apple.com/ ... Tyranny in the name of privacy. CC: @TimSweeneyEpic 🧵1/3
  • @joshavant Josh Avant on x
    Seems like Apple's moving towards SDK-level privacy sandboxing? 'Your third-party SDK can't rely on the privacy manifest files for apps that link the third-party SDK, or those of other third-party SDKs the app links, to report your third-party SDK's use of required reasons API.'
  • @joshavant Josh Avant on x
    After stewing on the UserDefaults/declared reasons changes, my hunch is the biggest reason UD is included in this is that ad network SDKs are hoovering up OTHER ad network SDK fingerprinting data stored in the shared space of UserDefaults. Probably a net positive for privacy.
  • @dimillian Thomas Ricouard on x
    That's really... not convenient. Does the user get a popup as soon as the app launch when you write first install = true?
  • @donnywals @donnywals on x
    Some interesting new privacy requirements are about to be rolled by Apple. It looks like we'll have to provide reasons for accessing user defaults, file metadata etc. https://developer.apple.com/ ...
  • @krausefx Felix Krause on x
    @joshavant @ronyfadel “This reason does not permit reading information that was written by other apps or the system, or writing information that can be accessed by other apps.” I'm confused, I thought NSUserDefaults were sandboxed already? What am I missing?
  • @joshavant Josh Avant on x
    @KrauseFx ... While I haven't verified anything like this myself, it wouldn't surprise me if Facebook's (or other ad networks) intelligence dragnet SDKs store fingerprinting data in UserDefaults, effectively making all of that data available to all other code + parties included i…
  • @sindresorhus Sindre Sorhus on x
    Why is this ridiculous and completely useless? 99% of apps use UserDefaults to store some state, like whether it's the first launch. It's privacy theatre at its finest. Bad actors can simply store it in a file or database instead.
  • @krzyzanowskim Marcin Krzyzanowski on x
    Despite stupidity of explicitly declaring a reason to use foundation provided API (just prevent it from doing forbidden operations), there's only ONE reason you can use UserDefaults for. And it's not even clear how it contradicts API documentation. The raise of new crazy rejectio…
  • @fosspatents Florian Mueller on x
    Apple went from zero to one of the world's largest ad networks with a “rules for thee, not for me” approach called App Tracking Transparency. Then came workarounds called fingerprinting. Apple's response is to tyrannize developers even more than before. 🧵2/3
  • @wooster @wooster on x
    Wild overreach from Apple. Can't read defaults data from other apps in the same app group. Can't log in crash reports how much disk space is remaining, etc (their own crash reporting system basically does not work). https://developer.apple.com/ ...
  • @ceceliacreates @ceceliacreates on x
    Yesterday I talked about how Apple App Store can reject you for unclear data requests. Soon you can add certain unclear API usage to the list of things to check before you submit for review. ✅ https://9to5mac.com/...
  • @neilcybart Neil Cybart on x
    Sigh. The dismal analysis that has surrounded ATT continues. The following tweet doesn't make any sense. It is funny though how some are now saying Zuckerberg should be thanking Apple for ATT. (Spoiler: I don't think Zuckerberg will be thanking Apple for anything anytime soon.) […
  • @joshavant Josh Avant on x
    UserDefaults now an API that requires a declared reason to use. Wow. https://developer.apple.com/ ...
  • @nachosoto Nacho Soto on x
    This is on beta 5 already [image]
  • @eric_seufert Eric Seufert on x
    Apple published additional context on Required Reasons APIs: APIs for which use will require justification in the new Privacy Manifests system. After reviewing this, it's clear that fingerprinting will be mostly, if not completely, impossible in iOS 17. https://developer.apple.co…
  • @1finebreed @1finebreed on x
    Now this is a ridiculous thing, we store basic user settings and app preferences data in userDefaults Why not just sandbox it by default so bad actions don't read what they shouldn't Imagine asking users “Allow [App Name] to save your setting or remember your preferences” 😒
  • @mysk_co @mysk_co on x
    Apple now details the required reason APIs. These are the APIs that are commonly used for fingerprinting. Surprisingly, the current list in Xcode 15 beta 5 has shrunk a lot compared to the previous betas 🧐. Here's a comparison: https://developer.apple.com/ ... [image]