Overview

Hello, Our app NUTRIFIT FEMME has been in Waiting for Review for approximately one week. There are no rejection messages or requests for additional information in App Store Connect. Could someone from Apple please confirm whether the submission is processing normally or whether any action is required from our side? Thank you.

Hello, I’m trying to enroll in the Apple Developer Program, but my enrollment could not be completed. I contacted Apple Developer Support and received the following response: “For one or more reasons, your enrollment in the Apple Developer Program couldn't be completed. We can't continue with your enrollment at this time.” Unfortunately, no specific reason was provided. I would like to understand what could cause this and, more importantly, whether there is anything I can do to resolve the issue and successfully enroll. Has anyone experienced a similar situation? I’m particularly interested in whether this can be caused by identity verification, Apple Account information, billing/payment details, country or region information, organization details, or another eligibility requirement. I’m happy to provide Apple with any additional documents or verification they require, but at the moment I don’t know what exactly needs to be corrected. If you encountered the same message and eventually managed to enroll, I would really appreciate hearing what steps helped you resolve it. Thank you!

I'm working on an FSKit module for EdenFS, a source control virtual filesystem. A teammate of mine asked about FSKit here a couple of years ago before its first public release. Since then, FSKit's feature development has made it feasible for our use case, so we're looking at FSKit again as a replacement for our current NFSv3 solution. The cache coherency API makes FSKit especially appealing to us, since we need a way to invalidate the kernel's caches after a checkout/goto operation. In another thread, an Apple engineer described it as "designed to manage cache coherency for network file systems and other kinds of file systems where an outside actor might modify the data outside of the kernel's normal data flow," which fits this case. As I understand it, there are two caching modes we could use: Negotiated caching, where FSKit calls the volume's open with the requested cache mode on every open of a file that isn't already open, and the volume replies with the coherency type it grants. FSKit then calls close once all references are released. That results in two extra round trips per file access, which is measurable on a workload that touches many thousands of files. Unilateral caching, where the volume sets isDataCacheInhibited = true, and FSKit stops calling the protocol's methods. The kernel then caches on its own, meaning those extra round trips are eliminated. As far as I can tell, setCacheState(for:cacheMode:coherencyType:action: .revoke) is the only invalidation mechanism FSKit gives a volume. With isDataCacheInhibited = true, that call returns ENOTSUP (NSPOSIXErrorDomain code 45) and the kernel keeps serving the old contents. I reproduced this on a minimal in-memory module and filed it as FB24996000 with the example attached, tested on macOS 27.2 (26B5091g). Is this ENOTSUP intended? The setCacheState documentation says it returns ENOTSUP for volumes that don't conform to FSVolume.DataCacheHandler, and my sample does conform. However, the isDataCacheInhibited documentation says it "instructs FSKit not to call this protocol's methods, even if the volume conforms to it". Is FSKit intentionally treating an inhibited volume as if it doesn't conform? If so, is there any other way to tell the kernel that cached data is stale in this mode? The documentation also states that the property is only read at loadResource, so we can't switch to negotiated caching just to serve a goto command either. For a source control filesystem like ours, we'd at least need to invalidate the kernel cache at specific points (after a goto) for correctness. If per-item invalidation is unsupported in this mode on purpose, would Apple consider a way to invalidate a whole volume's cache at once? Linux FUSE added FUSE_NOTIFY_INC_EPOCH (https://lists.openwall.net/linux-kernel/2025/02/20/1523) for a similar reason, so a server can invalidate every cached lookup in one call instead of one entry at a time. Negotiated caching does work (setCacheState(.revoke) succeeds in that mode) but unilateral caching is ideal for us due to the performance improvement and simpler implementation.

My first iOS app, Yug Purushottam, was originally submitted to App Review on September 27, 2026 at 2:56 PM Pacific Daylight Time. Apple subsequently returned the submission under Guideline 2.1 – Information Needed – New App Submission and requested additional information because the developer account has limited App Review history. I provided everything requested, including: A screen recording captured on a physical iPhone showing the app launch and normal user flow Registration and login flow Account deletion and revocation flow Detailed information about the app’s purpose, target audience, external services and regional behavior Updated App Review Information and Notes The submission was then successfully resubmitted on Friday, October 2 at 6:25 AM, and App Store Connect has remained at “Waiting for Review” since then. It has still not moved to “In Review.” I have also already submitted an Expedited App Review Request and contacted Apple through the App Review Status support channel, but so far there has been no progress. The app is complete, has been tested on a physical device, and all information requested by App Review has already been supplied. Has anyone recently experienced a similar delay with a first App Store submission, particularly after a Guideline 2.1 information request? Is there any further escalation route available when a submission remains in “Waiting for Review” despite an Expedited App Review Request and an App Review Status support case? Any recent experience with how long this situation eventually took to resolve would be very helpful.

Hi everyone, I'm sharing a tax setup problem in App Store Connect that other developers have also reported. Apple Finance support case — Case-ID: 22285494 My company is a Wyoming single-member LLC. It is a disregarded entity for U.S. federal tax purposes and has not elected corporate tax treatment. I am the sole owner, a Japanese citizen and tax resident of Japan. I am not a U.S. citizen or resident alien. The organization account uses the LLC's U.S. legal details. App Store Connect only offers W-9. Line 1 is locked to the LLC's name, and the form requires me to certify that I am a U.S. person under penalties of perjury. I have not submitted it. Our Paid Apps Agreement remains “Pending User Info.” The IRS W-9 instructions, page 3, say that a foreign owner of a disregarded entity must provide an appropriate W-8 instead of W-9, even if the foreign owner has a U.S. TIN. IRS W-9 instructions (page 3): https://www.irs.gov/pub/irs-pdf/fw9.pdf#page=3 Apple Finance told me to complete the current W-9 first so the Paid Apps Agreement can become active. They said I could submit the correct W-8 afterward. I have explained my ownership and tax status and referred to the IRS instructions, but their replies do not address these details. I keep receiving the same instructions. Their full instructions are attached below. Apple Finance instructions — full procedure I sent Finance the IRS instructions and asked whether my initial tax setup could be corrected or reset. Google Play approved my W-8BEN using my name and Japanese permanent residence address, while the company profile kept the LLC's U.S. details. I mentioned this only to explain my tax setup and understand whether I had made a mistake in Apple's setup. The latest reply from Apple Finance was: “Because you used a US legal entity address and we ARE NOT GOOGLE, you need to do the instructions previously provided. If not, the agreement will NEVER EVER activate.” I found this response discouraging because my underlying concern remains unanswered. Also did not explain how I could accurately certify that I am a U.S. person, given my tax status and the IRS instructions. I do not want to submit an inaccurate tax certification and face tax problems later, even if the form is corrected afterward. My app is ready, but this issue is blocking the Paid Apps Agreement and delaying the planned launch. I keep getting the same instructions without an explanation of how they fit the IRS rules. The delay is costing me time and money. It is also hurting my confidence and motivation after all the work I have put into the app. I also found the following reports of the same issue on these forums: W-9 shown for a non-US-owned single-member LLC Foreign-owned US LLC stuck on W-9 W-9 only shown; Finance case unanswered since August W-9 only; no W-8 questionnaire or option Related earlier discussions: Tax Form for US LLC owned by Non-Resident Alien Foreign owner explains why an existing W-9 workaround does not apply Thank you to anyone who can share a verified resolution. Best Regards, Z.Kozakai

I'm investigating a Siri invocation failure with an explicitly declared App Shortcut phrase. The same underlying App Intent works when run directly in Shortcuts and when invoked by the name of a saved personal shortcut. Environment: iPhone 17 Pro Max, iOS 27.2 beta (24B5099f), clean restore without a backup. iPhone and Siri languages: Italian. Standard Siri, no Siri AI. Xcode 27.2 (27B5028f), iphoneos 27.2 SDK. Italian App Shortcut phrase and app metadata. PetroCheck 1.3 (637), already open during the failing invocation. The published phrase is “Trova carburanti vicini con PetroCheck”, declared using \(.applicationName). This is a phrase-based App Shortcut; the intent does not adopt an App Schema. What I observe: Saying the App Shortcut phrase produces a generic Siri error: “mi dispiace, ma si è verificato un errore”. Running the action directly in Shortcuts succeeds and records execution in the app's intent journal. Saving a personal shortcut named “Diagnostica Petro” with just that action, then saying “Esegui Diagnostica Petro”, also succeeds and records execution. Returning only a minimal Text snippet from the original intent does not resolve the phrase invocation failure. For two captured failing phrase invocations, the device logs show BackgroundShortcutRunner failing to resolve the workflow reference: -[WFWorkflowDatabaseRunDescriptor(Conversion) workflowReferenceWithDatabase:error:] Couldn't find shortcut with descriptor: <private> reason: unable to resolve workflow reference from descriptor The first of these attempts has no new entry at the recorded start of perform(). The descriptor itself is redacted, so I cannot identify which reference Siri selected. A subsequent attempt also contains these assistantd messages shortly before the descriptor error: Found no AppShortcutTargets! Could not cast to VoiceCommand task to create AppShortcut invocation AppShortcuts enablement result=false I am including these as observations, without interpreting them as proof of a disabled setting. Calling updateAppShortcutParameters() at launch did not resolve the failure. I checked the compiled device bundle's App Intents metadata: the action is discoverable, its fuel parameter is optional, and the declared shortcut points to the correct intent. The Italian training metadata contains the phrase and the application name PetroCheck. This verifies the compiled metadata, not the device's registration database. I then built a separate app, “Prova Petro”, with a different bundle identifier, a fresh phrase, one intent with no parameters, and a dialog-only result. It has no location, networking, snippet or dependencies from the original app. The Siri phrase fails in this app too. I have not yet captured its intent diary or host logs, so I cannot claim that the minimal app fails at exactly the same stage. These are the core declarations from the compiled minimal project; the sample's journal calls are omitted here: import AppIntents struct RoutingProbeIntent: AppIntent { static let title: LocalizedStringResource = "Verifica collegamento Siri" static let supportedModes: IntentModes = [.background] func perform() async throws -> some IntentResult & ProvidesDialog { return .result(dialog: "Il comando Siri ha raggiunto Prova Petro.") } } struct ProbeShortcuts: AppShortcutsProvider { static var appShortcuts: [AppShortcut] { AppShortcut( intent: RoutingProbeIntent(), phrases: ["Verifica Siri con \(.applicationName)"], shortTitle: "Verifica collegamento Siri", systemImageName: "checkmark.circle" ) } } The minimal app's display name is Prova Petro, and the spoken phrase is “Verifica Siri con Prova Petro”. Its App.init() calls ProbeShortcuts.updateAppShortcutParameters(). The extracted metadata confirms one shortcut, zero parameters, dialog-only output, and the Italian application name and phrase. Has anyone reproduced this difference between an App Shortcut phrase and a named personal shortcut on iOS 27.2 beta, particularly with Italian phrases? Feedback Assistant: FB25077916. The complete minimal Xcode project and scoped diagnostics are attached to the report. Is there anything missing from this setup, or a supported way to diagnose the unresolved shortcut reference? Comparisons with other OS builds, languages or devices would be useful. I have not yet established a regression against a stable OS release. Prova Petro minimal source and Siri routing logs

I am looking for the correct escalation route for an unresolved Individual Apple Developer Program enrollment. I have already contacted Developer Support; the difficulty is obtaining an actionable response on the existing cases. Timeline: 28 June 2026: enrollment efforts began. During troubleshooting, I tried enrollment through the website and, following Support's instructions, the Apple Developer app. I supplied the requested screen recording, device information and identification documents, and the case was referred to an internal operations team. Two enrollment attempts produced order acknowledgements, but no visible card authorization or charge and no active membership. The second attempt used another newly created Apple Account to check whether the issue was specific to the first account; its order acknowledgement is dated 29 July. 3 August: Support stated that enrollment could not be completed and Apple could not continue at that time, without identifying a specific reason or corrective action. Follow-up emails on 3, 6 and 14 August, followed by escalation requests on 5 and 25 September, have not received a substantive response as of 5 October. That is five follow-up contact attempts since the 3 August reply. This is blocking the iOS launch of my business. I need to understand whether the unresolved barrier is technical or verification-related, or whether there is a final enrollment decision and a route for reconsideration. Has anyone found a working route to obtain senior review of an existing enrollment case when the normal support channel stops responding? If an Apple staff member can help route the matter, I can provide the case references through an official private support channel. I am asking how to reach the team that can give an actionable next step or a clear written outcome. My separate question about Organization eligibility as a sole proprietor should not obscure these unresolved Individual enrollment attempts. Thank you for any specific guidance.

I am a private individual working on a personal panorama viewing and reprojection project. I have been investigating the geometry of panoramas produced by the iPhone Camera app, with extensive analytical and research assistance from OpenAI's ChatGPT. My goal is to determine the physical viewing direction (longitude and latitude, or equivalently a 3-D viewing ray) corresponding to each pixel in a finished iPhone panorama. I have been able to recover much of this geometry from information contained in the panorama itself. Controlled tests on several iPhone models indicate that I can accurately determine the effective focal length of the perspective source camera, camera rotation during capture, endpoint geometry, horizontal field of view, and gravity-relative camera orientation. The remaining problem is the absolute vertical/latitude mapping in the finished panorama. The gravity/orientation information allows me to determine where a known physical latitude—for example, the true horizontal plane (0° latitude)—falls in the individual source-camera frames. However, I have not found a documented way to determine exactly where those source-frame viewing rays are placed vertically in the final panorama bitmap. My investigation suggests that the Camera app performs additional geometric processing during panorama assembly, including geometric/perspective correction and the selection, cropping and/or rotation of image slices before they are blended into the panorama. What I have not been able to determine is whether the information needed to reconstruct that source-ray-to-finished-pixel mapping is retained anywhere in the finished panorama or is available through a supported Apple API. My primary question is therefore: Is there a documented or supported way to determine the physical viewing ray corresponding to each pixel in a panorama produced by the iPhone Camera app, including its absolute vertical/latitude mapping? More specifically: Is the projection used for the finished Camera panorama documented? Is the gravity-relative orientation or vertical reference of that projection available through supported metadata or an API? Is sufficient information retained in the panorama to reconstruct the geometric correction and placement applied to source images/slices during panorama assembly? If that information is not retained in the finished image, is there another supported framework or API that provides it during or after panorama capture? I am not trying to reproduce Apple's image blending or other proprietary image-processing algorithms. I simply want to interpret the geometry of the finished image accurately enough to reproject it—for example, to cylindrical or equirectangular coordinates—and assign physical longitude and latitude to its pixels. I have controlled test panoramas from multiple iPhone generations and considerably more technical detail about the investigation. I would be happy to provide example files, measurements, or additional information if that would be helpful. Even confirmation that the required vertical-placement information is not retained or exposed would be very useful.

Hello, I am an undergraduate student working on a non-commercial university capstone project. I would like to clarify whether it is permitted to: Temporarily stream the 30-second preview audio provided through the iTunes Search API and process it in memory using the Essentia audio analysis library to extract numerical audio features. Store only the extracted numerical audio features (such as BPM, key, energy, and timbre) in a database, while immediately discarding the original preview audio after analysis. Could you please confirm whether this use of the previewUrl is permitted under Apple's terms and guidelines? Thank you.

While building an SMB 2/3 client as an FSKit file system module (FSUnaryFileSystem + FSVolume, the macOS 27 Handler protocols), I ran into a number of framework-level issues. I have filed each one with a title starting "FSKit:" so they are easy to find, and every report has a minimal reproduction attached: a small in-memory FSKit module (no network, no disk, no cache of its own), so none of them depend on SMB. All were measured on macOS 27.0 (26A5406e and 26A5416b) with Xcode 27.0 beta 5. Summaries below in case anyone else is hitting these. FB24419773: renameatx_np with RENAME_SWAP returns success but destroys the destination file. On any FSKit volume a RENAME_SWAP is performed as an ordinary clobbering rename: rc=0, but the destination's contents are silently lost instead of exchanged. The module cannot refuse it because renameItem receives no flags; a swap and a plain overwriting rename look identical. (RENAME_EXCL works correctly.) FB24419825: a negative lookup is cached permanently. Once anything gets ENOENT for a name on an FSKit volume, the kernel serves that ENOENT for the life of the vnode. If the file is created later (for example by another machine on a network volume), it stays unopenable by that name indefinitely, while ls of the same directory lists it. There is no API through which a module can report that a name now exists. FB24419858: a data-cache grant from openItem can be applied after the module has already invalidated. The grant in FSOpenItemResult is applied asynchronously after the module's reply, and an invalidation issued in that window succeeds (setCacheState returns no error) and is then overwritten by the stale grant. The result is a kernel cache no future event will invalidate; readers see stale data. FB24419870: synchronize(flags:) is never called on a URL-backed volume. fsync(2), fcntl(F_FULLFSYNC), fcntl(F_BARRIERFSYNC) and sync(8) all return success with zero calls reaching the module, so durability is reported and never established. A packet capture of the same SMB share shows five SMB2 FLUSH requests through Apple's smbfs and zero through an FSKit module. FB24419894: FSItemSetAttributesRequest.consumedAttributes is never observed, and wasAttributeConsumed(.changeTime) answers about the wrong attribute. Consuming everything and consuming nothing are indistinguishable to the caller (chmod returns 0 either way), even though the setAttributes documentation says the upper layers will detect unsupported attributes. Separately, wasAttributeConsumed answers YES for changeTime when only accessTime was consumed, and never answers correctly about changeTime itself; this part reproduces by constructing the request directly, no file system needed. FB24419911: restrictsOwnershipChanges = true does not reject non-superuser chown. The property is documented as "the volume rejects a chown(2) from anyone other than the superuser", but on an -o owners mount a non-root chgrp is delivered to the module's setAttributes anyway, so every module has to enforce the policy itself. FB24419932: a failed activate wedges the resource URL. After a module's activate throws once, every later mount of the same URL string fails with "Resource busy" (fskitd logs "Can't start new task, resource state is 5"), while the same volume under a different URL spelling mounts fine. For a network module the ordinary trigger is one wrong password. Recovery requires killing both fskitd and the extension process. FB24419964: enumeration cannot report extended-attribute presence. FSItem.Attributes has no per-item "has xattrs" field, so one cold ls -l of a 500-entry directory costs about 2,000 FSKit boundary crossings: an xattr call per entry plus a "._name" AppleDouble sidecar lookup per entry, and each of those ENOENTs is then pinned by FB24419825. Suggestion: a per-entry hasExtendedAttributes flag so getattrlistbulk can be satisfied from the enumeration. FB24419974: no byte-range lock operations. flock(2) and fcntl(2) locks on an FSKit mount stay kernel-local and never reach the module, so advisory locks cannot coordinate between clients of a network file system. Suggestion: an optional lock-operations handler. FB24419979: no ACL or security descriptor operations. ls -le, chmod +a, acl_get_file(3) and cp -p with ACLs cannot work on any FSKit volume; a network server's real ACLs are invisible behind synthesized mode bits. The nearest surface, FSVolumeAccessCheckHandler, can only be asked yes/no questions about a descriptor the module has no way to provide. Suggestion: an optional ACL-operations protocol. If any of these are biting you too, duplicate feedbacks referencing the FB numbers above genuinely help with prioritization.

HI. I'm trying to renew my Apple Developer membership but the checkout is not working. After I click the 'Renew Membership' button and sign into the Apple Store, the web page shows a spinner and nothing else happens. Safari, Chrome & Firefox all show the problem so it doesn't appear to be a problem at my end.

On iOS [27.x (build)], LiveCommunicationKit shows Handle.value on every system surface and ignores Handle.displayName. That forces a choice that CallKit doesn't: Put a stable account id in value (as WWDC26 session 226 recommends, so Recents redial can identify the person), and the raw id appears on the incoming call screen, the banner and in Recents. Put the person's name in value so the UI reads correctly, and a redial from Recents hands back only the name, which can't reliably identify anyone. Minimal reproduction let configuration = ConversationManager.Configuration( ringtoneName: nil, iconTemplateImageData: nil, maximumConversationGroups: 1, maximumConversationsPerConversationGroup: 1, includesConversationInRecents: true, supportsVideo: false, supportedHandleTypes: [.generic, .phoneNumber, .emailAddress] ) let manager = ConversationManager(configuration: configuration) let remote = Handle(type: .generic, value: "u-1234", displayName: "Jane Appleseed") try await manager.reportNewIncomingConversation( uuid: UUID(), update: Conversation.Update(members: [remote], capabilities: []) ) Expected: the incoming call UI and the Recents row show "Jane Appleseed". Session 226 says displayName is "what the system shows when it can't match the handle to a contact". Tapping the Recents row delivers an INStartCallIntent whose contact personHandle.value is u-1234. Actual: the full-screen ring, the foreground banner and the Recents row all show u-1234. Tapping the row does deliver INStartCallIntent with personHandle.value == "u-1234", so redial works, but the user never sees the name. What we tried, all with the same result (the value is shown): Handle.Kind set to .generic, .phoneNumber or .emailAddress, with every kind listed in supportedHandleTypes Conversation.Update(localMember:) set to the local user's handle activeRemoteMembers set to the remote handle, and localMember plus activeRemoteMembers together Donating an INInteraction (an INStartCallIntent whose INPerson has personHandle set to the id, displayName set to the name and customIdentifier set to the id) when the conversation ends. The donation succeeds, but the Recents row and the redial payload don't change. CallKit comparison, same device: CXCallUpdate.remoteHandle = CXHandle(type: .generic, value: "u-1234") with localizedCallerName = "Jane Appleseed" shows the name on the ring and in Recents. A redial from Recents delivers personHandle.value == "u-1234". That's the behaviour we expected from LiveCommunicationKit. Questions: Is Handle.displayName meant to be shown when the handle doesn't match a contact? If so, is there a configuration step we're missing? If this is a bug, is there a supported way with LiveCommunicationKit to show a name while keeping a stable identifier for Recents redial? Filed as FB24933340. Device: iPhone 15 pro, iOS [27.0.1].

I have an App where I use the UISheetPresentationController to present a menu as a "drawer" (like the "FindMy" or "Maps") App. Because the sheet is presented over a map, I made the sheet semi-transparent/blurry, so the Map shines through, which looks nice. The sheet is using a UITableView with the "insetGroup" style, so the table cells have the nice rounded borders and there are margins to the sheet borders. When running the App on the iPhone Duo (Simulator) on the outer display, the tableView does no longer respect the "insetGroup" style, it is rendered like it would have the "plain" style, which destroys everything that look good. No rounded borders, no margins. However if I opt-out of the automatic "vertical toolbar behavior" (overriding preferredVerticalBarBehavior so it returns "disabled"), then everything looks great again, however then the sheet content might overlap with the sidebar icons and camera because it now covers the whole area up to the right screen border. Is this supposed to be this way (if yes, why?), is there a way to fix this, or do we have to wait for a bugfix within iOS 27.1? The tableview still claims to have the "insetGrouped" style, just it does not render this way. I did not see any similar issues under other circumstances. Only UISheetPresentationController seems to be affected by this. Is there a way to correctly detect if the App is running on an iPhone Duo, so we could use this detection to add workarounds for such issues?

Hello. I have setup a StoreKit testing in the app that was and still is perfectly working on iOS 18. Unfortunately when run on iOS 26 the following error gets printed in the console after calling Transaction.currentEntitlement(for:) method: Failed to verify certificate chain due to client recoverable failure: Error Domain=NSOSStatusErrorDomain Code=-67843 "“StoreKit Testing in Xcode” certificate is not trusted" UserInfo={NSLocalizedDescription=“StoreKit Testing in Xcode” certificate is not trusted, NSUnderlyingError=0x109de7e10 {Error Domain=NSOSStatusErrorDomain Code=-67843 "Certificate 0 “StoreKit Testing in Xcode” has errors: Root is not trusted;" UserInfo={NSLocalizedDescription=Certificate 0 “StoreKit Testing in Xcode” has errors: Root is not trusted;}}} I'm not seeting any StoreKit Testing certificates in phone's certificate trust settings. This test was performed on iOS 26.0 (23A341) with app built in Xcode 16.4. FB20339145

To learn how to prevent copycat and impersonation rejections, visit 4.1 - Preventing copycat and impersonation rejections on App Review Help.

To learn best practices for before and after submitting your app for review, visit App Review Help.

To learn about supporting your app on multiple devices, visit Test your app on compatible devices on App Review Help.

To learn how to best prepare your app for an efficient review, visit Test your app on compatible devices, Configure In-App Purchases for review in the sandbox, and Provide information for a complete review on App Review Help.

Since apps built against iOS 27.1 RC are now submittable to App Store Connect, when is Xcode 27.1 going to be available for Xcode Cloud?

Hello, I would like to clarify the exact technical behavior of the App Store Server API (V2) and StoreKit under the following two specific scenarios: Case A (Production Account on Sandbox Endpoint): If a user with a production Apple Account attempts to purchase through a build pointing to the Apple Sandbox environment (or Sandbox API), how does the Apple server handle this transaction and its data lifecycle? (Does StoreKit block this at the client-side, or does the API return a specific error code?) Case B (Restoring Cleared Sandbox Data): If a Sandbox tester's purchase history is cleared/deleted on the Apple server, and the app subsequently requests a "Restore Purchase" or queries the App Store Server API using a previously valid transactionID from that account, what specific error code (such as 4040010 TransactionNotFound) or empty response does the Apple server return? I would highly appreciate your confirmation or any technical insights on these behaviors. Thank you!