Overview

Hi Apple Developer Support / Community, My Apple Developer Program enrollment is stuck due to identity verification. Country/region: Australia (I’m currently in Australia) Passport: non-local passport (Japanese) The Apple Developer app rejects non-local passport uploads automatically, so Apple Support instructed me to upload documents via a special upload link. Phone support confirmed the documents were received, but there has been no progress for over 2 weeks. I also submitted the Apple Developer Program Support contact form, but have not received any reply. Case ID: 102795934998 I understand the community can’t access my account details. I’m posting to ask: Is there any way to get this routed to the Identity Verification / Enrollment Operations queue? What exact next step should I request from support to unblock enrollment? Has anyone experienced a similar “special upload link” process and long delays? I need this resolved to publish my iOS app. Any guidance or escalation path would be appreciated. Thank you.

Hello everyone. We have an app that has been on the App Store for several years, originally distributed for iOS and iPadOS only. Recently, we enabled Mac (Designed for iPad) and started distributing macOS-compatible builds. Current situation: The app is available and downloadable from the macOS App Store and runs correctly on Apple Silicon Macs. The same app/build appears in TestFlight on macOS, but cannot be installed. TestFlight shows the message: “This app can only be tested on an iOS device.” This suggests the app itself is Mac-compatible, but TestFlight is treating the build as iOS-only. Environment and checks performed: Mac is Apple Silicon. App Store Connect app-level availability for Mac (Designed for iPad) is enabled. The app is not Mac Catalyst; it is a UIKit iOS/iPadOS app. Distribution is done via GitLab CI. CI uploads use an App Store provisioning profile (Apple Distribution), not development or ad-hoc. iPhone and iPad TestFlight installs work as expected. Info.plist verification: UIRequiredDeviceCapabilities was originally present (armv7) and has since been: removed entirely, build number incremented, new builds uploaded to TestFlight. No other hardware capability requirements are declared. LSRequiresIPhoneOS = true remains unchanged. No other plist keys that should exclude macOS are present. CI / build considerations: The same uploaded build is accepted by App Store Connect and distributed successfully on the macOS App Store. This tells us the binary itself is valid for macOS, but TestFlight applies additional or different eligibility checks. At the moment we think that TestFlight eligibility may depend on build metadata, scheme/configuration flags, or internal App Store Connect state that differs from App Store distribution. Questions: Are there known cases where a build is valid for macOS App Store distribution but not eligible for macOS TestFlight installation? Does anyone know if TestFlight applies stricter or different platform gating than the App Store for “Mac (Designed for iPad)” apps? Are there specific build settings (e.g. SUPPORTS_MAC_DESIGNED_FOR_IPAD, TARGETED_DEVICE_FAMILY, scheme/config mismatches) that can affect TestFlight macOS eligibility independently of App Store eligibility? Is there an authoritative way in App Store Connect to inspect why a specific TestFlight build is marked as “iOS-only” for macOS? Any insight into TestFlight-specific eligibility rules for “Mac (Designed for iPad)” would be appreciated, especially given that App Store distribution for macOS is already working. I hope we're missing something very basic, and not that the app can't be tested as is for the mac, because it's useful to have our QA team test it on the mac.

Hello Apple Forums, We are developing an iOS application that connects to a custom BLE accessory and sends control commands to it. Our system architecture is as follows: A separate hardware device collects data and sends it to our backend server via Wi-Fi. The backend evaluates state changes and determines when the BLE accessory should update its display. The iOS app acts purely as a BLE command executor for this accessory. Our goal is to: Maintain a BLE connection with the accessory while the app is in the background. Receive state-change events from our backend server. Upon receiving such events, send a BLE command to the accessory to update its state. We understand that iOS does not allow arbitrary background execution. We would like to confirm whether there is any supported mechanism, entitlement, or program that allows: Long-running background execution for BLE control, or Server-originated events (other than APNs) to trigger background BLE actions. If this is not supported, we would appreciate confirmation that APNs (silent push) is the only supported way to trigger such background BLE actions, or guidance on any recommended alternative architectures. Thank you for your guidance.

My Enrolment Program has been pending for nine days now. I submitted the requested documents and received the following message: "Thank you for providing the documents we requested. We will review them and follow up with you within two business days." It's been 5 days now, and I still haven't received a response. I've emailed support three times and haven't received a response either. I haven't received any information that anything is wrong or that I need to send anything else. Zero contact. What's going on? I have to admit, I haven't felt treated as poorly by any company as I am now by Apple.

Hello , I recently uploaded an app and would like testflight , ı sent 2 friends of mine invitation however none of them got it ( prior that added them as user) one of them use icloud.com the other uses mail.ru. Does anyone face such problem and how to solve it? Its been almost 5 hours, I retry the process by deleting them then add later on again.

I can't find the full content of the SwiftUI inspector in the latest version of Xcode. I've opened the preview canvas but it still won't display.

Hello, I have an app approved and available on the app store, which one IAP approved and available on the app store. I want to update the app, and I followed the instructions which are to click on the "+" and chose a new version number. I did that, but I have an issue. When selecting the build (which was tested on testflight), I cannot select the in-app purchase that was already on the last version and already approved. Also, i'm wondering, why is it mandatory to put new screenshots of the app for a new version, is there a way to pick the screenshots of the last version ? Thank you !

As stated in the title, I'm a Russian citizen located outside of Russia and Belarus. I am trying to enroll into the program as a US LLC that has EIN. I am the only owner and employee of it. Today has been exactly 1 month of me going back and forth with Apple Support. I provided all of the requested information, including company ownership verification, as well as have been verified that I'm not on the sanctions list. For the past two weeks, I have not received any reply from the support. I know that access to the program is heavily restricted for Russian citizens, but I have not seen any mention that I cannot enroll even if I'm applying as a US LLC registered with the IRS. I also did not get any mention from the support that my citizenship is a problem. I am not sure what to do next. Any advice is appreciated.

We're a premium paid app - currently listed in Maps & Navigation as our primary category, with Travel set as secondary. We’ve been in Maps & Navigation for ~9 years and consistently rank in the top 5. However, aside from one other app that regularly shares that top-5 position with us, most apps in this category don’t appear relevant to our product or audience. They also don’t seem to reach the same type of user we’re targeting. By contrast, the Travel category contains a much higher concentration of apps that serve the same type of user as ours, and feels like a more natural discovery fit. What’s unclear to us is: Why a secondary category exists if the app does not appear to surface in that category for browsing/discovery. The implications of swapping our primary and secondary categories. Specifically, if we reverse Category 1 and Category 2: Do we retain our existing ratings and review history? Are there any penalties or long-term impacts beyond potential short-term ranking changes? We’re comfortable with an initial ranking reset if that’s expected, but after 9 years in market, we want to be certain there’s no loss of accumulated reviews or other irreversible downsides before making the change. Any clarification from those with experience would be appreciated.e for an "experiment".

Background / Objective We are currently developing a solution to centrally manage Apple OS updates (major and minor) across managed macOS devices. Before implementing at scale, we need Apple’s guidance on supported and future-proof update mechanisms under MDM. Questions / Ask (Apple Guidance Requested) Apple recommended method What is Apple’s recommended approach to perform: Minor updates (e.g., macOS X.Y → X.Z) Major upgrades (e.g., Ventura → Sonoma) in an enterprise fleet? Support boundary Is macOS update management only supported via MDM (including any newer declarative workflows), or are local mechanisms (installer + command-line tooling) also considered supported for enterprise automation? Use of startosinstall Can we leverage the existing utility: /Applications/Install macOS .app/Contents/Resources/startosinstall for automated upgrades in enterprise environments? If yes, are there recommended flags/workflows Apple endorses for unattended or minimally interactive upgrades? Long-term support / stability Does startosinstall have any form of long-term support / stability guarantees across future macOS releases? Are there any known deprecations planned (or guidance that customers should transition to MDM/DDM workflows)? MDM interaction / interference When using startosinstall, can MDM policies (software update deferrals/restrictions, update enforcement, etc.) interfere with or block the upgrade? If interference is expected, what is the correct supported way to coordinate: MDM software update settings local startosinstall execution to avoid failures and ensure compliance? What We Need From Apple (Desired Outcome) A clear statement of recommended and supported update workflow(s) for enterprise managed macOS: for minor updates for major upgrades Guidance on whether startosinstall is acceptable for long-term automation, or whether we should only use MDM/DDM-driven workflows. Any best practices or reference documentation Apple recommends for implementing this safely and reliably.

Hello, I experienced an issue when trying to upload the app to App Store Connect. It rejects the upload every time. I’ve already accepted the required agreements on the Apple Developer website. I also tried uploading the app via Xcode, but I’m getting the following error: “The operation couldn’t be completed. (DVTAppStoreConnect.ServiceBackendError error 1.)” Has anyone run into this issue before and managed to fix it? I tried contacting support about it, but I haven’t received any response.

I’m hoping to get some insight from Apple engineers or developers who have seen similar behavior. Background We previously had a React Native / Expo iOS app in production for several years. Recently, we rebuilt the app completely from scratch as a native SwiftUI app using WKWebView (no shared code, no RN runtime). The new app architecture is: Native SwiftUI container WKWebView loading a remote web app Firebase Analytics & Crashlytics Push notifications (APNs + FCM) No local database, no persistent native state Migration scenario Users update the app via the App Store: Old app: React Native / Expo New app: native SwiftUI + WKWebView For most users, the migration works fine. However, for a about 10% of users, the following happens: The issue After updating from the old React Native app to the new SwiftUI app: The app opens The native landing screen appears (solid black OR blue background, depending on which most recent version if being installed) The app never transitions to the WKWebView No crash Force-quitting does not help Deleting the app completely and reinstalling does fix it 9/10 times, but NOT ALWAYS. From the user’s perspective: “The app is stuck on a black OR blue screen forever.” Important detail Most of the times, a full uninstall + reinstall FIXES the issue, but funny enough, NOT always.. In some cases, the issue persists: What we’ve already tried Over the last weeks, multiple iOS developers have investigated this. We have implemented and/or tested: Full rebuild in SwiftUI (no RN remnants) Aggressive cleanup on first launch after update: -- UserDefaults cleanup -- WKWebsiteDataStore cleanup -- URLCache / cookies cleanup Timeouts and fallbacks so the UI never blocks indefinitely Explicit logging of: -- app_open -- session_start -- webview_init -- webview_load_start / finish -- blank screen detection Handling: -- WKWebView content process terminated -- network / TLS / DNS errors Added a native SwiftUI landing screen (in the latest version) so users no longer see a black screen, but now they see a BLUE screen when the transition fails Observations from Analytics & Crashlytics No native crashes Very high user engagement (~99%) Very low blank-screen detection (~1–2%) The issue does not appear to be mass-scale But support still receives complaints daily from affected users This suggests a device / iOS / network-specific edge case, not a general migration failure. Hypotheses (not confirmed) We suspect one of the following, but haven’t been able to prove it: WKWebView failing to initialize under specific conditions after App Store updates TLS / ATS / CDN edge behavior affecting first WKWebView load iOS lifecycle timing issue when transitioning from SwiftUI landing view to WKWebView OS-specific WebKit state that survives reinstall (keychain? system WebKit state?) ISP / DNS / IPv6-related issues on first launch What we’re looking for We would really appreciate insight on: Are there known cases where WKWebView fails silently after an App Store update, even after reinstall? Is there any system-level WebKit state that survives app deletion? Are there best practices for transitioning from a SwiftUI landing view to WKWebView to avoid dead-ends? Any known iOS versions / device classes where this behavior is more common? Any debugging techniques beyond Crashlytics / Analytics that could surface what WebKit is failing on? We’re not looking for generic “clear cache” advice — we’ve already gone far down that path. We’re trying to understand whether this is a known WebKit edge case or something we are fundamentally missing. Thanks in advance for any pointers or shared experiences.

Description I'm developing a custom keyboard extension using UIInputViewController and need to set a specific height of 268 points. The keyboard functions correctly, but there's a visible flicker and resize animation during launch that I cannot eliminate. The Problem When the keyboard launches, iOS provides incorrect heights before settling on the correct one. At launch, the view starts at 0×0. Around 295ms later, iOS sets the frame to 440×956 which is full screen height and wrong. Around 373ms, iOS changes it to 440×452 which is still wrong. Finally around 390ms, iOS settles at 440×268 which matches our constraint. This causes visible flicker as the view resizes three times rapidly. The keyboard appears to shrink from full screen down to the correct height, and users can clearly see this animation happening. What I've Tried I've tried adding a height constraint on self.view which gives me the correct height but causes the visible flicker. I created a custom UIInputView subclass and overrode intrinsicContentSize to return my desired height. iOS completely ignores this and gives random heights like 471pt, 680pt, or 956pt instead. I set allowsSelfSizing to true on my UIInputView subclass. iOS ignores this property. I set preferredContentSize on the view controller. iOS ignores this as well. I tried adding the constraint in viewDidAppear instead of viewDidLoad, thinking iOS might have settled by then. It still causes flicker. I overrode the frame and bounds setters on my UIInputView to clamp the height to my desired value. iOS bypasses these overrides somehow. I overrode layoutSubviews to force the correct height after the super call. iOS still applies its own height. Specific Question What is the correct API or technique to specify a keyboard extension's height that iOS will respect immediately upon launch, without triggering the resize animation sequence? Other third-party keyboards like Grammarly and SwiftKey appear to have solved this problem. Their keyboards appear at the correct height without any visible flicker. How do they achieve this? Expected Outcome The keyboard should appear at 268pt height on the first frame with no visible resize animation. Steps to Reproduce Create a new iOS App project in Xcode and add a Keyboard Extension target. In KeyboardViewController.swift, add a height constraint in viewDidLoad: override func viewDidLoad() { super.viewDidLoad() let heightConstraint = view.heightAnchor.constraint(equalToConstant: 268) heightConstraint.priority = .defaultHigh heightConstraint.isActive = true let label = UILabel() label.text = "Demo Keyboard" label.textAlignment = .center label.translatesAutoresizingMaskIntoConstraints = false view.addSubview(label) NSLayoutConstraint.activate([ label.centerXAnchor.constraint(equalTo: view.centerXAnchor), label.centerYAnchor.constraint(equalTo: view.centerYAnchor) ]) } Build and run on a physical device. Enable the keyboard in Settings, then General, then Keyboard, then Keyboards. Open any app with a text field and switch to the custom keyboard using the globe button. Observe the height changing from around 956pt to 452pt to 268pt with visible animation. Environment iOS 17 and iOS 18 and 26.2, Xcode 16 and Xcode 26, affects all iPhone models tested, reproducible on both simulator and physical device.

Hello everyone, I’m currently working with the Message Filtering Extension and would really appreciate some clarification around its performance and operational constraints. While the extension is extremely powerful and useful, I’ve found that some important details are either unclear or not well covered in the available documentation. There are two main areas I’m trying to understand better: Machine learning model constraints within the extension In our case, we already have an existing ML model that classifies messages (and are not dependant on Apple's built-in models). We’re evaluating whether and how it can be used inside the extension. Specifically, I’m trying to understand: Are there documented limits on the size of an ML model (e.g., maximum bundle size or model file size in MB)? What are the memory constraints for a model once loaded into memory by the extension? Under what conditions would the system terminate or “kick out” the extension due to memory or performance pressure? Message processing timeouts and execution constraints What is the timeout for processing a single received message? At what point will the OS stop waiting for the extension’s response and allow the message by default (for example, if the extension does not respond in time)? Any guidance, official references, or practical experience from Apple engineers or other developers would be greatly appreciated. Thanks in advance for your help,

Dear Apple, The Apple Developer website and App Store Connect currently remain locked in light mode, which can cause significant eye strain during extended development sessions. It would be greatly appreciated if dark mode — or an automatic system-based appearance option — could be added to make these platforms more eye-friendly for developers. Thank you for considering this improvement.

We operate a native iOS app that authenticates users via the system browser using OIDC against a 3rd party SaaS authentication broker, which then performs authentication against the individual customer IdPs using SAML within the browser session, and then completes the OIDC login between the broker and our application. Our application initiates the OIDC login using ASWebAuthenticationSession, using the broker’s library, against the broker, and at that point the authentication workflow is handled by the broker. At the beginning of the login session, the broker sets a session-identifying cookie for their domain, before redirecting the user to their company’s identity provider to authenticate, which then redirects the user back to the broker. Intermittently, Mobile Safari does not include that previously set cookie on the final communication with the broker, when being redirected from the IdP as the final step of the SAML portion of the login workflow. When the cookie is missing, the broker cannot correlate the authentication response to the original request and the login fails, even though the user successfully authenticated at their identity provider. The same user can sometimes find success after retrying on the same device minutes later, without any changes. When we first started diagnosing this issue, we were seeing about a 20% rate of these errors across all Mobile Safari logins, which we can identify fairly conclusively (from provider logs, based on their guidance) as being caused by the session cookie set in one request not being provided on the subsequent request to the same domain. Our authentication broker provider has indicated, based on their server logs, and logs from an affected device, that this behavior is caused by Mobile Safari’s Intelligent Tracking Protection (ITP) causing Mobile Safari to not send the login session cookie to the broker when handling the SAML redirect from the IdP back to them. Our authentication broker provider recommended that we switch the SAML Request binding setting from POST to Redirect in the SAML configurations against our customer IdPs, which reduced the rate of these errors to about 5% for most of our customers. However, we have at least one customer which is still seeing about a 20% rate in these errors for Mobile Safari logins after this change, and even a 5% error rate seems high. Our authentication broker has not been able to suggest any further remediation options, and has suggested we contact Apple for assistance. Our questions are: Is it reasonable to assume that ITP is causing this issue? Is there any way to confirm, conclusively, that ITP has caused a previously-set cookie to not be provided on a subsequent request to the same domain, i.e. via device logs? If so, are there any steps which can be taken to reduce or eliminate this error? Changes to how ASWebAuthenticationSession is invoked? Changes to the Authentication Broker which would reduce the chance of ITP being triggered? Changes to the Customer IdP configuration which would reduce the chance of ITP being triggered?

I’m trying to test a crossgrade on a subscription plan that has the same duration and price. When running tests with renewal intervals shorter than one hour, and managing or modifying the subscription, I see a payment confirmation message that says “You’ll pay X euros today.” This message is confusing because it sounds like an immediate charge, whereas my understanding is that the payment actually occurs at the next renewal, which in the test environment happens “today” due to the accelerated renewal frequency (1 hour or less). To make sure this works as expected, according to the official documentation, when testing in TestFlight the renewal frequency is 1 day. Therefore, when managing and modifying the subscription to perform the crossgrade, I would expect the UI to indicate that the payment will occur tomorrow. However, when I manage the subscription from the device’s Developer section, it indicates that the subscription will renew today, and as a result, during the crossgrade flow it again shows that I will pay X euros today. Is there any way to properly test this scenario? Or should I assume that in production the crossgrade behavior will match the documented explanation?

Environment macOS 15.7.3 Xcode 26.1.1 / 26.2 iOS 18.5 / 26.2 iPhone 16 Pro Simulator and physical device Problem Description When tapping an unselected UISegmentedControl, the selected segment does not match the tapped position. Specifically, tapping the rightmost segment (index: 3) results in the leftmost segment (index: 0) being selected instead. Conditions for Reproduction This issue occurs when all of the following conditions are met: Built with Xcode 26.x UIDesignRequiresCompatibility is set to YES in Info.plist UISegmentedControl is positioned using Auto Layout with leading alignment Segments are added dynamically using insertSegment(withTitle:at:animated:) Note: The issue does not occur when segments are defined statically in Storyboard. Steps to Reproduce Create a subclass of UISegmentedControl that dynamically sets segments: class CustomSegmentedControl: UISegmentedControl { func setSegments(titles: [String]) { removeAllSegments() titles.forEach { title in insertSegment(withTitle: title, at: numberOfSegments, animated: false) } } } In the ViewController, configure the control: override func viewDidLoad() { super.viewDidLoad() segmentedControl.setSegments(titles: ["Item A", "Item B", "Item C", "Item D"]) segmentedControl.selectedSegmentIndex = UISegmentedControl.noSegment } Set UIDesignRequiresCompatibility to YES in Info.plist: <key>UIDesignRequiresCompatibility</key> <true/> Run the app and tap the rightmost segment ("Item D") Expected vs Actual Behavior Expected Actual Tap rightmost segment "Item D" (index: 3) is selected "Item A" (index: 0) is selected What I Tried (Did Not Work) Calling layoutIfNeeded() after adding segments: segmentedControl.setSegments(titles: ["Item A", "Item B", "Item C", "Item D"]) segmentedControl.layoutIfNeeded() // No effect Workarounds Set UIDesignRequiresCompatibility to NO (enables Liquid Glass design) Define segments statically in Storyboard instead of dynamically Sample Project Minimal reproduction project is available here: https://github.com/CH3COOH/Samples/tree/master/SampleSelectSegmentedControl Feedback Assistant This issue has been reported via Feedback Assistant: FB21712773 Has anyone else encountered this issue or found alternative workarounds?

Apple notification description: notificationType： The type that describes the In-App Purchase or external purchase event for which the App Store sends the version 2 notification. App Store Server Notifications 2.0+ string notificationType Possible Values CONSUMPTION_REQUEST A notification type that indicates that the customer initiated a refund request for a consumable In-App Purchase or auto-renewable subscription, and the App Store is requesting that you provide consumption data. For more information, see Send Consumption Information. When the developer receives the refund request notification and sends the refundPreference, they say: GRANT_PRORATED You prefer that the App Store grants a prorated refund. Discussion Use these values in the refundPreference field of a ConsumptionRequest. The following constraints apply to the GRANT_PRORATED option: If the product is a consumable or non-consumable In-App Purchase or a non-renewing subscription, you may include a consumptionPercentage value in the ConsumptionRequest. Question: Requesting a refund for a non-consumable type does not send a notification to the developer. However, when a developer sends a refund preference, they can still send a GRANT_PRORATED request for a non-consumable type.

Hi DTS / Apple engineers, We’re attempting to extending our screen time app target to Mac Catalyst. On iOS, FamilyControls works as expected (AuthorizationCenter + FamilyActivityPicker, then ManagedSettings shields + DeviceActivity monitoring/reporting). On Mac Catalyst: The project builds with FamilyControls/DeviceActivity/ManagedSettings capabilities enabled. But attempting to request FamilyControls authorization (or present FamilyActivityPicker) fails at runtime. We see errors similar to: Failed to get service proxy: The connection to service named com.apple.FamilyControlsAgent was invalidated: failed at lookup with error 159 - Sandbox restriction. And our app stays authorizationStatus == .notDetermined, with the request failing. We saw an Apple engineer suggestion to “disable App Sandbox”, but Mac Catalyst apps appear to always be sandboxed, so we can’t disable it. Questions: Is FamilyControls authorization supported on Mac Catalyst today? If so, what entitlement/capability is required specifically for Catalyst/macOS? If FamilyControls auth cannot succeed on Catalyst, does that mean ManagedSettings shields and DeviceActivity monitoring/reporting are effectively unusable on Catalyst (since they depend on that authorization)? Is there an Apple‑recommended approach for a Catalyst “portal” app that mirrors an iOS child device’s restrictions, or is local enforcement on Catalyst intentionally unsupported? Any guidance (and any official docs that clarify current platform support) would be hugely appreciated.