I checked Apple's current support instructions, and the button is conditional. “Share Age Range Again” may appear only if the account has moved into a new age range or previously denied sharing. If the app already shows Shared and neither condition applies, the app detail page may have nothing to tap; there isn't necessarily a per-app unshare control there. For a child account, the family organizer or parent can manage the sharing preference from Family settings. If you're trying to repeat the consent prompt during development, Apple's WWDC demo describes Share Age Range Again as the way to clear the cached response, but the control may not be available for every existing Shared entry. What iOS version is this device on, and is it an adult or child Apple Account? Those details matter here. Apple's support article says the button may be available after an age-range change or a prior denial; it doesn't say every Shared entry can be reset manually.

The docs define anchor as the point on the label's bounding box that attaches to the axis position. So .topLeading should attach the label's top-left corner to that tick; it doesn't change the tick position itself. Given you have an iOS 26 vs 27 comparison and a Feedback ID, this does look like a useful regression report. For a temporary workaround for the first label clipping at the chart edge, you could try reserving a little start padding in the X scale range with chartXScale(range: .plotDimension(startPadding: 20)) and see whether that gives the label room. It changes the plot layout, so check the tick and mark alignment too. If the anchor still behaves differently in a minimal sample, include that sample and the before/after screenshots with your existing Feedback report. Apple's AxisValueLabel docs define the anchor this way, and plotDimension(startPadding:endPadding:) can reserve space at the start of the plot.

One detail that may help narrow this down: Apple's docs describe multiLabelAlignment as how the axis labels align with each other. It doesn't describe alignment of multiple lines inside one label. If your actual label text contains a newline and the issue is within that text, try supplying a Text view and setting multilineTextAlignment(.trailing) on it, while keeping anchor for positioning the label as a whole. If your minimal repro still fails with ordinary single-line labels, that points more directly to a Charts regression. Also, the snippet appears to show a literal string rather than interpolation for the y-value. If that was only a formatting issue in the post, disregard this; otherwise use "y-(Int(revenue))" in Swift.

I don't know of a public way to ask ManagedSettings whether a specific shield is actually being enforced. Apple's APIs let you set the shield, but this result looks like an OS-level issue from the A/B tests you described, especially since the same child device blocks when the parent is also on iOS 18.7.1. I'd file a Feedback Assistant report with the exact matrix, device models, build numbers, the Family Controls authorization status on both devices, the decoded token counts, and sysdiagnose from the iOS 27 child shortly after reproducing it. Keep a copy of the selection's encoded data and confirm that decoding succeeds and applicationTokens isn't empty before assigning the store. If possible, add a test where the selection is created on an iOS 27 parent and sent to the same iOS 27 child; that would help separate token-versioning from the mixed-version family setup. I wouldn't treat the release-note issue number as confirmation that this is the same bug. Apple's docs describe these as opaque tokens shared within a Family Sharing group, and say they become void if authorization is revoked, so check that authorization is still valid on the child. If it reproduces with valid authorization and nonempty tokens, the Feedback report is the useful next step; I don't know of a reliable app-side workaround for a shield the OS isn't enforcing. References: [FamilyActivitySelection](https://developer.apple.com/documentation/familycontrols/familyactivity

A few parts of your flow match Apple's docs, with one important detail on validation. The Registration API is intended for platform integrators, and the integrator manages the merchants' Apple Pay setup. Each registered merchant has its own internal identifier and domain list. The verification file is associated with your platform integrator ID; Apple says to distribute that file to each merchant and host it at the required .well-known path on every domain before calling Register Merchant. For encryptTo, Apple's request reference says to use the platform integrator ID by default. If another party decrypts the payment data, use that party's platform integrator ID or merchant ID instead. For onvalidatemerchant, the browser sends the validationURL to your server. Your server requests a session from Apple and returns the one-use merchant session to the page. Apple explicitly says not to request the merchant session from the client. I don't see Apple's public docs specify whether a single wrapper library is preferred for canMakePayments() or applePayCapabilities(). I'd treat that as an integration design choice, provided the merchant page uses the Apple Pay JS flow for its registered domain and checks eligibility with the appropriate merchant identifier. For token ownership or shared-domain edge cases, confirm with Apple through your Registration API support channel before going live. References: Web Merchant Registration API, domain verification, RegisterMerchantRequest, and Providing Merchant Validation.

Apple's banking guidance says to select the country or region of the bank branch, enter the bank's own details (not an intermediary bank), and make sure the account holder matches the individual or legal entity enrolled in the Developer Program. If the bank isn't listed, Apple says it may be unable to send payments to that bank. I'd wait for Apple Finance to confirm whether TEB or another Kosovo bank is supported before trying a bank in a neighboring country or an online account. The account, territory, tax details, and your developer enrollment need to line up, so I wouldn't assume Wise or Revolut will work just because they provide an IBAN. You could ask Apple Finance specifically whether Kosovo is supported for payouts and what bank code format they expect for your IBAN. Apple's references: Enter banking information and Banking information.

Since the resubmission includes the monthly and annual subscriptions too, check that both IAP items are attached to the current submission and have complete metadata and review information. For the 5.1.2(i) fix, test on a fresh install that the ATT prompt appears before any tracking starts, and make sure the App Privacy answers match the SDKs and data flows in this build. In Review Notes, give the exact steps to reach the consent prompt and explain what happens if the user declines. If those checks are clear and App Store Connect shows no action needed, keep the current submission in the queue. Follow up once on the existing support case with this submission ID and build 24, asking whether anything is incomplete or if they need more information. I wouldn’t withdraw and resubmit just to try to move it along.

Because the earlier decision was under 4.3(a), I’d make the follow-up focus on what makes Done Spend a distinct product in the app itself, not only the different company, issuer, or country. Apple’s guideline addresses apps that share a similar binary, metadata, or concept, so describe the concrete differences in the user workflows, features, target customers, and content, and point the reviewer to those screens in the demo account. Since the current build is still Waiting for Review, keep it submitted and follow up in the existing App Review conversation or support case with the submission ID and build number. Ask whether they need any clarification about the revised demo credentials or the 4.3(a) response. I wouldn’t submit another build just to try to change the queue; if the app is rejected again, address the exact finding in one clear response or appeal.

Apple’s current App Review guidance doesn’t publish a typical turnaround time for App Review Board appeals. It says the Board will send a message in App Store Connect when its investigation is complete, and may contact you there if it needs more information. Sixteen days without a reply doesn’t tell you whether the appeal is still under review. If you want a status check, Apple specifically says not to use the appeal itself to request one. Use the appropriate Contact Us form and include the app name, appeal date, and existing case or appeal reference. I’d avoid filing a second appeal for the same rejection. Apple’s appeal instructions are here: https://developer.apple.com/help/app-review/after-submitting-for-review/appeal-to-the-app-review-board

For the next review, map each rejection point to a specific change in the App Review notes. Use screenshots from the current build and explain when the notification prompt appears and what still works if the user declines. For 3.1.1, explain what the POS subscription pays for and the actual signup and purchase flow. Removing pricing screens may not address the concern if the app still unlocks paid digital features or directs users elsewhere to buy. Describe the real business customer flow in the Resolution Center and ask which part remains unclear. Keep this submission active and follow up on the existing support case with the submission ID and build number.

I would not cancel and resubmit the identical build. You cannot see from App Store Connect whether it is in a separate queue, and creating another submission could just add another wait without fixing anything. Since the demo account and review notes are now verified, keep the current submission active and make sure those credentials remain available to the reviewer. For the existing support follow-up, include the submission ID and state exactly what changed after the 2.1 issue, including that the fixed-code login was tested against production. An expedited request is only a request, so it may not get a separate response. If App Review needs access or more information, they can contact you through the Resolution Center.

A pending termination notice is account-specific, so nobody on the public forum can identify the app or confirm whether the white-label arrangement caused it. I would keep the appeal and every follow-up in the same private Support case, and ask for confirmation that it is with the team handling the notice, whether they need any documents or explanation from you, and whether any action should be taken on the client’s app while the appeal is open. I would not transfer, remove, or make further changes to that app based only on guesses from the forum. Keep the agreement with the client and a clear timeline of who owned and operated the app available, and send those privately if Support requests them. If your existing case has gone unanswered, use Apple Developer Support’s official contact channel to ask for an escalation and reference the case number.

Since payment is complete and you have an Enrollment ID, this needs an account-specific check from Developer Support; the forum can’t see whether the payment is linked or what verification is pending. Reply to the existing support case with the Enrollment ID, payment date, and order number, and ask them to confirm the enrollment status and whether any action is required from you. Send the invoice only through Apple’s private support channel if they request it. I’d avoid posting the invoice or full payment details here, and avoid starting another enrollment while this one is being reviewed.

Since this was resubmitted on October 17, the current review queue starts from that resubmission. If the app is still marked Waiting for Review, there may not be anything else you can change in the build right now. Make sure the camera and photo permission explanations match what the app actually does, and that the account deletion flow is easy to find; keep the physical-device recording in the review notes in case the reviewer needs it again. You’ve already opened a support case, so I’d follow up there with the current submission ID and ask whether they need anything else from you. I wouldn’t withdraw and resubmit again just to try to move the queue, since that can reset the wait.

Since you have already withdrawn and resubmitted twice, I would leave the current submission in place. Check that each of the eight in-app purchases has its required metadata and review information completed, and that the app version and purchases are all ready for review. That does not mean the purchases are causing the delay, but it is worth ruling out anything incomplete in the submission. If everything is complete, follow up on your existing support case with the current submission ID, build 37, and the date the expedited request was granted. Ask whether the submission is still waiting in the queue or if there is an account or metadata issue you need to address. I would avoid opening duplicate cases or withdrawing it again while you wait.