Overview

My tvOS app includes the purchase of subscriptions, and I am updating the code with Storekit 2.0. I have seen other apps that present the "Confirm with Apple Device" UI upon selection of a product, but for me I only ever see an alert confirming the purchase. I have tested this using Xcode storekit data and a sandbox account. I have also attempted using Storekit views and passing the UIWindowScene to the purchase(confirmIn: ) parameter, but neither made any difference. Is there some limitation that prevents that UI from showing in debug builds?

I have been attempting to contact development support regarding verification of my organization in my signing ability on behalf of my organization because my account has not been. My initial filing was on May 5 for my new reference number because my first one got declined the developer portal as that it should only take two business days, but it is definitely taking a lot longer than that to verify my business. has anybody had this sort of issue before and is there a phone number to actually contact because the email process also seems to be delayed at this point in time. I work full-time and cannot receive phone calls during the day so putting in a ticket for someone to call me is not feasible. Hopefully somebody from the sports team will see this post and reach out to me and give me a way to contact Apple development support so I can get this finalized.

Currently our app Juris: Learn the Law has consumable IAPs available publicly. We've recently added a subscription to a new update, but since we already added consumable IAPs, we can only submit new IAP on their own and cannot attach it to a new binary. The issue is that when we submit the subscription for review, it gets rejected and the reviewers respond that the subscription needs to be included with a new binary, even though we can't attached it to a new binary. We submitted a new binary at the same time we submitted a new subscription, but the new binary would be approved and the subscription would be rejected. The update with the subscription is available, but the subscription isn't, meaning users cannot use the new features which require the subscription.

We are implementing starting an activity via Push-To-Start. For the most part it works great, however we have run into a few edge cases. Currently, we send the "start activity" push notification and it creates the Activity as expected. If the app doesn't send an update token w/in a configured time, we assume the activity didn't start and try to start the activity again. Occasionally we get into a situation where there have been multiple activities started, but it should really only be one. Here is my theory: We store an auth token in the keychain for all REST endpoints if the phone has been restarted and not unlocked, the app doesn't have access to the auth token and fails to send the update token to our backend. Are there any best practices on how to manage PTS and UPDATE tokens? (updating these w/o authentication seems problematic)

I've added two new users to our App Store connect account but when they follow the link in the invitation email, they're taken to a blank white page in their browser. I've had them try with an incognito browser and cleared their browsing data but have had no luck. We stopped trying for a few weeks and today, I sent a new invitation and they experienced the same issue. Can't seem to nail down why this is happening.

For many months now we've been building a watchOS app with push support. On device, these usually work fine, but in the sim, only loud pushes are ever received (don't contain content-available). This includes pushes triggered from our backend, whether directly or through Firebase Cloud Messaging, from Apple push web interface, from apns files dropped onto the sim, or from files sent using simctl push. All say they were sent successfully, none trigger any of the push related WKApplicationDelegate methods. As I understand it, only didReceiveRemoteNotification should be triggered for this kind of push. Additionally, can anyone confirm what the proper background mode setup is for push notifications on watchOS? Is it supposed to remote-notification under UIBackgroundModes or WKBackgroundModes? For WKBackgroundModes Xcode only offers a few watch specific values, but not the push value. The docs are unclear on this part.

Hello juice community. firts of all, i'm brazilian dev, soo this conversation will be a lot errors of english. but i'm think is a nice to prove is not a AI generate post here. hehe I want a big tip, how i integrate my app in the fruit ecosystem. Soo, i launch a AI prompt plataform, the idea is make users your own prompt, you make a context for him, like " you are a food master chief", and configure the inputs, like a photo of your freezer, to the AI take the ingredients e make a recipe with AI. The aplication is infinite! The integration, now, is with AI provider. the idea is not make a context with complex Skills.sh, but the common user create your own Prompt/AI and feel a prompt engineer master. i'm think the is a powerful plataform for native apple system. the plataform has url, and if any one has interesting a will chat in the comments the name for see how beaut is.

I'm adding live activities to my app and I'm trying to use push notifications to fully remotely start them and end them. The pushToStartTokenUpdates sequence gives start tokens exactly as expected, and triggers even when the app is fully terminated when a new live activity starts. However, the pushTokenUpdates sequence is far less predictable and seems to never trigger when the app is fully terminated. Even when the app is just backgrounded, it's still finicky. I send the "input-push-token": 1 as part of the aps payload too to begin the live activity, but that seems to have little to no effect. Is there any way to ensure that we can receive a push token specifically to update the live activity after it starts? It seems to me that if a live activity can be started via push even when the app is fully terminated, and live activities are meant to reflect active information, then the mechanism to update it via a new token should also be able to work when the app is terminated. Both sequences are subscribed to within the AppDelegate upon initial app launch. This is what my code looks like at the moment: func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { Task { for await newToken in Activity<WidgetAttributes>.pushToStartTokenUpdates { let tokenString = newToken.map{ String(format: "%02x", $0) }.joined() // send to server } } Task { for await activity in Activity<WidgetAttributes>.activityUpdates { Task { for await token in activity.pushTokenUpdates { let tokenString = token.map { String(format: "%02x", $0) }.joined() // send to server } } } } } } Thanks in advance for any insights!

Our application currently supports Live Activities. We’re working on adding a new Widget and are weighing some architectural decisions regarding whether we should add it to the same extension target that our Live Activity lives in or create a new extension that would expose it and other widgets we plan to create in the future. In the Add Support for Live Activities documentation, it suggests adding Live Activity code to the existing widget extension to facilitate code reuse. Beyond code sharing, we’re trying to determine if there are downsides to isolating new Widget(s) into their own extension. Specifically, we are concerned about process isolation and how a failure/crash in one might impact the other. Assuming they did live in the same extension, we’re hoping to better understand some of the finer details as presented by the following questions: If a Widget (e.g., via the TimelineProvider) causes the extension process to crash, what is the guaranteed behavior for a currently running Live Activity? Is the relaunch and restoration of a Live Activity after an extension crash guaranteed, or is it best-effort? Is there a distinction in crash isolation between a TimelineProvider failure and a View rendering crash? Are there any known scenarios where a Widget crash could cause a Live Activity to be permanently dropped? Does keeping them in the same extension affect the memory budget, or does each 'instance' receive its own allocation? In short: we're looking to ensure that an issue with a Widget doesn't inadvertently affect a Live Activity (or vice-versa) when they live in the same WidgetsBundle within the same extension and are seeking guidance on whether it makes sense to keep them together or continue down the path of separate extensions in the interest of process safety. Any pointers to other documentation or known behavior would be greatly appreciated!

Hey everyone, hoping someone here has seen this one because Apple support has basically gone silent on me at this point. Quick rundown of the situation: I submitted my app for review for the first time about 2 weeks ago, with my in app subscriptions attached to that first binary. That worked exactly like it's supposed to, subs and binary went into review together. The binary got rejected and the subs got rejected with it. Since then, every single time I create a new app version, the option to submit my subscriptions alongside it just isn't there. There's no "attach subscriptions" prompt anywhere in the new version's submission flow. So the only way I can actually submit the subs is on their own, straight from the Subscriptions page. And every time I do that, they come back rejected for one reason only, that they need to be submitted with a new app version. Which I literally cannot do, because that UI option doesn't appear in my ASC anymore. It worked the first time, and ever since that very first rejection it's just vanished from my account. What I've already tried: Multiple new builds over the past 2 weeks, each one addressing every bit of review feedback Bumping the version number a full major release (1.x to 2.0) incase ASC was caching something Leaving detailed review notes asking them to please review the subs alongside the current binary even though they aren't formally tied to it Including screen recordings in App Review Notes showing the option just isn't there on my end Submitting through the developer contact form, multiple times. Replying directly in Resolution Center on the rejection itself The usual stuff, refresh, clear cache, different browsers, Safari and Chrome. Same result everytime Honestly I'm fairly demoralised at this point. The hard part is that this is me costing real money for every day it drags on, users genuinely cannot upgrade to a paid plan because the subs aren't live, and as a 18 year old solo dev this aint easy. My actual question is, has anyone here run into this specific thing where the "attach subscriptions to a new version" option just disappears from ASC after the first rejection? Is there a known workaround, or a particular contact form topic that actually gets a human response within a reasonable timeframe? With all this being said I could be a complete idiot and theres something im missing and thats why its not working. If thats the case please just tell me im being stupid and that im missing something because i deserve it lowkey... I've even started thinking about deleting the subs and recreating them from scratch as a complete last resort, but that feels nuclear and I'd rather try anything else first. All help would be greatly appreciated thanks everyone 😄

Our app was approved for distribution yesterday, however our In-App Purchase subscription products have been in Waiting for Review status for several months, without the ability or option to manually connect to the app when submitting for review. As a result the App Store is incorrectly displaying our app as a $6.99 one-time purchase instead of Free with In-App Purchases. What can be done to connect the app to the subscriptions.

Hi everyone, I’m facing a very specific issue with our business location on Apple Maps. In the Apple Business Connect dashboard, our name is correctly set as "ANLOG Lojistik". It also appears correctly within the Apple Maps app itself. However, when we share the location via WhatsApp or iMessage, the "Preview Card" (Metadata) displays the name as "Anlog LojİStİK". It seems like a character rendering bug (specifically with Turkish character case sensitivity). Even standard characters like 'S' and 'K' are being forced into uppercase randomly. When you click the link, it opens correctly in Apple Maps, but the preview remains broken. Apple Support says "it's a 3rd party app issue," but this happens because the LPMetadataProvider fetches this specific data from Apple servers. Has anyone experienced a metadata sync/cache issue like this before? How can we force Apple to refresh the "Place Card" preview data?

Hi everyone, I’d appreciate guidance on a 2.5.2 rejection. My app was rejected with this message: “During review, the app installed or launched executable code. Specifically, the app allows users to install apps created by other users.” What my app actually does: Users create/share tool templates (not binaries/plugins). A template contains only: form configuration (text fields, dropdowns, checkboxes, sliders, etc.) At runtime, placeholders like #TextField are replaced with user input, then the final prompt is sent to a server for AI response. *The iOS app does not download/install/execute native code, scripts, frameworks, or dynamic modules on-device. I suspect review interpreted the word “install” in my UI as real app/code installation anyone knows what can i do to fix this problem. thank you,

We are experiencing an issue with a few end users where the UIAlertController's UIView is rendered with a (for the lack of a better word) "shattered" effect (see attachments). It appears to be happening only occasionally which makes me think it's a bug with iOS 26 and/or hardware issue. I'm posting here hoping to get some type of guidance on a workaround or if this is already a known issue (I have not been able to find instances of this particular issue online). Has anyone experienced or seen others experience this issue? Does anyone know of a workaround or can confirm this is a bug with iOS 26? Thanks in advance.

Hello, I am seeking guidance or an internal escalation regarding our app (App ID: 6480077134), which has been in the "In Review" status for over 30 days. Despite several attempts to resolve this through standard channels, we have not received a status update or a response to our latest correspondence. We have already: Requested a phone callback (Result: "We'll email the review team," but no follow-up). Submitted a formal Expedited Review request 14 days ago with no response. Attempted to contact the review team via email over a week ago (exceeding the 72hr response window). Our last correspondence addressed feedback regarding Guidelines 2.3.2 and 2.1(a) as follows: Guideline 2.3.2 – Promotional Images & Price References Removed all promotional images from IAP products. Removed price references from display names (e.g., changed "90 Day Free Trial" to "90 Day Trial"). Guideline 2.1(a) – App Completeness (Conversations) Provided clear reproduction steps for the "Conversations" feature, clarifying its contextual design. This version is an update to an existing app already on the Store, and this delay is now significantly impacting our business. We are concerned the submission may be stuck in a technical queue or an un-notified account hold. Any assistance or visibility from Apple staff or the community would be greatly appreciated.

Hello, My app "Glow Mode: AI Skin Scanner" (Apple ID: 6762376419) has been blocked from distribution in all 27 European Union countries for 49+ days due to Digital Services Act trader verification stuck in "In Review" state. Current state in App Store Connect: • Business → Compliance → Digital Services Act: "In Review" since 24 March 2026 • Pricing and Availability → Manage Availability: all 27 EU countries show "Trader Status Not Provided" → "Cannot Sell" • App-level: declared as "trader app" ✓ • Account: published in 148 other countries, all agreements / banking / tax forms verified and Active Apple's stated typical review time is 5 business days. I'm at day 49. Several other developers have reported identical issues in recent threads: • https://developer.apple.com/forums/thread/822744 — DSA Review stuck • https://developer.apple.com/forums/thread/822857 — App not available in EU • https://developer.apple.com/forums/thread/818244 — Review stuck 2+ months I've also filed a support case (ID: 20000114608599) but wanted public visibility in case this is a systemic issue affecting multiple developers. Questions for Apple staff and the community: Has anyone resolved a DSA verification stuck this long? If so, how? Is there a backend status that may already show "approved" while the UI continues to show "In Review"? What is the recommended escalation path beyond the standard support form? Thanks in advance for any insight.

Hi, I’m looking for clarification on Apple Pay merchant domain verification behavior. Our production domain’s verification expiry was extended without any action from our team. Previous expiry: May 21, 2026 Current expiry: October 6, 2026 The Verify button is greyed out, and we can’t download a new .txt file. We did not re‑verify the domain during this time. A few weeks prior, we did renew our Apple Pay Merchant Identity certificate for Apple Pay on the web. Could someone clarify: Does updating the Merchant Identity certificate trigger automatic domain revalidation or expiry extension? If so, why was the extension only 4 months? Does Apple automatically revalidate or extend merchant domain verification? Is this expected behavior, or should domains always be manually re‑verified?

I don’t know what is going on. However I am getting strange app updates. APIs Thank you

I have Family Controls (Distribution) and (Development) on my main app. The shield overlay, shield actions, and ManagedSettingsStore all work correctly. My app concept: the user selects a specific time (e.g. 7:00 AM) at which their selected apps (Instagram, TikTok, Snapchat, etc.) should be blocked until they complete an action. The blocking should happen everyday automatically at the chosen time without the user needing to open my app. What actually happens: at 7:00 AM nothing happens. The selected apps remain accessible. The blocking only activates when the user manually opens my app and then closes it. Has anyone found a reliable way to make intervalDidStart fire every day at the scheduled time in the background? Is there a known workaround? I have seen similar reports from other developers but no confirmed solution. Any guidance from Apple engineers would be greatly appreciated.

We are integrating the App Intents framework into our iOS app to enable Siri functionality, including intents that display user data (e.g., showing upcoming schedule information) and intents that perform actions on behalf of users (e.g., submitting a time-off request). Our Legal team has asked us to provide any developer-specific integration terms or agreements that govern the engineering use of Siri and the App Intents framework — separate from the user-facing Siri, Dictation & Privacy terms. So far, the only reference we've found to App Intents or Siri in Apple's developer agreements is Section J of the Apple Developer Program License Agreement. We've also reviewed the App Store Review Guidelines, the Privacy HIG, and the Siri HIG. As a point of comparison, Apple Maps has its own specific set of developer integration terms (MapKit / Apple Maps Server API terms). Does anything equivalent exist for Siri and/or the App Intents framework? If Section J of the License Agreement and the relevant HIG sections are the complete set of terms governing developer use of App Intents and Siri, confirmation of that would also be very helpful. Thank you.