Overview

Hi, A reviewer rejected my app and asked me to reply in the Resolution Center with an explanation about part of the subscription flow and to provide an additional demo account. I provided the requested information within about 30 minutes of the reviewer’s message. However, it has now been 12 days and I have not heard back from the reviewer. I also sent follow-up messages through App Store Connect and contacted Apple Support via email 5 days ago regarding this issue, but I still haven’t received a response. Is this normal in situations like this? What would be the best thing to do now — keep waiting, or submit a new build? Thank you.

On the iPad Pro 12.9-inch (3rd generation) cellular model, when you touch the screen with four fingers and then move your fingers, the touch is no longer detected. The same operation with one to three fingers works normally. This phenomenon does not occur when accessibility is turned on. Is this a beta-specific issue that will be fixed in the official release?

I managed to publish the first version of my app at the beginning of February. I was lucky, I guess. On 11th of February, I added a new version which contains in app purchases. The app went "in review" a few hours later and since then ... nothing. After a week or so I sent a first email support. They claim responding in 2 working days: no response. Then I sent another one. 2 days later another one. Tried expedite review several times: nothing. Last week I finally got an answer to my first email: they apologize, blah blah. But still nothing. This is very very annoying. I longtime hesitated to purchase the Apple developer program and finally did it. Now I regret doing so. They seem they don't care about. We buy expensive Apple gear. We develop applications we cannot even install on our devices without Apple developer subscription! And they treat us like this. What is going on, Apple? Are you still there?

When building our project for Mac Catalyst with Xcode 26.2, we get this warning almost a hundred times, once for every object file: directory not found for option '-L/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst' Somehow, every Link <FileName>.o build step got the following parameter, regardless if the target contained Metal files or not: -L/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst The toolchain is mounted at this point, but the directory usr/lib/swift/maccatalyst doesn't exist. When building the project for iOS, the option doesn't exist and the warning is not shown. We already check the build settings, but we couldn't find a reason why the linker is trying to link against the toolchain here. Even for targets that do contain Metal files, we get the following linker warning: search path '/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst' not found Is this a known issue? Is there a way to get rid of these warnings?

**To offer apps or other in-app purchases, you must update your legal entity information prior to signing the Paid Apps Agreement. Edit Legal entity ** Hello everyone, i have for days and weeks tried to change this so i can update my address, but i cannot change it by my own. And all i see is message above Does anyone know exactly how long it takes to be updated by apple support? what other alternatives there to sign up for business agreements so i can not loose much time ? Thanks

Hello, I am wondering if an app that does the following is possible or is impossible due to ios limitations for apps? An app that access all sms messages, and or all phone calls logs? (goal is to save them and not have to filter them manually) An app that control OTHER apps permissions and or read permissions status of all other apps?

Hi everyone, We recently submitted our first B2B iOS app and had a quick question about expected review timing. The application is intended for registered wholesale clients of a food distribution company and the launch is coordinated with the rollout of our ordering platform for customers. Since the launch communication with clients is already scheduled, we wanted to confirm whether there is anything missing in the submission that could delay the review. If anyone from the App Review team can take a quick look or confirm the submission is complete, we would greatly appreciate it. App ID: 6759172913 Thank you!

I am facing an issue with my app. It works perfectly on TestFlight, and I have tested it on several devices, where it also runs without any problems. However, when the app is tested in the Apple testing facility, it shows an unexpected server error message. I have tested the app using multiple VPNs and different locations in Sri Lanka, and it works perfectly in all cases. It also works correctly when distributed through third-party app stores. At this point, I am not sure what is causing this issue. I have already submitted more than 10 app versions, each with different fixes that I thought might solve the problem, but the issue still persists. Could someone please help me understand what might be causing this problem? (the above provided screenshot from apple)

I am referencing: https://aninterestingwebsite.com/documentation/foundation/pausing-and-resuming-uploads Specifically: You can’t resume all uploads. The server must support the latest resumable upload protocol draft from the HTTP Working Group at the IETF. Also, uploads that use a background configuration handle resumption automatically, so manual resuming is only needed for non-background uploads. I have control over both the app and the server, and can't seem to get it to work automatically with a background url session. In other words, making multiple requests to get the offset then upload, easy but I am trying to leverage this background configuration resume OS magic. So anyone know what spec version does the server/client need to implement? The docs reference version 3, however the standard is now at like 11. Of course, I am trying out 3. Does anyone know how exactly this resume is implemented in iOS, and what exactly it takes care of? I assumed that I can just POST to a generic end point, say /files, then the OS receives a 104 Location, and saves that. If the upload is interrupted, when the OS resumes the upload, it has enough information to figure out how to resume from the exact offset, either by making a HEAD request to get the offset, or handle a 409. I am assuming it does this, as if it doesn't, the 'uploads that use a background configuration handle resumption automatically' is useless, if it just restarts from 0. Note, of course making individual POST/HEAD/PATCH requests manually works, but at that point I'm not really leveraging any OS auto-magic, and am just consuming an API that could really implement any spec. This won't work in the background, as the OS seems to disallow random HTTP requests when it wakes the app for URLSession background resumes. As of right now, I have it 'partially' working, insofar as the app does receive the 104 didReceiveInformationalResponse url delegate call, however it seems to then hang; it stops sending bytes, seemingly when the 104 is received. However, the request does not complete. In other words, it doesn't seem to receive a client timeout or otherwise indicate the request has finished. Right now, I am starting a single request, POSTing to a /files end point, i.e. I am not getting the location first, then PATCHing to that, as if I do that, the OS 'automatic' resuming fails with a 409, i.e. it doesn't seem to make a HEAD request and/or use the 409 offset correction then continue with the PATCH. Any idea what could be going on?

I signed up for the Developer Account Program, but I keep getting a message that my registration is under review. Obviously, I haven't paid yet because I couldn't find a link to pay the $99 when I signed up. I've sent two emails for support, but I haven't received a response. Has anyone else had the same problem? Thanks.

I've created a custom keyboard and implemented the: class KeyboardViewController: UIInputViewController The imlementation looks like this: override func viewDidLoad() { super.viewDidLoad() var stack = UIStackView() stack.axis = .vertical stack.spacing = 8 stack.translatesAutoresizingMaskIntoConstraints = false stack.distribution = .fill stack.heightAnchor.constraint(equalToConstant: 200).isActive = true .... view.addSubview(stack) NSLayoutConstraint.activate([ stack.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 20), stack.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -20), stack.topAnchor.constraint(equalTo: view.topAnchor, constant: 10), stack.bottomAnchor.constraint(equalTo: view.bottomAnchor, constant: -10) ]) The problem is that the keyboard seems to start showing in the size (I've printed the parent frame): Optional(<UIView: 0x101008480; frame = (0 0; 390 844); autoresize = W+H; layer = <CALayer: 0x600000207b80>>) and than resizes to my given height. But it's not fast enough so that I can see some glitches whenever I switch from another keyboard to my custom keyboard. Is there a way to prevent this resizing or start the keyboard in a given size? This is just not the best user experience.

0 0x10109152c __assert_rtn + 252 1 0x101006054 void std::__1::__introsort<std::__1::_ClassicAlgPolicy, ld::AliasAddressOrderer&, ld::Atom const**, false>(ld::Atom const**, ld::Atom const**, ld::AliasAddressOrderer&, std::__1::iterator_traits<ld::Atom const**>::difference_type, bool) + 0 2 0x1010059a4 ld::LayoutLinkedImage::assignAtomOffsetsInSection(ld::SectionLayout&, unsigned int, bool) + 680 3 0x10100a724 void dispatchForEach<ld::SectionLayout*, ld::LayoutLinkedImage::sortAtomsWithinSections()::$_0>(std::__1::span<ld::SectionLayout*, 18446744073709551615ul>, unsigned long, ld::LayoutLinkedImage::sortAtomsWithinSections()::$_0)::'lambda'(unsigned long)::operator()(unsigned long) const + 7852 4 0x180818aec _dispatch_client_callout2 + 16 5 0x1808137f8 _dispatch_apply_invoke3 + 336 6 0x180818ad4 _dispatch_client_callout + 16 7 0x180801a60 _dispatch_once_callout + 32 8 0x180812938 _dispatch_apply_invoke + 252 9 0x180818ad4 _dispatch_client_callout + 16 10 0x1808359dc _dispatch_channel_invoke.cold.5 + 32 11 0x18081113c _dispatch_root_queue_drain + 736 12 0x180811784 _dispatch_worker_thread2 + 180 13 0x1809b7e10 _pthread_wqthread + 232 ld snapshot written at /tmp/AIChatDoctor-2026-03-10-150254.ld-snapshot ld: Assertion failed: (aliasSectionNum == sectionNum && "alias and its target must be located in the same section"), function assignAliasAtomOffsetInSection, file Layout.cpp, line 4805. clang: error: linker command failed with exit code 1 (use -v to see invocation)

We are assisting a client with their app integration. The client believes that NEPacketTunnelProvider, NEHotspotHelper, and NEHotspotManager extensions stop functioning if the containing app hasn't been launched by the user within some recent window (e.g. 30, 60, or 90 days). We haven't been able to find any documentation supporting this claim. Specifically, we'd like to know: Is there any app launch recency requirement that would cause iOS to stop invoking a registered NEHotspotHelper or NEHotspotManager configuration? Is there any app launch recency requirement that would cause iOS to tear down or prevent activation of a NEPacketTunnelProvider? More generally, does iOS enforce any kind of "staleness" check on apps that provide Network Extension or Hotspot-related functionality, where not being foregrounded for some period causes the system to stop honoring their registrations? If such a mechanism exists, we'd appreciate any pointers to documentation or technical notes describing the behavior and timeframes involved. If it doesn't exist, confirmation would help us guide our client's debugging in the right direction. Thank you.

I am contacting you to clarify a technical issue regarding the behavior of App Store Server Notifications (V2), as we have observed differences depending on the subscription plan. Currently, we have noticed the following behavior when a refund occurs for an auto-renewable subscription: Observed Behavior: Monthly Plan:When a refund occurs, we receive a REFUND notification, followed by an EXPIRED notification indicating the subscription has ended. Annual Plan:When a refund occurs, we receive the REFUND notification, but the expected EXPIRED notification does not arrive. Questions: Are there any differences in the conditions for sending EXPIRED notifications after a REFUND, depending on the subscription plan (monthly vs. annual)? Is the absence of the EXPIRED notification for annual plans an intended behavior by Apple, or could it be a possible issue? I would appreciate your guidance on this matter.

Hello, I am experiencing the same severe delays as many other developers on the forum recently. I have multiple apps ( 6759218500 and 6758253704)that have been completely stuck in the "Waiting for Review" status, with one sitting there since mid-February. I have already tried reaching out via the "Contact Us" form multiple times, but my open support case (Case ID: 102828235824) has received no follow-up or resolution. Could someone from the app review team please look into this, any assistance would be greatly appreciated, as the standard support channels seem to be unresponsive. Thank you.

Objective: Downloading and running an old Swift iOS App on iPhone 5s with iOS 12.5.8. Development System and Tools: Apple macBook, M4 Pro, running macOS Tahoe 26.3.1 (25D2128). Xcode Version 26.3 (17C529)

I'll try to ask a question that makes sense this time :) . I'm using the following method on NSFileManager: (BOOL) getRelationship:(NSURLRelationship *) outRelationship ofDirectoryAtURL:(NSURL *) directoryURL toItemAtURL:(NSURL *) otherURL error:(NSError * *) error; Sets 'outRelationship' to NSURLRelationshipContains if the directory at 'directoryURL' directly or indirectly contains the item at 'otherURL', meaning 'directoryURL' is found while enumerating parent URLs starting from 'otherURL'. Sets 'outRelationship' to NSURLRelationshipSame if 'directoryURL' and 'otherURL' locate the same item, meaning they have the same NSURLFileResourceIdentifierKey value. If 'directoryURL' is not a directory, or does not contain 'otherURL' and they do not locate the same file, then sets 'outRelationship' to NSURLRelationshipOther. If an error occurs, returns NO and sets 'error'. So this method falsely returns NSURLRelationshipSame for different directories. One is empty, one is not. Really weird behavior. Two file path urls pointing to two different file paths have the same NSURLFileResourceIdentifierKey? Could it be related to https://aninterestingwebsite.com/forums/thread/813641 ? One url in the check lived at the same file path as the other url at one time (but no longer does). No symlinks or anything going on. Just plain directory urls. And YES calling -removeCachedResourceValueForKey: with NSURLFileResourceIdentifierKey causes proper result of NSURLRelationshipOther to be returned. And I'm doing the check on a background queue.

Dear Xcode Team, Please consider adding an option to position the Coding Assistant on the right side of the editor. Currently, when the assistant panel is open, it makes it difficult to access the Project Navigator at the same time. Having the ability to move the Coding Assistant to the right side would allow developers to keep the Project Navigator visible while interacting with the assistant, improving workflow and efficiency. Thank you

Hello App Review team and iOS developer community, I submitted an updated version of my app on App Store Connect on February 5, 2026, and it entered the review process on February 7, 2026. However, I do not understand why, as of today (March 8, 2026), its status is still "In Review." I have already contacted Developer Support on February 27, 2026 but have only received the following automated reply: “Thanks for submitting your support request. We’ve received your support request and will get back to you as soon as possible.” More than a month has passed, and I still haven’t received any official follow-up or updates from Apple regarding this issue My case ID : 102831527320 Apple ID : 1628986976 I would greatly appreciate your help in reviewing and approving this update as soon as possible, as the delay is affecting many users. Thank you for your support.

Same problem. All our apps (IDs: 6756160582, 6756997290, 6758690019) have been in "Waiting for Review" for more than one month, and we have received no specific response explaining why it is taking so long. We hope the developer team can support us or elaborate on what we can adjust to speed up the review process.