APP STORE REVIEW
No — provided it isn't in the binary you submit. App Review evaluates the build you upload, so a debugging SDK only matters if it ships inside it. AppTelepath's iOS SDK is excluded from App Store configurations at build time, and refuses to start at runtime if a misconfigured build reaches the store anyway.
iOS SDK · free beta · never in App Store builds
App Review sees the binary you upload. Three things follow from that.
List AppTelepath only in configurations you never submit. :configurations in the Podfile keeps the pod out of the archive, so the submitted binary contains none of its code.
If it does get linked in, the SDK checks the distribution channel on start. App Store build: it stops and logs why. TestFlight: off unless you opt in.
Nutrition labels and PrivacyInfo.xcprivacy describe the app you submit. Excluded, the SDK adds no code, no size and no declaration.
With the integration below, and matching the SDK's own distribution gate.
| Debug | TestFlight | App Store | |
|---|---|---|---|
| SDK linked into the binary | Yes | Yes, if you list that configuration | No — excluded by :configurations |
| SDK starts | Yes | Only with allowTestFlight = YES |
Never — it detects the channel and stops |
| Talks to AppTelepath | Yes, once a workspace credential is set | Yes, once you allow TestFlight | No connection at all |
| App binary size | Grows by the linked static code | Same as Debug | Unchanged — nothing is linked |
| Privacy manifest and nutrition label | Not submitted to Apple | Uploaded to App Store Connect — declare what your own build uses | Nothing to declare for the SDK |
AppTelepath ships no PrivacyInfo.xcprivacy: it is not built for App Store distribution. What your own build has to declare depends on your integration, and Apple's review outcome at the time is what counts.
One Podfile line, one compile flag, placeholders instead of credentials.
Configuration names differ per project, so don't hard-code Debug. TestFlight, AdHoc and enterprise builds are usually Release-class and are allowed. List every configuration you never submit to the App Store.
Define TELEPATH_ENABLED in exactly those configurations. #if DEBUG is the wrong guard — it also switches the SDK off in the Release-class test builds you do want it in.
Info.plist references build settings; the real server URL and workspace key live in a gitignored xcconfig, and stay empty in the production configuration. If one Release configuration is also used for the App Store archive, add a separate Internal or Staging configuration instead.
# Podfile · list every configuration you never submit
pod 'AppTelepath', '~> 3.0',
:configurations => ['Debug', 'Staging']
// Debug.xcconfig · one per non-submission configuration
SWIFT_ACTIVE_COMPILATION_CONDITIONS = $(inherited) TELEPATH_ENABLED
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) TELEPATH_ENABLED=1
// AppDelegate.swift · compiles to nothing when the flag is undefined #if TELEPATH_ENABLED import Telepath Telepath.start() #endif
<!-- Info.plist · placeholders only; values come from a gitignored xcconfig --> <key>TelepathAgentServerURL</key> <string>$(TELEPATH_AGENT_URL)</string> <key>TelepathAgentWorkspaceKey</key> <string>$(TELEPATH_AGENT_KEY)</string>
The credential that ends up in a test build is device-only: whoever extracts it can impersonate a device, but cannot reach the console, the MCP endpoint or other devices. Never put an admin token in an app.
How you link the SDK decides how you exclude it — and whether you owe it a linker flag.
:configurations is the integration path that keeps the SDK out of specific build configurations. -ObjC is added for you: the pod builds as a static framework and vendors a static binary, so CocoaPods sets the flag itself.
A package dependency on your app target links in every configuration. If you need the SDK absent from the submitted binary, integrate through CocoaPods, or keep it on a separate test-only target. The #if TELEPATH_ENABLED guard still applies either way.
SwiftPM and manual xcframework installs must add -ObjC to Other Linker Flags. Without it the linker drops category-only translation units, and the symptom is a runtime unrecognized selector, not a link error. SwiftPM cannot add it for you — dependency packages may not use unsafeFlags.
Public evidence only: the compile-time simulator flag, whether embedded.mobileprovision is in the bundle, and whether an App Store receipt file actually exists.
A provisioning profile in the bundle means the build was not distributed through the store, so the SDK starts normally. It reports the channel it detected, so the console shows which build you are looking at.
No profile plus a sandboxReceipt means TestFlight, and the SDK stays off until you set config.allowTestFlight = YES or TelepathAgentAllowTestFlight in Info.plist. External testing reaches real testers, so that has to be your decision, not a default.
No profile plus a receipt file that is not a sandbox receipt means an App Store build. Telepath stops before connecting and logs the reason, pointing at the configuration list in your Podfile.
Neither a profile nor a receipt file is ambiguous, so the SDK starts and keeps warning. The direction is deliberate: this gate catches a misconfiguration, and a debugging tool that silently fails to connect is harder to diagnose than one that complains.
The gate blocks Telepath.start, not the linker. Once the SDK is linked in, its code is in the binary and a few probes read a persisted switch at +load. That is why step one — never linking it into a build you submit — is the real answer, and the gate is only a fallback.
Apple's privacy manifest and nutrition label requirements cover the app you submit and the SDKs inside it. With AppTelepath excluded from that binary, there is nothing about it to declare, and nothing it could collect from your App Store users.
AppTelepath ships no PrivacyInfo.xcprivacy. That follows from the same policy: the SDK is not built for App Store distribution, so it carries no manifest for a submission it is not part of. Leave it linked in a production archive and you get both problems at once — a missing declaration, and an SDK that refuses to start.
It does use APIs Apple groups under Required Reason — file timestamps, system boot time and user defaults — for reading the sandbox, sampling launch timing and inspecting stored values. One more reason it belongs only in builds you never submit.
In a test build you started, the SDK collects what a debugger collects: screenshots and recordings, logs and crashes, network requests, the view hierarchy, sandbox files, database queries and performance samples. It sends them to the AppTelepath hosted service, where your workspace and your agent read them. That data comes from whichever device runs the build — which is why allowing TestFlight is an explicit decision rather than a default.
What your own app has to declare — manifest entries, nutrition labels, disclosures to testers — depends on your integration and on everything else in your build, and Apple's review outcome at the time is what counts. We can tell you what our SDK does; we cannot answer for your binary.
Not by itself. App Review evaluates the binary you upload, so a debugging SDK only matters if it ships inside it. AppTelepath is meant to be excluded from App Store configurations at build time, and excluded that way it is not part of the review at all. Whether any particular build passes is Apple's call at the time.
Yes, if you decide to. TestFlight builds are usually Release-class, so list that configuration in the Podfile and set config.allowTestFlight = YES, or TelepathAgentAllowTestFlight in Info.plist. The SDK is off in TestFlight by default because external testing reaches real testers and the credential inside the build can be extracted. That credential is device-only: it can impersonate a device, but not reach the console, the MCP endpoint or other devices.
Not in an App Store build that excludes it — the requirement covers SDKs inside the app you submit. AppTelepath ships no PrivacyInfo.xcprivacy of its own, because it is not built for App Store distribution. What your own app must declare depends on your integration and on the rest of your build.
A few capabilities do: synthesizing touches for swipe, capturing frames for screen recording, and constructing a notification response for simulated push. They run only when an agent invokes that specific command, never on the launch path. Where a public path exists they fall back to it and report which one they used; where none exists the command says so instead of pretending it worked. That is another reason the SDK is limited to builds you never submit; for TestFlight uploads, Apple's checks are still Apple's call.
The SDK detects the App Store channel and stops before connecting, logging the reason. Its code is still in your binary, so fix the Podfile configuration list and the compile flag, then re-archive. The runtime gate is a fallback for a misconfigured build, not a substitute for excluding it.
Free beta, iOS SDK, one CocoaPods line. Your agent does the rest.
Start free