App Store Rejection due to Non-Public / Deprecated APIs (Guideline 2.5.1)

[Nitin-UpSwing]

Platform

iOS

Environment

Production

Installed

Swift Package Manager

Version

Latest

Xcode Version

15.4

Did it work on previous versions?

Yes

Steps to Reproduce

We are facing an App Store rejection and believe it is related to Sentry. We’d appreciate your help resolving the issue.

App Store Rejection Details

Apple rejected our app under the following guideline:

Guideline 2.5.1 – Performance – Software Requirements

Apple reports that the app uses or references non-public or deprecated APIs, which is not permitted.

Flagged Classes:

_TtC7SwiftUIP33_A34643117F00277B93DEBAB70EC0697122_UIShapeHitTestingView__SwiftValue

According to Apple, usage of non-public or deprecated APIs can lead to poor user experience if those APIs change and is therefore not supported on Apple platforms.

Apple’s Suggested Next Steps

Revise the app binary and remove references to the identified non-public or deprecated APIs.

Update all third-party libraries to their latest versions.

If the source code of a dependency is not accessible, use tools such as:

strings – to list methods called by a library

---

This is used in sentry iOS, here is the screenshot of related file

Here is file link:

sentry-cocoa/Sources/Swift/Core/Tools/ViewCapture/SentryUIRedactBuilder.swift

Line 153 in 23936a7

redactClasses.insert(ClassIdentifier(classId: "_TtC7SwiftUIP33_A34643117F00277B93DEBAB70EC0697122_UIShapeHitTestingView"))

Expected Result

We should able to upload our app without any issue

Actual Result

Facing an App Store rejection

Are you willing to submit a PR?

No

[linear]

COCOA-1120

[philprime]

Thank you @Nitin-UpSwing for bringing up this issue.

We are aware of Apple performing String-based analysis of binaries to identify if apps are accessing private API, but interestingly this is the first time it was surfaced to us that Session Replay is causing this issue (the code in question has been part of the SDK for ~3 years).

The Sentry SDK is not accessing the private API mentioned in this feedback, and this is a false-positive report by Apple.

Our redaction logic identifies views that need to be masked by getting the type of the view instance, to then perform a string-based comparison with the constant in our code base.

We are not loading or instantiating the type _UIShapeHitTestingView in any way. Here's the exact code in the latest version:

sentry-cocoa/Sources/Swift/Core/Tools/ViewCapture/SentryUIRedactBuilder.swift

Lines 393 to 395 in ee9199a

	private func shouldIgnore(view: UIView) -> Bool {
	return SentryRedactViewHelper.shouldUnmask(view) || containsIgnoreClassId(ClassIdentifier(class: type(of: view))) || shouldIgnoreParentContainer(view)
	}

The type(of: view) is converting the instance type to a String used by the containsIgnoreClassId(_ id: ClassIdentifier) here:

sentry-cocoa/Sources/Swift/Core/Tools/ViewCapture/SentryUIRedactBuilder.swift

Lines 256 to 263 in ee9199a

	/// Returns `true` if the provided class identifier is contained in the ignore list.
	private func containsIgnoreClassId(_ id: ClassIdentifier) -> Bool {
	/// Edge case: ``UITextField`` uses an internal type of ``UITextFieldLabel`` for the placeholder, which should also be ignored
	if id.classId == "UITextFieldLabel" {
	return ignoreClassesIdentifiers.contains(ClassIdentifier(classId: "UITextField"))
	}
	return ignoreClassesIdentifiers.contains(id)
	}

Therefore, while this is annoying, and we apologize for the inconvenience, the recommended step at this point is responding to the Apple review and let them know that this detection result is invalid and that we are not using the private API. From personal experience these topics can be resolved via written communication with the review team Apple and explaining what's going on.

We are planning to create a prepared statement in our documentation in case this becomes a prominent issue.

---

With regards to future SDK versions, we discussed earlier today alternative approaches without having the scanners create false-positives.

Apple rejects the framework because the code references _UIShapeHitTestingView (a private API) in the mangled class name:

_TtC7SwiftUIP33_A34643117F00277B93DEBAB70EC0697122_UIShapeHitTestingView

The solution we are going to implement first is encoding the constants as Base64 and decode them at runtime, therefore any String-based binary analysis will not find the private API class name anymore. It's important to mention here that as stated above, we are not actually using private API and therefore this is not malicious behaviour.

An alternative approach would be matching on the 32-character hash (A34643117F00277B93DEBAB70EC0697122) instead of the full mangled name. This avoids mentioning the private API name while still identifying the class.

For future reference, here are some insights on the mangled class name hash:

• Structure: The hash A34643117F00277B93DEBAB70EC0697122 is a 32-character hexadecimal string (128 bits)
• Purpose: Swift's private discriminator used to differentiate private types with the same name in different contexts
• Stability: Stable for a given class name and context across builds
• Algorithm: Not publicly documented; implementation detail that may change between Swift versions

What Causes the Hash to Change?

• Class name changes (if Apple renames _UIShapeHitTestingView)
• Context/position changes (moving the class to a different namespace/enclosing type)
• Swift compiler version changes (less common for stable classes)

What does not change it:

• Internal structure changes (adding/removing properties/methods)
• Implementation changes

False Positive Risk?
Very low if matching the full 32-character hash:

• 128-bit space makes collisions extremely unlikely
• The hash appears in a specific context (P33_ prefix, before _ + class name)
• Matching the full hash string is safe

Risk increases if matching a shorter substring (e.g., just A346431).

[Nitin-UpSwing]

Hi @philprime, thanks for the clarification.

I understand that the SDK is not invoking or instantiating the private API at runtime. However, my confusion is that the exact private API name flagged by Apple (_UIShapeHitTestingView) is still present in the Sentry codebase and ends up in the compiled binary (via the mangled Swift class name used for string comparison).

From Apple’s review standpoint, the presence of this private API identifier in the binary seems to be sufficient for them to flag it as “usage,” even if it’s only part of a string-based comparison and not an actual API call.

Could you please confirm if this understanding is correct, and whether this presence alone is what’s triggering the App Store rejection?

And Please help us in the approval process as got rejected multiple times

[philprime]

I believe the understanding is correct, but it seems like an inconsistency by Apple handling this matter, as I just published an update of my test-app Flinky yesterday with the latest Sentry Cocoa v9.1.0 without any issues with the App Review team.

Were you able to communicate the matter to Apple? How did they react to you stating that while the string is in the binary, it's not actually used for private API? Happy to help further to get this rejected, but as I mentioned, I believe it's possible to clarify the issue with the review team.

[Nitin-UpSwing]

I did talk with the review team. They mentioned that this check has been recently introduced, and many apps have been told to get this sorted, and many of them have done so. After much talks on how many folks have raised similar issue on app store, they asked to fix it and they won't take app with these 2 private api in my binary of the app.

[philprime]

In that case the hotfix @itaybre is working on with #7123 is the best shot here. Which version of the Sentry SDK are you using?

[Nitin-UpSwing]

we are using 8.36.0 version of sentry SDK

[philprime]

Would upgrading to v9 be an option for you? If yes, we would consider implementing the fix for v9 only for now.

It should be available in the next v8 release.

[Nitin-UpSwing]

Can you help me with timeline for that release as our release got stuck ?

[philprime]

We just released v8.58.0 a couple of minutes ago. Please try it out and let us know if it resolves your issue.