Overview

Hello Apple Developer Community, I submitted my PDF app for review on October 5, 2026, and as of October 14, it is still showing “Waiting for Review.” This is the first submission of my app. I have already sent two emails to App Review Support asking for an update, but unfortunately, I have not received any response. I understand that App Review times may vary, but waiting for nine days without any update is concerning, especially for a new app launch. Could anyone from the community share their recent experience with App Review delays? How long did your app stay in “Waiting for Review” recently? Is anyone else experiencing similar delays? Is there any recommended way to contact Apple and get an update on a pending submission? I would really appreciate any advice or suggestions. Thank you.

I own a U.S. single-member LLC that's a disregarded entity. In App Store Connect, Line 1 of the W-9 is locked to the LLC name, but the IRS instructions say the owner's name goes on Line 1 and the LLC on Line 2. This is blocking my Paid Apps Agreement. I contacted Finance Support around 9-23-26 with a screenshot and video of the issue, but haven't heard back. I followed up a week ago. Still no response. Has anyone with a single-member LLC gotten this fixed recently? Apple developer support says their financial team is the only team that can handle this issue. Nearly one month to fix some basic text is ridiculous. I could have handles this myself if the Line 1 box wasn't greyed out.

~5% of our users when downloading the iOS application from the Apple Store for the first time are unable to enrol a Passkey and experience an error saying the application is not associated with [DOMAIN]. The error message thrown by the iOS credentials API is "The operation couldn't be completed. Application with identifier [APPID] is not associated with domain [DOMAIN]" We have raised this via the developer support portal with case id: 102315543678 Question: Why does the AASA file fail to fetch on app install and is there anything that can be done to force the app to fetch the file? Can this bug be looked at urgently as it is impacting security critical functionality? Other Debugging Observations We have confirmed that our AASA file is correctly formatted and hosted on the Apple CDN. Under normal circumstances the association is created on install and Passkey enrolment works as intended. We have observed that when customers uninstall/reinstall the app this often, but not always, resolves the issue. We also know this issue can resolve itself overtime without any intervention. We have ruled out network (e.g VPN) issues and have reproduced the issue across a number of different network configurations. We have ruled out the Keychain provider and have reproduced it across a variety of different providers and combinations of. We observed this across multiple versions of the iOS operating system and iPhone hardware including the latest hardware and iOS version.

If a username field has .autocorrectionDisabled() or .textInputAutocapitalization(.never), tapping the saved login above the keyboard stops working once the user has typed part of their email. Nothing gets filled in. Seen on iPhone 16, iOS 27.0 (24A437). I've also reported this to Apple through Feedback Assistant (FB24825410). Steps to reproduce You need an app with Password AutoFill set up (a webcredentials associated domain) and a saved login for that domain. Tap the email field. The saved login appears above the keyboard. Type a few letters of the email. Tap the saved login. Expected: the email and password fields fill in, replacing what was typed. Actual: nothing happens. What works A username field with only .textContentType(.username) and .keyboardType(.emailAddress). Tapping the saved login fills both fields, no matter how much the user has typed. What breaks With .autocorrectionDisabled(), the tap works after 1 typed character, but does nothing after 2 or more. With .textInputAutocapitalization(.never), the tap does nothing after even 1 typed character. UIKit has the same problem: a UITextField with autocorrectionType = .no behaves like .autocorrectionDisabled(). In all of these cases, choosing the login from the key icon's Passwords sheet still fills both fields. Only the tap on the suggestion above the keyboard fails. Sample struct LoginView: View { @State private var email = "" @State private var password = "" var body: some View { VStack { TextField("Email", text: $email) .textContentType(.username) .keyboardType(.emailAddress) // Either of these breaks AutoFill once the user types: .autocorrectionDisabled() // fails after 2+ typed characters .textInputAutocapitalization(.never) // fails after 1 typed character SecureField("Password", text: $password) .textContentType(.password) } } } Workaround I removed both modifiers from our username field and it works. Typed emails still didn't get autocorrected in my testing. Has anyone found a way to keep these modifiers on a username field without breaking AutoFill? Possibly related: https://developer.apple.com/forums/thread/702970

Hello, I am developing a native macOS utility using SwiftUI and AppKit, and I am investigating whether its power scheduling features can be implemented in a sandboxed app distributed through the Mac App Store. The intended functionality is: Schedule power-on from a fully shut-down state, not just wake from sleep. Schedule wake from sleep and shutdown. Let the user select weekdays and times, and modify or cancel the schedule. Keep the schedule effective after the user quits the app. For example, the user could explicitly configure power-on at 08:00 and shutdown at 22:00, Monday through Friday. My local prototype uses pmset with administrator authorization. For a possible Mac App Store version, I am looking for a supported implementation that does not execute privileged shell commands or run an application helper as root. What I have checked The documentation for IOPMSchedulePowerEvent states that it must be called as root. Calling that API directly therefore does not appear to remove the privilege requirement. App Review Guideline 2.4.5 requires sandboxing and prohibits requesting escalation to root privileges. I also reviewed launchd scheduling and user-supplied scripts through NSUserAppleScriptTask, but neither appears to provide a self-contained solution for scheduling power-on from shutdown without privileged operations. Questions Is there a public API or system-mediated authorization mechanism that supports this functionality from a sandboxed third-party app? Is there a requestable entitlement specifically applicable to power-event scheduling? If the complete feature set is unsupported, which operations are available within App Sandbox: power-on from shutdown, wake from sleep, and scheduled shutdown? The current deployment target is macOS 13 or later, on Apple silicon and Intel. If a supported solution requires a newer macOS version or specific hardware, that information would also be helpful. I am asking about supported API capabilities and architecture, rather than advance App Review approval. A documentation reference—or confirmation that scheduled power-on from shutdown is unavailable under these constraints—would help me choose the appropriate distribution model. Thank you.

Case ID: 102996013304 The order originally indicated that processing could take up to 48 hours, but it has now been days. We have contacted Apple Developer Support and have open support cases, but I have not received any responses yet. Any guidance would be greatly appreciated.

The problem On iOS 27, UIPrintInteractionController.print(to:completionHandler:) works on its first call in a process. Every subsequent call is accepted (print(to:) returns true and printInteractionControllerWillStartJob fires), but the completion handler is never invoked: nothing prints, didFinishJob never fires, no error is produced, and no job appears in Print Center. I expected each call to submit an independent job and invoke its completion handler, as it does on iOS 26 and earlier with the identical binary. Steps to reproduce Build an app that prints without the print panel, using a retained UIPrinter from UIPrinterPickerController. Submit a job: let controller = UIPrintInteractionController.shared let info = UIPrintInfo(dictionary: nil) info.outputType = .general info.jobName = "job-\(n)" controller.printInfo = info controller.printingItem = pdfData // valid PDF, canPrint(data) == true controller.delegate = self let started = controller.print(to: savedPrinter) { _, completed, error in print("completion", completed, String(describing: error)) } print("started", started) First job: started == true, both willStartJob and didFinishJob fire, the completion handler runs with completed == true, and the page prints. Submit a second job the same way, same process. started == true and willStartJob fires with printInfo.printerID populated and printPaper negotiated to the same values as the successful job. Then nothing. No didFinishJob, no completion handler, no error, no page, nothing in Print Center. A third job: print(to:) returns false synchronously, since the shared controller still considers job two in flight. System information iPad, iPadOS 27.0 developer beta 6 Built against iOS 26.2 SDK (Xcode 26.2). Same binary works on iOS 26. Reproduced on two unrelated printers: Brother QL-820NWB and Canon MF420 Series. Content is a small PDF (~11 to 13 KB); canPrintData: returns true. Troubleshooting tried Restarted the iPad and reinstalled the app. Each buys exactly one successful print before the failure returns. Compared observable state between the working and hung jobs. Identical in every respect. During a hang, printed the same content to the same printer from Files via the share sheet. Worked normally, including on repeat. Paused in the debugger during the hang. No blocked thread; no PrintKit frame, XPC wait, or semaphore anywhere in bt all. Called contactPrinter before each job on the retained printer. Returned true quickly, and the job still hung. Implemented printInteractionControllerParentViewController(_:) in case a presentation context was missing. UIKit never calls it on this path. Workaround Creating a new UIPrintInteractionController per job resolves it completely. A long-lived instance the app creates itself fails exactly like .shared does, so the issue is reuse of a controller that has already run a job, not the shared singleton specifically. Is per-job instantiation the supported pattern? The docs say the shared instance "represents a print job" but don't state whether a controller may be reused for a second job, and every sample I can find uses sharedPrintController with the present… methods rather than print(to:).

App Name: Tempo Soccer App App Id: 6809041619 Support Ticket Id: ID is 102991364712. No response to support tickets or expedite requests either. Phone support seems to be temporarily unavailable. I missed a launch event and another one is due in next couple of days. What are my options ? Any help is highly appreciated.

I am a long time developer but have never incorporated an IAP into any of my work so this is very new to me. So to save time I have used some AI for coding, but the code is having an issue and I'm not sure whether it is in the code or in Xcode. Xcode 27 on macOS 27.0.1 for iOS 27.0.1. IAP is to unlock full access after a 14-day trial. DESCRIPTION OF PROBLEM In local Xcode StoreKit testing, Product.purchase() returns .pending (as expected, since "Ask to Buy" is enabled), and Xcode’s transaction manager continues to show “Pending Approval.” After closing and reopening the app’s purchase sheet, the same transaction appears as verified and non-revoked in Transaction.currentEntitlements and is delivered through Transaction.updates, giving full access to the app. This reproduces in a standalone UIKit test app (linked below). The source file in question is AppAccessManager.swift. The relevant functions are: AppAccessManager.purchaseProduct() Calls product.purchase(). Handles .pending by recording a request reminder and displaying feedback. AppAccessWindowViewController.viewDidLoad() Runs when the purchase-options sheet is opened. Calls manager.start() followed by manager.refreshAccessState(). This is the sheet-opening path associated with the unexpected transaction delivery. AppAccessManager.refreshAccessState() Iterates Transaction.currentEntitlements. A transaction still labeled “Pending Approval” in Xcode is returned here as verified and nonrevoked. AppAccessManager.startListeningForTransactionUpdates() and handleTransactionUpdate(_:) The same pending transaction is also delivered through this sequence as verified and nonrevoked. The handler applies access before calling transaction.finish(). AppAccessManager.applyVerifiedPurchase(_:) Applies verified transactions received from successful purchases or the listener. STEPS TO REPRODUCE https://avliscoding.com/storekittest.zip Launch app Select "Open Purchase Sheet" Start trial Quit app, enable "Ask to Buy" in StoreKit file configuration settings Restart app. Select Purchase (will give a pending message in response) Close sheet Reopen sheet The app now believes it has made that purchase even though the purchase is still "Pending" in Xcode.

I can’t launch an Xcode development build on my iPhone. The iPhone says “Unable to Verify App — An internet connection is required to verify trust of the developer,” and Xcode says the Developer App Certificate is not trusted. The app builds and installs successfully. I’ve tried Wi-Fi and cellular, and Developer Mode is enabled. A browser request to ppq.apple.com returned “OK,” but verification still fails. Could this be a PPQ verification issue?

Hi Quinn, Following your recommendation by email, I’m posting this as a new thread. Thank you again for your guidance on Virtualization.framework. This is a separate question about ordinary host-side subprocess ownership and timeout recovery, not VM cleanup. Target environment: Intel x86_64 macOS Monterey 12.7.6, build 21H1320 Python 3.13.15 Public, supported mechanisms; no root privileges, private APIs or kernel extensions We are verifying a subprocess supervision component with this process structure: Trusted caller process → runner → pytest → private helper → native subprocess Each parent normally owns the consuming wait for its direct child. The private helper exclusively manages signalling and reaping of its native child. Outer processes do not signal saved helper/native PIDs. Cancellation is cooperative, through channels and file/token delivery. The runner observes its fresh pytest child, drains stdout/stderr with bounded retention, and consumes its exact child’s status after exit is observed. The runner, pytest and helper are launched in separate sessions. Consequently, signalling pytest’s process group would not cover the separately sessioned helper and its native child. The unresolved failure case is: A fresh pytest invocation starts. Cancellation delivery fails, or delivery succeeds but the work does not finish. The runner continues observation and bounded output draining within the remaining deadline. The deadline expires while pytest or processes below it may still be alive. The runner reports an unresolved outcome and may exit. The caller also has a bounded deadline and may return without consuming its runner child. Closing capture pipes can cause EPIPE and disturb the child’s cleanup. Exiting a consuming parent also relinquishes its ability to collect that child’s eventual status. The outer caller does not automatically acquire wait rights over pytest or its descendants. Our current policy retains affected files, preserves the original failure, and prevents subsequent tests from starting. We do not treat cancellation delivery, pipe EOF, successful signal delivery, or direct-child reap as proof that every descendant has stopped. This prevents false success, but does not resolve responsibility for work that remains alive. We have considered separating the caller’s response lifetime from the consuming owners’ lifetimes: the caller could return an unresolved response while both existing parents remain alive, draining output and collecting their direct children later. However, keeping them alive adds no termination authority and does not address a crash of either owner. I am not asking for an absolute guarantee against arbitrary kernel failures, or a promise that SIGKILL always completes within a fixed time. I would like to understand the supported architectural approach on Monterey. My questions are: Is retaining the existing consuming parents beyond the response deadline the appropriate pattern, or is there a supported macOS facility that provides a better ownership and recovery boundary? What safe termination authority should those owners retain over their fresh direct children? If process groups are part of the solution, what lifecycle rules are needed to avoid acting on a reused identifier, particularly after leader exit or reaping? Is there a supported way to manage the separately sessioned helper/native work if an intermediate parent exits? Or must each level independently retain its own supervision and cleanup responsibility? If the consuming owner itself crashes, is there a supported recovery mechanism for ordinary subprocesses? Would launchd or XPC materially help, and what limitations would remain for descendants in separate sessions? Which design constraint would you recommend changing: cooperative-only cancellation, the fixed lifetime of the runner, or the process topology? These are our current choices, not restrictions we assume macOS imposes. Our practical goal is a bounded response while an identifiable owner remains responsible for unsettled work, with appropriate termination authority and an honest unresolved outcome when cleanup cannot be established. The immediate qualification scope is only three simple tests, using shell bodies such as exit, kill -9 $$, and echo with ordinary exit statuses. They contain no intentional background work, pipelines or command substitutions. We would prefer a proportionate supported pattern rather than a new general supervision framework. If a reduced example would help clarify the question, I can provide one. Thank you for your time and guidance.

Layout margin guides are broken throughout UIKit and SwiftUI on the iPhone Duo sim in iOS 27.1 RC. For example, a cell which looks perfectly fine on a normal iPhone sim (which has a compact horizontal size class), has zero vertical layout margins on iPhone Duo. Here's some screenshots. The red dotted lines are supposed to show the margins in the cell content view, i.e., the boundary between default padding around the cell (for its background) and the content of the cell. On every other device and size class these all work, and will have some vertical margin. iPhone 18 Pro: iPhone Duo: As you can see, the border is cut off. No vertical margins at all. iPhone Duo Unfolded: Not only is it busted just in UICollectionViews. Check out this segmented control (also configured with layout margins). This works fine on catalyst, iPhone, and iPad. This makes me very nervous about shipping with the 27.1 SDK. Is this a known issue? If so, what is the recommended workaround in the meantime? FB25097501

Hello! I am hoping a DTS engineer or someone who knows the Capability Requests portal can help, because I am stuck between a written support confirmation and what the portal actually shows. Background. We are building a native macOS iSCSI initiator for SOHO and home NAS use, developed over close to two years. A userspace daemon runs the iSCSI protocol and a DriverKit system extension presents the remote LUN as a block device. The code is essentially complete. Only the DriverKit extension cannot be signed, loaded and validated without the entitlement. We submitted request 32PC8MGU57 for two entitlements: com.apple.developer.driverkit.family.block-storage-device for the extension com.aviontex.iscsi.AviontexISCSI.AviontexInitiator com.apple.developer.driverkit.userclient-access for the app com.aviontex.iscsi.AviontexISCSI, scoped to the extension bundle id The problem. On June 25 Developer Support confirmed in writing that both entitlements were granted. The portal does not match that: Block Storage Device: No Requests: on both App IDs UserClient Access: Assigned: on the app SCSI Controller: Submitted: on the app So the one entitlement we actually need, Block Storage Device, shows as never requested, even though request 32PC8MGU57 covered it and support confirmed the grant. The case was escalated to the senior team on July 2 (case 102922935570). Follow-up emails since then have not received a response. Why Block Storage Device specifically Our initiator has no PCI or Thunderbolt bus and no DMA path, so SCSIControllerDriverKit does not fit. This is confirmed by DTS in thread 776020, where Kevin Elliott explains that SCSIControllerDriverKit passes data through fBufferIOVMAddr as a physical address with no mechanism to convert it into a VM address the dext can access. He also notes it cannot be used with any bus other than PCI or Thunderbolt. Block Storage Device is therefore the family we need. My questions: Am I reading the portal correctly: Block Storage Device not requested, UserClient Access assigned, SCSI Controller submitted? From here, what is the correct way to get Block Storage Device onto these two App IDs, with both the Development and the Distribution grant, since our public beta depends on Distribution? Should I submit a new request through the Capability Requests tab or does the escalated case handle it? Is there any way to get visibility on the escalated case, since email follow-ups are not being answered? A full technical justification is prepared and we are happy to share the source code. Any guidance would be appreciated. Thank you.

Sign in with Apple fails for every App ID in our team (K9UFUZF2XW), on every device and every Apple ID we have tried. The system sheet appears, the user authenticates successfully, the sheet then shows "Sign Up Not Completed", and no credential is returned. The failure happens after authentication — this is not a client-side rejection. I have spent several days isolating this and have ruled out everything on my side. Posting the full evidence in case an Apple engineer can look at the server-side state for our team, and in case it helps others hitting the same wall. WHAT THE FRAMEWORK ACTUALLY RETURNS The client library we use (expo-apple-authentication) discards the original NSError, so I patched its native layer to surface the raw error verbatim. This is what ASAuthorizationController hands back to didCompleteWithError, immediately after the user authenticated and the sheet displayed "Sign Up Not Completed": ASAuthorizationError .canceled (rawValue = 1001) domain = com.apple.AuthenticationServices.AuthorizationError code = 1001 desc = The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError, error 1001) userInfo: NSUnderlyingError: So the framework reports a user cancellation that never happened, with a completely empty userInfo and no underlying error. There is no diagnostic information on the client at all — I cannot debug this any further from my side, because the information does not exist there. Note: the same failure surfaces as a different error code depending on the client library version — .unknown (1000) with the older version, .canceled (1001) with the current one. The user-visible behaviour ("Sign Up Not Completed") is identical in both. So the error code is not a reliable signal here. WHAT I RULED OUT Not the App ID. I created a brand-new App ID (kz.auraai.ios) with Sign in with Apple enabled as a primary App ID, built a fresh binary, tested on the same device with the same Apple ID — identical failure. Two independent App IDs in the same team fail the same way. Not the entitlement. Verified inside the signed binary, not just in the portal: application-identifier = K9UFUZF2XW.kz.auraai.ios com.apple.developer.applesignin = ["Default"] I also tried the workaround suggested elsewhere on these forums (removing the entitlement while keeping the capability in the portal). That made it strictly worse: iOS then rejects the request instantly, without showing the sheet at all. Which confirms iOS reads the entitlement correctly, the sheet works, and the user authenticates — the failure is downstream of all of that. No stray or wildcard App IDs. A commonly cited cause is other App IDs in the team lacking the entitlement. I enumerated the whole team via the App Store Connect API: it contains exactly two App IDs, both with APPLE_ID_AUTH = PRIMARY_APP_CONSENT. No wildcard identifiers exist. Not the Apple ID, the device, or the iOS version. The same Apple ID, on the same device, with the same iOS, signs in successfully through another app belonging to a different team (Expo Go, host.exp.Exponent) — a valid identity token is returned. A second, unrelated Apple ID on another device fails in my app in exactly the same way. So this is not scoped to one account: it affects every user of the app. Agreements and membership are in good standing. Program License Agreement accepted 30 June 2026; Developer Agreement accepted 26 June 2026; membership active. Both distribution types fail. TestFlight and ad-hoc. WHAT IS LEFT After all of the above, the only variable that differs between the working case (a different team's app, same device, same Apple ID) and the failing case (my app) is the Apple Developer team itself. This exact signature — sheet renders fully, final server submit fails, "Sign Up Not Completed", delegate reports canceled with no userInfo, not reproducible in other apps on the same device — is documented in thread 122458 ("Error: Sign-Up Not Completed"). In that case it affected multiple developers, including Apple's own sample app, and was ultimately resolved by Apple on the server side, with a recurrence reported in June 2025. THE ASK Could someone from Apple check the server-side Sign in with Apple registration for team K9UFUZF2XW (App IDs kz.auraai.app and kz.auraai.ios)? I am not looking for configuration advice — I have exhausted the client side and there is nothing left to configure. This looks like the same server-side state that was fixed in the referenced cases. Feedback Assistant: FB23716661 (includes sysdiagnose with the Accounts/AuthKit profile, timestamp, and video of the failure). This is currently blocking us: because Sign in with Apple works for none of our users, guideline 4.8 prevents us from offering Google Sign-In, so we are shipping with email-only login. Happy to provide the binary, entitlements dump, or a fresh sysdiagnose on request.

MacBook Air (M4) Current build: macOS 27 Developer Beta (26A5368g) I have a system-wide Location Services failure affecting Apple Maps, Safari geolocation APIs, and any application requesting the current location. Symptoms: Apple Maps cannot determine current location. Safari and browser geolocation APIs fail. Websites report that location cannot be found. Location Services are enabled and permissions are granted. The issue has persisted across: macOS 26.5 beta macOS 26.6 beta macOS 26.6 beta 2 macOS 27 Developer Beta Troubleshooting already performed: Multiple Wi-Fi networks tested. iPhone hotspot tested. VPN enabled and disabled. Location Services reset. Permissions reset and reauthorized. New clean local user account created (no Apple ID, no third-party software). Issue reproduces identically in the clean account. Technical observations: locationd logs repeatedly show: knownCount = 0 AlsWifi = unknown while Wi-Fi scanning itself appears successful: queryMacAddresses.size = 57 The system sees dozens of nearby access points, but none appear to be recognized for Wi-Fi positioning. Additional findings: Wi-Fi hardware functions normally. Internet connectivity is normal. Bluetooth and Find My device presence work. GeoServices resources are present on disk. No successful location fix is ever produced. Has anyone seen similar CoreLocation / GeoServices behavior where Wi-Fi scans succeed but knownCount always remains 0 and no location fix is generated?

My app is live, I’ve already spent money promoting it, and people can’t subscribe. I’m losing potential customers while the fix sits in the review queue, and I’m honestly really frustrated. I was told my corrected submission would still get expedited review, but it’s been almost 5 hours with no movement. I contacted support around midnight and still haven’t had an actual response, just automated acknowledgements. I’ve tried calling too, but phone support has been unavailable all morning. Is there anyone from App Review who can please look into this? I need to know if something is holding it up or if there’s anything else I need to do. This is affecting my business right now.

In my app there are two main layers both animate. Due to performance reasons the lower of the two layers is completely opaque and animates at 12fps via a TimelineView. It has a lot of views that move per frame however everything moves slowly so that lower frame rate is fine. The second layer however has only one View and uses a Canvas rather than various SwiftUI views. It however does look better running at 60fps. It fills the screen but is mostly transparent. My hope would be that despite having the 60fps layer on top that the lower layer is still invalidating at a lower frame rate. I would furthermore hope that the compositing step would recognize it doesn't need to re-render layer one for a least half of the frames and can just composite layer two on top. Does anyone happen to know how SwiftUI and layout step and render server behave in this scenario?

Hi, I am trying to complete the payment for my Apple Developer Program enrollment under my organization DigiSutra. I am facing two different errors depending on the device I use: On Mobile (iPhone): When I try to purchase/subscribe to the Apple Developer Program, I get the error: "Unable to Purchase – This item is currently not available in your country/region." On MacBook: When I try the same purchase, the process shows "Unable to Continue" and does not proceed further. I have already completed my D-U-N-S Number verification and all required organization details under the legal entity name DigiSutra. My Apple ID region and billing details are correctly set to India. I have tried this on multiple devices (iPhone and two separate MacBooks) using the same Apple ID, and the issue persists consistently — so this does not appear to be a device-specific issue. Could you please help me understand: Why the App Store is showing the Developer Program as unavailable in my region despite my account being set to India? Whether this is related to my organization enrollment/D-U-N-S verification still being in review on Apple's end? What steps I need to take to successfully complete this purchase? Account details: Organization: DigiSutra Country/Region: India Errors: "Not available in your country/region" (iOS), "Unable to Continue" (macOS) Looking forward to your assistance in resolving this at the earliest, as this is blocking my organization's app publishing process. Thank you, Jaimik Patel DigiSutra

Hello Apple Developer Support, For two months, the enrollment page at developer.apple.com/programs/enroll shows this message: "We are unable to process your request. An unknown error occurred." The error appears in Safari on Mac after I choose "Individual / Sole Proprietor" and click Continue. App Store Connect (appstoreconnect.apple.com) shows the same "Unknown error." Signing in to the Apple Developer app on my iPhone works well with the same Apple ID. I have written to support earlier and still await a reply. Please check my Apple ID, find the cause of the error, and complete my enrollment in the Apple Developer Program as an individual. A phone call is welcome as well. Thank you, Ekaterina

I have developed a Driverkit extension which matches for iPadOS which is bundled within my app. My driver contains two different personalities - one with provider as USBDriverKit (USB3) and the other as PCIDriverKit (USB4). When enabled, the driver matches/loads, initiates the class with the right personality based on whether the device it matches is operating in USB3/USB4 and works as intended. Recently, we have come across an issue when operating in USB4 and below are the steps to reproduce. Platform: iPadOS 17 (Issue not observed following the same steps in iPadOS 18 and higher, though cannot be full sure as I have tested only in some versions of 18, 26 and 27). Tested in iPad having a USB-4 compatible port. Steps to reproduce: Install the app. This provides an option to enable the driver which comes with it from the app's system settings. Enable the driver from settings. Connect a device which is compatible with the driver in USB4 so that the specific personality can be loaded. Verify the same. With the driver still loaded, uninstall the application. On uninstallation, ideally, Apple's inbox IONVMeController should match on the re-enumeration and get loaded without a re-plug being required. However, this is not the case as the port becomes unresponsive. Even after a re-plug of the device, it still does not get detected by the iPad itself. This is specifically when I try to connect the device in USB 4 as this specific driver personality matches only in this case. If I try the same steps as above or try to connect the same device in USB3 after this issue has occured, the device gets detected and works as intended. To make the port to be usable again in USB4, a restart of the iPad has to be performed. Has this been observed before with PCIDriverKit or DriverKit in general? Is this some kind of a known limitation in iPadOS 17 in particular or does this have something to do with the iPad model too? Is there any workaround that can be followed to prevent this from happening?