Just to clarify the earlier answer: Apple’s screenshot requirements say an iPad screenshot is required if the app supports iPadOS; it isn’t a minimum requirement for every iPhone app. Apple Watch screenshots are required for Watch apps. So the presence of those tabs by itself doesn’t mean your uploaded build has become universal or that you need to add iPad/Watch support. Since your build metadata says iPhone only, I’d check the archived build’s Supported Destinations / Targeted Device Family and confirm the selected build in this version is the one with that setting. If it is iPhone-only, follow App Store Connect’s validation for the iPhone screenshots and don’t add unrelated device screenshots just to fill the extra tabs. If ASC says a specific platform’s screenshot is required, check which build or Watch target is attached before submitting. Apple’s current screenshot specifications make the iPad requirement conditional, and its Watch app setup guide covers the separate Watch metadata.

There isn't a single public API that tells you which authorization check caused -25293. Apple defines errSecAuthFailed broadly as an authorization and/or authentication failure, so the code alone can't distinguish a bad ACL, an authentication requirement, or keychain state. Without changing access or reading the secret, I'd first record the exact query's nonsecret fields (class, service, account, access group, synchronizable and data-protection-keychain flags) and the returned OSStatus. Then compare the item's access group with the signed app's keychain entitlements, and confirm the query is targeting the same keychain type that contains the item. On macOS the legacy file-based keychain and the data-protection keychain behave differently; Apple's TN3137 explains how to tell which API path you're using. If the query and entitlements line up, capture a minimal reproduction and a sysdiagnose while the failure is happening for Apple. A user-visible Keychain Access prompt or a manual unlock may change the state you're trying to diagnose, so I wouldn't use that as the first test if the goal is to observe the failure unchanged. References: Security Framework result codes, TN3137: On Mac keychain APIs and implementations, keychain access groups.

I wouldn't expect A versus B to be faster just because the bullet loop is in a separate System. The important part is how much work each update does. RealityKit Systems are designed to update a query of matching entities together; Apple recommends using an EntityQuery and avoiding unnecessary work in update(context:). For bullets, try not to find the closest enemy by checking every bullet against every enemy on every frame. If a shot is aimed, choose its target when firing and store that target on the bullet. If bullets should hit whatever they reach, give them simple collision shapes and use collision events, with collision groups so bullets only test against enemies. Keep pooling, and remove expired bullets from active queries. If you really need nearest-target seeking, retarget occasionally or use a spatial grid instead of a full scan. I'd start with a BulletSystem that queries active bullets and moves them using the frame delta time, then profile with realistic enemy and bullet counts in Instruments. If the bullet count is small, the simpler implementation may already be fast enough. Apple's guides on RealityKit Systems and collision detection are useful starting points.

I would start by narrowing down whether this is a direction issue or an inset issue. A blank strip on one side usually means a view's frame, safe area, or layout margins changed; RTL by itself shouldn't add an arbitrary margin. Using UIAppearance to force the direction globally can make it hard to see which view is responsible, especially when the app switches languages while already running. As a test, remove those appearance settings and apply the direction at the app's root view/controller, then recreate the affected screen after the language change. On SDKs that support it, try a layout-direction trait override on the root controller and check that the intended direction reaches the affected descendants. Apple notes that a view's effective layout direction doesn't necessarily propagate through every part of its subtree: https://developer.apple.com/documentation/uikit/uiview/effectiveuserinterfacelayoutdirection Also log the affected view's frame, safeAreaInsets, layoutMargins, and effectiveUserInterfaceLayoutDirection in English and Arabic. Check that horizontal constraints use leading/trailing rather than left/right, and test after dismissing and recreating the screen. If the left gap remains, temporarily disable the appearance proxy settings one class at a time; that should identify whether a specific UIKit class is involved. UISemanticContentAttribute is intended to describe how a view's content should behave in RTL, so it may not be appropriate to force every view to the same value: https://developer.apple.com/documentation/uikit/uiview/semanticcontentattribute If you can share a small view-controller example and those inset values from both runs, it will be much easier to tell whether this is an app-level constraint issue or something specific to the Duo simulator.

I wouldn’t take Waze or Google Maps as confirmation that a custom speed badge is allowed. Apple’s current CarPlay navigation sample says the root map view should contain only the map, and that overlays should use CarPlay-provided templates. That makes a custom SpeedLimitView drawn over the map look outside the documented pattern, even if other apps appear to do it. There is a system CPMapPanel for navigation-related information, but Apple’s docs don’t specifically say that current speed or speed limits belong in it. I’d check whether the information can be presented through a supported CarPlay template, and ask CarPlay Developer Support to confirm the proposed placement before shipping. Keep it informational and noninteractive so it doesn’t compete with maneuvers or the road view. Apple’s navigation sample: https://developer.apple.com/documentation/carplay/integrating-carplay-with-your-navigation-app CPMapPanel: https://developer.apple.com/documentation/carplay/cpmappanel

Waiting for Review means Apple received the current submission but hasn't started reviewing it. Since the previous 2.1 message thread closed when you resubmitted, I’d focus on the current submission in App Store Connect: confirm the version and subscription are both in the submission you intended, and that the Account Holder has accepted any agreement that still shows as needing action. For the unanswered 2.1 questions, include the answers and walkthrough video in the current App Review Information, then contact App Review about this specific submission through App Store Connect. Explain that the earlier message thread closed after resubmission and ask whether the current submission needs anything else. Apple says the review-status page is where to track the queue, and App Store Connect is the best way to contact the specialist handling an ongoing submission. I wouldn’t remove and resubmit again just to try to restart the queue, since that can create a new review cycle. Status guide: https://developer.apple.com/help/app-review/after-submitting-for-review/review-status Contact App Review: https://developer.apple.com/help/app-review/after-submitting-for-review/contact-app-review

For an organization enrollment, Apple says Developer Support verifies the organization details and then emails the next steps. The forum can’t check an enrollment case, so the useful next step is to follow up through Apple Developer Support using the existing case and include the Enrollment ID. Mention that you replaced the documents Apple flagged, and ask whether the corrected ID and signed letterhead document were received and whether anything else is needed. I’d avoid starting a second enrollment while this one is processing, since it won’t move the current verification along. You can also sign in to the developer account used for enrollment and check the membership status there. Apple’s enrollment guide explains the organization verification process: https://developer.apple.com/help/account/membership/program-enrollment

From what you describe, the key issue may be guideline 4.3(b), not just the horoscope games. Apple specifically lists fortune telling as an established category and says new apps need to offer a meaningfully different or improved experience. A consultation marketplace can still look similar if the main difference is which astrologers are listed. In App Store Connect, reply to the rejection and ask which part of the current build they consider indistinguishable, and what they would need clarified. Then point them to the specific features that make this app meaningfully different, with exact steps to find them and a short review video if the distinction is not obvious. Avoid another round of broad feature removals until you know what concern you are addressing. If you believe the current decision is wrong, Apple has a separate appeal process. Guideline 4.3(b): https://developer.apple.com/app-store/review/guidelines/#spam How to contact App Review: https://developer.apple.com/help/app-review/after-submitting-for-review/contact-app-review/

Apple's public documentation doesn't explicitly guarantee whether the Team ID or an existing Developer ID certificate stays the same and active after an individual-to-organization conversion. Apple describes this as updating your existing membership, and says a Team ID is assigned to a membership, so I would expect the account to remain the same, but I wouldn't rely on that assumption for a signing or release plan. Before proceeding, ask Developer Support on your conversion case to confirm both points in writing: whether your Team ID will remain unchanged, and whether your current Developer ID Application certificate and signing identity will remain usable. Don't revoke the certificate yourself. Keep a secure backup of the certificate and private key. Apple notes that revoking a Developer ID certificate can stop users from installing or launching software signed with it. Apple's conversion instructions are here: https://developer.apple.com/help/account/membership/updating-your-account-information/ Team ID: https://developer.apple.com/help/glossary/team-id/ Developer ID certificate behavior: https://developer.apple.com/help/account/certificates/create-developer-id-certificates/

For your first app, the forms are not a separate step you have to fill in after every rejection. Open the rejection in App Store Connect and read the message in App Review. Fix the specific issue there, then resubmit. If the status now says Waiting for Review, Apple has received the submission but has not started reviewing it yet. Check the app information and compliance sections only if App Store Connect says something is missing. Apple's status guide explains the queue states: https://developer.apple.com/help/app-review/after-submitting-for-review/review-status If your release is tied to a real upcoming event, or you need to fix a critical bug, you can request an expedited review and explain the date and why the app is needed for it. A large waitlist by itself may not qualify. The request form is here: https://developer.apple.com/help/app-review/after-submitting-for-review/request-expedited-review

One thing stands out in the wording: Apple's current guideline 4.3(a) is about submitting multiple Bundle IDs for the same app, while games that are hard to distinguish from established titles are covered under 4.3(b): https://developer.apple.com/app-store/review/guidelines/. If this is one app under one Bundle ID, I’d ask App Review to clarify what made them apply (a), and whether they see it as a duplicate of another submission or as an indistinguishable category game. A new name or metadata alone probably won’t address that. If you submit again, make the product differences obvious in the actual gameplay and review notes. I don’t have personal 4.3(a) rejection experience, so this is based on the guideline text.

Apple's reinstatement form is here: https://developer.apple.com/contact/request/app-review/termination/. If it hangs, sign in first with the Apple Account tied to the terminated membership. If it still fails, contact Developer Support at https://developer.apple.com/contact/ and ask for Membership support. Keep the appeal reference for that private case and remove it from this public post.

Waiting for Review means the submission is still in the queue; several days can happen, and the status alone doesn't show that anything is missing. Check App Store Connect for any review message, agreement or compliance item, and make sure the review notes explain any account or purchase flow. Since you already have a support case, follow up there with the submission ID and ask whether anything is blocking review. I'd leave the submission in the queue rather than withdraw and resubmit, since that can restart the wait.

Apple's Registration API is for platform integrators: you manage merchant Apple Pay setup using shared keys and certificates. I don't see a per-country PI ID requirement in Apple's docs. You still need API access approved and each merchant's domains registered and verified. Apple says payment request countryCode is the merchant's principal place of business, often the settlement location; check with your PSP. currencyCode is the transaction currency, while supportedCountries filters card-issuing countries. Confirm country, networks and currencies with your acquirer. Acceptance depends on PSP support. Docs: https://developer.apple.com/documentation/applepaywebmerchantregistrationapi/ and https://developer.apple.com/documentation/applepayontheweb/applepaypaymentrequest/countrycode

FAIL_CLOSED covers missed deadlines and queue-full drops. Docs don't specify pending AUTH on client deletion or later denial after disconnect; es_delete_client only destroys/disconnects. For strict denial, use separate enforcement during ES loss and ask DTS for a version-specific guarantee. Docs