Overview

Post

Replies

Boosts

Views

Activity

Kernel Sandbox/System Policy intermittently denies ALL file access (not just mount syscall) on NFS mounts
I'm seeing a recurring issue on macOS 26.5.2 (build 25F84) where the kernel's Sandbox/System Policy layer intermittently denies file access on NFS mount points from local network servers. Posting here in case anyone recognizes this pattern or has a workaround, and flagging it since I've also filed a Feedback Assistant report (with a live-captured sysdiagnose) for the same issue. WHAT HAPPENS Two independent NFS mounts to two separate, unrelated servers on my LAN start failing simultaneously with "Operation not permitted." The kernel log shows: kernel: (Sandbox) System Policy: mount_nfs(PID) deny(1) file-mount /path/to/mount Critically, it's not limited to the mount syscall - within the same few-second window, System Policy also denies ls, perl, diskutil, and even umount -f on the exact same path, for otherwise unrelated processes. So it looks like a transient, path-scoped kernel decision rather than something specific to NFS or the mount syscall. It self-heals anywhere from seconds to ~30 minutes later, then recurs - documented 30-80+ occurrences/day via a background watchdog script. WHAT I'VE RULED OUT Server-side cause: two independent servers on different hardware fail identically at the same instant. Network issue: checked network logs in the same window, no correlated connectivity event. Third-party kext conflict: kextstat shows zero third-party kexts loaded. syspolicyd database corruption: no "ASP: Validation category" signature present. TCC/Full Disk Access: already granted; the denying layer is kernel Sandbox "System Policy," not TCC. QUESTION Has anyone else run into System Policy denying file-mount/file-read-data/file-unmount on network volume paths intermittently like this? Is there any userland way to inspect or reset whatever internal state drives this decision (I haven't found one - no spctl/tccutil/sysctl lever that touches it)? Happy to share more log excerpts if useful.
14
0
585
3h
Guideline 4.3(b) — where is the line between a Lock Screen utility and a wallpaper app?
I'm building an iPhone app that is primarily an editor: it renders a pixel-accurate Lock Screen preview for the user's specific device model (clock, date, widget row, Dynamic Island), isolates the photo's subject on-device with Vision so it overlaps the clock for the depth effect, measures contrast behind the clock, and generates backgrounds procedurally with Metal. It also ships a small library of original images I create myself. Since June 2026, 4.3(b) names wallpaper apps explicitly. Has anyone shipped something in this space recently? Specifically: Did the presence of any image library push the review toward the wallpaper category, regardless of the tooling? What did your screenshots and subtitle emphasise? Which primary category did you use? Any experience appreciated.
0
0
18
3h
App removed from sale after 5.6 rejection – resubmitted 11+ days ago, still "Waiting for Review"
Hello, Our app was removed from sale following a Guideline 5.6 (Developer Code of Conduct) notice on July 22, 2026, citing concerns about "hidden functionality". We responded in detail explaining our multi-tenant, role-based architecture and provided full Review account access with no restrictions. We submitted a corrected build (version 1.1) on July 24, 2026, which has now been in "Waiting for Review" for 11+ days with no update, rejection, or further communication. App Name: Stay Easie Apple ID: 6784701866 Current version: 1.1 Submitted: July 24, 2026 Guideline referenced: 5.6.0 Developer Code of Conduct We have already: Submitted an expedited review request Called Apple Developer Support multiple times Provided complete role-based review credentials and detailed clarifications The app is currently unavailable on the App Store and this is directly impacting our client's business operations. Could someone from the app review team please take a look at this case? Happy to Provide any additional information needed. Thank you.
1
0
29
3h
Generation Error
So I'm having an issue with the FoundationModels framework but idk if this is just my feeling or not, the issue comes up after I updated my Mac into 26.6 the code was very simple actually: #Playground { let model = SystemLanguageModel.default let session = LanguageModelSession(model: model) print(model.availability) var query = "How to hide button" Task { do { let response = try await session.respond(to: query) print(response.content) } catch { print("\(error)") } } } the code works before I updated the version, but then after I updated the version it says: Error Domain=FoundationModels.LanguageModelSession.GenerationError Code=-1 "The operation couldn’t be completed. (FoundationModels.LanguageModelError error -1.)" UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=FoundationModels.LanguageModelError Code=-1 "(null)" UserInfo={NSMultipleUnderlyingErrorsKey=(\n "Error Domain=ModelManagerServices.ModelManagerError Code=1026 \"(null)\" UserInfo={NSMultipleUnderlyingErrorsKey=(\n)}"\n)}" ), NSLocalizedDescription=The operation couldn’t be completed. (FoundationModels.LanguageModelError error -1.)} this is runned in Xcode 26.6, additional information I have also coder 27 beta 4 installed in my Mac, is this problem occurring because the Xcode 26.6 and Xcode 27 beta 4?? can u guys help me
1
0
448
3h
Pinch gesture not recognized on MTKView when attaching it to a RealityView using a ViewAttachmentComponent in a immersive space
Hello! We are seeing a problem with a SwiftUI view that wraps an MTKView and that MTKView uses gesture recognizers from UIKit. One of those gestures we are using is UIPinchGestureRecognizer. And that gesture isn’t recognized at all when the SwiftUI view is attached to a RealityView using the ViewAttachmentComponent AND the RealityView is being shown in an ImmersiveSpace. If the SwiftUI view is attached to the RealityView using the init that has an attachment closure then pinching works fine there. So this definitely seems like a bug. Here is some code to help you reproduce the problem. Run this on a Vision Pro device. A simple red square will be rendered and if a single tap or pinch gesture is recognized on the red square, it will print to the console. App Code: import SwiftUI @main struct VisionPinchProblemsApp: App { var body: some Scene { WindowGroup { MenuView() } ImmersiveSpace(id: "RedSquare") { RedSquareView() } } } View code: import MetalKit import RealityKit import SwiftUI import UIKit struct MenuView: View { @Environment(\.openImmersiveSpace) private var openImmersiveSpace @Environment(\.dismissImmersiveSpace) private var dismissImmersiveSpace @State private var showImmersiveSpace = false @State private var immersiveSpaceIsOpen = false var body: some View { Form { Toggle("Show red square", isOn: $showImmersiveSpace) .task(id: showImmersiveSpace) { if showImmersiveSpace { await openImmersiveSpace(id: "RedSquare") immersiveSpaceIsOpen = true } else { if immersiveSpaceIsOpen { await dismissImmersiveSpace() immersiveSpaceIsOpen = false } } } } .onDisappear { // Attempt to close the immersive space on the way out. Task { if immersiveSpaceIsOpen { await dismissImmersiveSpace() } } } } } struct RedSquareView: View { let metalViewAttachmentID = "metalID" var body: some View { // Adds SwiftUI view using attachments closure. // Pinching and single taps are recognized here! // RealityView { content, attachments in // if let metalViewEntity = attachments.entity(for: metalViewAttachmentID) { // metalViewEntity.position = [0, 1, -1.25] // content.add(metalViewEntity) // } // } placeholder: { // ProgressView() // } attachments: { // Attachment(id: metalViewAttachmentID) { // MetalView() // } // } // Add SwiftUI view using ViewAttachmentComponent. // Pinching is not recognized here! // Single tapping is recognized ! // Why doesn't the red square show up in the Vision Pro simulator? RealityView { content in let metalViewEntity = Entity() let metalView = MetalView() .frame(width: 500, height: 500) let component = ViewAttachmentComponent(rootView: metalView) metalViewEntity.components.set(component) metalViewEntity.position = [0, 1, -1.25] content.add(metalViewEntity) } placeholder: { ProgressView() } } } struct MetalView: UIViewRepresentable { var device: MTLDevice? init() { self.device = MTLCreateSystemDefaultDevice() } func makeUIView(context: Context) -> MTKView { let mtkView = MTKView() mtkView.device = device mtkView.clearColor = MTLClearColor(red: 1.0, green: 0.0, blue: 0.0, alpha: 1.0) mtkView.delegate = context.coordinator let pinchGesture = UIPinchGestureRecognizer(target: context.coordinator, action: #selector(context.coordinator.handlePinch(_:))) mtkView.addGestureRecognizer(pinchGesture) let tapGesture = UITapGestureRecognizer(target: context.coordinator, action: #selector(context.coordinator.handleTap(_:))) mtkView.addGestureRecognizer(tapGesture) return mtkView } func updateUIView(_ uiView: MTKView, context: Context) { } func makeCoordinator() -> Coordinator { Coordinator(self) } class Coordinator: NSObject, MTKViewDelegate { var parent: MetalView init(_ parent: MetalView) { self.parent = parent } func mtkView(_ view: MTKView, drawableSizeWillChange size: CGSize) { } func draw(in view: MTKView) { guard let drawable = view.currentDrawable else { return } guard let descriptor = view.currentRenderPassDescriptor else { return } let commandQueue = parent.device?.makeCommandQueue() let commandBuffer = commandQueue?.makeCommandBuffer() let renderEncoder = commandBuffer?.makeRenderCommandEncoder(descriptor: descriptor) renderEncoder?.endEncoding() commandBuffer?.present(drawable) commandBuffer?.commit() } @objc func handlePinch(_ sender: UIPinchGestureRecognizer) { print("Pinch detected") } @objc func handleTap(_ sender: UITapGestureRecognizer) { print("Tap detected") } } }
1
0
17
3h
App Review 1+ week
Hello, I’m posting here because I’m experiencing a very unusual issue with the App Store review process and haven’t been able to resolve it through normal support channels. Our app has been waiting in App Review for over 1 week, which is far beyond the normal review timeframe. During this period, I contacted Apple Developer Support multiple times and even submitted an expedited review request, but the situation has not progressed. Some of my inquiries have unfortunately received no response, and the app remains stuck in review without any explanation. I fully understand that review times can vary, but a 1+ week delay without any status update or communication seems highly abnormal. If any Apple staff or experienced developers have encountered a similar situation, I would greatly appreciate any guidance on how to resolve this or escalate it properly. Thank you for any help or advice.
1
1
44
3h
App Still "Waiting for Review" Since July 22 – Anyone Else Experiencing Long Delays?
Hi everyone, I'm wondering if anyone else is experiencing unusually long App Review delays. My app has been in "Waiting for Review" since July 22 at 11:04 PM, and it still hasn't entered the review process. As of today, it's been nearly two weeks with no review activity. I understand that review times can vary depending on workload, app category, and other factors, but this is significantly longer than what I've experienced before. Has anyone else recently faced similar delays? How long did your app remain in "Waiting for Review"? Did it eventually get reviewed without taking any action? Did contacting Apple Developer Support help in your case? I'm mainly trying to understand whether this is a broader issue affecting other developers or if I should reach out to Apple Support. Thanks in advance for sharing your experience.
2
1
45
3h
App Stuck in Waiting for Review - 10 Days
Hello! I submitted my app for first time review on July 24th around 12pm EST and have not yet heard anything or seen any updates in App Store Connect. Is there anything I can do to check the status or nudge it forward? I have checked for messages, rejections, or issues to resolve in App Store Connect and can't seem to find any indication of a stall reason. I also submitted a support request on July 30th inquiring about potential delays and haven not yet heard back. ID's added to the bottom of this post. Thank you for your time! App ID: 6791030400 Case #: 20000123752874
0
0
14
3h
Individual Apple Developer enrollment in India blocked by “Unable to Continue”
I am attempting to enroll in the Apple Developer Program from India through the Apple Developer app. The app immediately displays: “Unable to Continue. Contact support at https://developer.apple.com/contact/.” I cannot proceed to enrollment type selection, identity verification, agreement, or payment. The issue is reproducible on an iPhone 16 Pro Max running iOS 26.5.2 with Apple Developer app 11.0.2. I verified the Apple Account details at account.apple.com, checked the Developer Account website, and confirmed that Apple Developer System Status reports no enrollment incident. The website shows “Join the Apple Developer Program” / “Enroll today,” while the required app flow remains blocked. I have opened a Developer Support case requesting a manual enrollment-state review and have filed Feedback Assistant report FB24014432 with the exact screenshot and reproduction steps. Has Apple Developer Support identified whether this alert normally indicates a stale historical enrollment, an unresolved identity-verification state, an account-information mismatch, or another backend restriction? I am specifically trying to determine the correct official escalation, secure verification, or reset procedure. Please do not suggest web enrollment as a workaround; Apple’s documentation states that enrollment in India must use the Apple Developer app.
1
1
58
3h
ManipulationComponent causes makeUIView(context:) to get called twice
Here I have some demo code that is rendering a cylinder "platter" using RealityKit and there is a red circle rendered on top of it which uses Metal and SwiftUI. When the platter appears you will see in the console that makeUIView(context:) is called twice while it is documented that it will only be called once when the view appears for the first time. So this seems like a bug. If you remove ManipulationComponent from the platter's components you will see that this problem goes away so it seems like that is the cause of the problem. Any insight here would be appreciated! Thank you. Here is what is printed in the console: Entity returned from EntityWrapper.makeEntity(context:) was already parented to another entity. This is not supported and may lead to unexpected behavior. SwiftUI adds entities to internally-managed entity hierarchies. Make UI View! This should be called once. Make UI View! This should be called once. Here is the app code: import SwiftUI @main struct SomeApp: App { var body: some Scene { WindowGroup { ContentView() } ImmersiveSpace(id: "TableTop") { TableTopPlatterView() } } } Here is the view code: import MetalKit import RealityKit import SwiftUI struct ContentView: View { @Environment(\.openImmersiveSpace) private var openImmersiveSpace @Environment(\.dismissImmersiveSpace) private var dismissImmersiveSpace @State private var showImmersiveSpace = false @State private var immersiveSpaceIsOpen = false var body: some View { Form { Toggle("Show table top", isOn: $showImmersiveSpace) .task(id: showImmersiveSpace) { if showImmersiveSpace { await openImmersiveSpace(id: "TableTop") immersiveSpaceIsOpen = true } else { if immersiveSpaceIsOpen { await dismissImmersiveSpace() immersiveSpaceIsOpen = false } } } } .onDisappear { // Attempt to close the immersive space on the way out. Task { if immersiveSpaceIsOpen { await dismissImmersiveSpace() } } } } } struct TableTopPlatterView: View { private var attachmentID: String { "RedCircle" } var body: some View { RealityView { content, attachments in if let redCircleEntity = attachments.entity(for: attachmentID) { // Lays the red circle in the platter. let rotation = Rotation3D(redCircleEntity.orientation) .rotated(by: .init(angle: .degrees(-90), axis: .x)) redCircleEntity.setOrientation(.init(rotation), relativeTo: nil) redCircleEntity.position.y = 0.026 platterEntity.addChild(redCircleEntity) content.add(platterEntity) } } placeholder: { ProgressView() } attachments: { Attachment(id: attachmentID) { MetalView() .clipShape(.circle) } } } /// The platter entity that the red circle lays on top of. private let platterEntity: ModelEntity = { let anchor = AnchorEntity( .plane( .horizontal, classification: .table, minimumBounds: [0.01, 0.01] ) ) let material = SimpleMaterial( color: .lightGray, roughness: 0.5, isMetallic: false ) let platter = ModelEntity( mesh: .generateCylinder(height: 0.05, radius: 0.475), materials: [material] ) platter.generateCollisionShapes(recursive: false) let components: [any Component] = [ InputTargetComponent(), GroundingShadowComponent(castsShadow: true), ManipulationComponent() // MARK: This is causing makeUIView to get called twice! ] platter.components.set(components) // Placed closer to the user when booted up. platter.position = [0, 1, -1.25] anchor.addChild(platter) return platter }() } // Metal view that renders a red square. struct MetalView: UIViewRepresentable { var device: MTLDevice? init() { self.device = MTLCreateSystemDefaultDevice() } func makeUIView(context: Context) -> MTKView { print("Make UI View! This should be called once.") let mtkView = MTKView() mtkView.device = device mtkView.clearColor = MTLClearColor(red: 1.0, green: 0.0, blue: 0.0, alpha: 1.0) mtkView.delegate = context.coordinator return mtkView } func updateUIView(_ uiView: MTKView, context: Context) { } func makeCoordinator() -> Coordinator { Coordinator(self) } class Coordinator: NSObject, MTKViewDelegate { var metalView: MetalView init(_ metalView: MetalView) { self.metalView = metalView } func mtkView(_ view: MTKView, drawableSizeWillChange size: CGSize) { } func draw(in view: MTKView) { guard let drawable = view.currentDrawable else { return } guard let descriptor = view.currentRenderPassDescriptor else { return } let commandQueue = metalView.device?.makeCommandQueue() let commandBuffer = commandQueue?.makeCommandBuffer() let renderEncoder = commandBuffer?.makeRenderCommandEncoder(descriptor: descriptor) renderEncoder?.endEncoding() commandBuffer?.present(drawable) commandBuffer?.commit() } } }
3
0
944
3h
No response from app reviewer since 7-17 :(
App ID: 6788510203 Case Number: 102948809441 I submitted an app on the middle of July, got my first response from a reviewer on July 16th, and again on the 17th, and have not received a response back since. After a week of not hearing back, I made and submitted a new build just to try and get it "unstuck" since it was no longer getting replies. That was last Monday at 9am. It's been 17 days now since I've last received a response. Is this common, or is my app stuck in some extended review state or something? Since my last build, it is still "waiting in review" so it seems like it's just not getting assigned to someone?
0
0
28
4h
Supported way to pre-approve kTCCServiceBluetoothAlways via MDM on macOS 27 (Golden Gate)
We develop a third-party endpoint security agent (DLP / device control). It needs kTCCServiceBluetoothAlways to enumerate paired Bluetooth devices and disconnect them selectively based on policy — without user interaction, since this runs unattended on managed fleets. Until recently we granted this silently via a com.apple.TCC.configuration-profile-policy (PPPC) profile pushed by MDM, or by writing directly to the TCC database — the latter no longer possible starting with macOS 27 (Golden Gate). As of macOS 27, tccd also ignores the PPPC profile approach: Override: skipping kTCCServiceBluetoothAlways ... as it is defined in deprecated PPPC profile As a result, end users now hit the standard Bluetooth access consent popup, which we have no way to suppress or pre-answer with Allow. ** Questions: ** Is there any currently supported MDM mechanism — profile-based, DDM, or otherwise — to pre-approve kTCCServiceBluetoothAlways for a specific managed app, so the popup never appears? If direct pre-approval is gone for good, is there any supported way to auto-answer the popup on the user’s behalf via policy (as exists for some other TCC services)? Is this now permanently interactive by design, or is a replacement mechanism planned for MDM-managed Bluetooth access?
0
0
11
4h
Rejected 3x under 2.1(b): cannot submit app version and In-App Purchases in the SAME review submission
Our app BandPro (Apple ID 6793207475) has been rejected three times under Guideline 2.1(b) because the In-App Purchase products were "not submitted for review". Everything is ready on our side, but App Store Connect will not let us put the app version and the IAPs into the SAME review submission: New binary uploaded: iOS 1.0 (build 22), attached to the version. 7 IAPs in "Ready to Submit": 4 auto-renewable subscriptions in the group "BandPro Pro" + 3 consumables. All have prices, availability in 175 storefronts, review screenshots and review notes. The app version is locked inside the REJECTED submission ("Unresolved Issues"). The only action available there is "Resubmit to App Review", which sends the version ALONE - exactly what caused the 2nd and 3rd rejections. Adding the IAPs for review creates a SEPARATE draft submission. That draft cannot be sent: it shows "To submit your items for review, add an app version for the selected platform" - but the version cannot be added because it is held by the rejected submission. We replied to App Review in the Resolution Center on Aug 1 explaining this. No response yet. We also saw the recent reply from an App Store Commerce Engineer saying the In-App Purchase submission experience was recently updated and an issue affected some submitted IAPs - our timeline matches that window. Could someone from Apple help us either: (a) attach the 7 ready IAPs to the existing submission so everything is reviewed together, or (b) release the app version from the rejected submission so we can create ONE new submission containing the version + all IAPs? We would like to avoid deleting and recreating the subscription group, since the product IDs are already live in our billing stack and on Google Play. Thank you!
0
0
38
5h
iOS 27 terminates a running app while MDM converts it to a managed app
We're working on an iOS app distributed through the App Store and installed on an MDM-enrolled device. Our MDM server uses InstallApplication to take management of the already-installed and running app. On iOS 27 betas 3 and 4, processing this command causes iOS to terminate the app and its extensions with SIGKILL. The same flow and MDM payload work without terminating the app on earlier iOS versions (iOS <=26). Environment OS: iOS 27 betas 3 and 4 Does not happen: iOS 26 or iOS 16.7.15 Device: iPhone SE 2nd Gen Enrollment: MDM-enrolled device Distribution: App Store app App state: Already installed and running when management is requested MDM command: InstallApplication Minimal MDM command The MDM server sends an InstallApplication command for the already-installed app: Attributes = { Removable = false; }; ChangeManagementState = Managed; Identifier = "APP_BUNDLE_ID"; InstallAsManaged = true; ManagementFlags = 1; RequestType = InstallApplication; We also tested the equivalent command using iTunesStoreID = APP_STORE_ID instead of Identifier, and removing InstallAsManaged. The targeted running app was terminated in the same way. Steps to reproduce Install and launch the App Store app as an unmanaged app. Enroll the iPhone in MDM. While the app is running, send the MDM InstallApplication command to take management of the existing installation. Observe the unified logs for mdmd, appstored, manageddeviced, installcoordinationd, and runningboardd. The issue can also be reproduced by initiating the same server-side flow while the app is already in the background. iOS 27 log sequence The command is accepted and appstored starts the managed-app tasks. manageddeviced then attempts to mark the app as managed using a null persona (this differs from iOS <26): The running app has a valid persona. After the failed mapping, installcoordinationd explicitly asks RunningBoard to terminate the app to disassociate that persona: After termination, removing the valid persona also fails. The managed-app task later reports success despite the mapping failures and termination. Earlier iOS comparison As an example, on iOS 16.7.15, using the same MDM command, **iOS routes the request through dmd with persona: default. The app remains alive and receives managed-app change notifications. Expected The existing installation becomes managed without terminating the running app, consistent with the behavior on earlier iOS versions. Actual manageddeviced tries to associate the app with persona (null) and fails with MIInstallerErrorDomain Code 191. That failure causes installcoordinationd to request termination of the app and its extensions to disassociate their valid persona. runningboardd terminates them with SIGKILL (isUserKill=0). The subsequent removal of the only valid persona fails with Code 242, although the managed-app task later reports success. Documentation checked The payload follows the documented InstallApplication flow for taking management of an existing app: Apple Docs WWDC26 app MDM updates We have not found a malformed field that explains the iOS 27-only failure. More info Detailed logs and additional info can be found on the Feedback report.
1
2
1.6k
5h
App has been "Waiting for Review" for over 7 days
Hello everyone, Our iOS app WSH-P (Apple ID: 6503934660) has been in "Waiting for Review" for more than 7 days. This is an app update submission, and we have not received any review feedback or requests for additional information. The status has remained unchanged since submission. Has anyone experienced similar delays recently? Is there anything we should do, or is this just due to a review backlog? Any advice would be greatly appreciated. Thank you.
0
0
22
5h
Kernel Sandbox/System Policy intermittently denies ALL file access (not just mount syscall) on NFS mounts
I'm seeing a recurring issue on macOS 26.5.2 (build 25F84) where the kernel's Sandbox/System Policy layer intermittently denies file access on NFS mount points from local network servers. Posting here in case anyone recognizes this pattern or has a workaround, and flagging it since I've also filed a Feedback Assistant report (with a live-captured sysdiagnose) for the same issue. WHAT HAPPENS Two independent NFS mounts to two separate, unrelated servers on my LAN start failing simultaneously with "Operation not permitted." The kernel log shows: kernel: (Sandbox) System Policy: mount_nfs(PID) deny(1) file-mount /path/to/mount Critically, it's not limited to the mount syscall - within the same few-second window, System Policy also denies ls, perl, diskutil, and even umount -f on the exact same path, for otherwise unrelated processes. So it looks like a transient, path-scoped kernel decision rather than something specific to NFS or the mount syscall. It self-heals anywhere from seconds to ~30 minutes later, then recurs - documented 30-80+ occurrences/day via a background watchdog script. WHAT I'VE RULED OUT Server-side cause: two independent servers on different hardware fail identically at the same instant. Network issue: checked network logs in the same window, no correlated connectivity event. Third-party kext conflict: kextstat shows zero third-party kexts loaded. syspolicyd database corruption: no "ASP: Validation category" signature present. TCC/Full Disk Access: already granted; the denying layer is kernel Sandbox "System Policy," not TCC. QUESTION Has anyone else run into System Policy denying file-mount/file-read-data/file-unmount on network volume paths intermittently like this? Is there any userland way to inspect or reset whatever internal state drives this decision (I haven't found one - no spctl/tccutil/sysctl lever that touches it)? Happy to share more log excerpts if useful.
Replies
14
Boosts
0
Views
585
Activity
3h
App submission now held up three weeks due to backend issues
For about three weeks now, my Smart Recorder app has been in the "Prepare for Submission" state rather than the "Ready to Submit" state. The result is that I am unable to properly submit the app for review. Can anyone help me resolve the issue so that I can get the update posted?
Replies
0
Boosts
0
Views
23
Activity
3h
Guideline 4.3(b) — where is the line between a Lock Screen utility and a wallpaper app?
I'm building an iPhone app that is primarily an editor: it renders a pixel-accurate Lock Screen preview for the user's specific device model (clock, date, widget row, Dynamic Island), isolates the photo's subject on-device with Vision so it overlaps the clock for the depth effect, measures contrast behind the clock, and generates backgrounds procedurally with Metal. It also ships a small library of original images I create myself. Since June 2026, 4.3(b) names wallpaper apps explicitly. Has anyone shipped something in this space recently? Specifically: Did the presence of any image library push the review toward the wallpaper category, regardless of the tooling? What did your screenshots and subtitle emphasise? Which primary category did you use? Any experience appreciated.
Replies
0
Boosts
0
Views
18
Activity
3h
App removed from sale after 5.6 rejection – resubmitted 11+ days ago, still "Waiting for Review"
Hello, Our app was removed from sale following a Guideline 5.6 (Developer Code of Conduct) notice on July 22, 2026, citing concerns about "hidden functionality". We responded in detail explaining our multi-tenant, role-based architecture and provided full Review account access with no restrictions. We submitted a corrected build (version 1.1) on July 24, 2026, which has now been in "Waiting for Review" for 11+ days with no update, rejection, or further communication. App Name: Stay Easie Apple ID: 6784701866 Current version: 1.1 Submitted: July 24, 2026 Guideline referenced: 5.6.0 Developer Code of Conduct We have already: Submitted an expedited review request Called Apple Developer Support multiple times Provided complete role-based review credentials and detailed clarifications The app is currently unavailable on the App Store and this is directly impacting our client's business operations. Could someone from the app review team please take a look at this case? Happy to Provide any additional information needed. Thank you.
Replies
1
Boosts
0
Views
29
Activity
3h
Generation Error
So I'm having an issue with the FoundationModels framework but idk if this is just my feeling or not, the issue comes up after I updated my Mac into 26.6 the code was very simple actually: #Playground { let model = SystemLanguageModel.default let session = LanguageModelSession(model: model) print(model.availability) var query = "How to hide button" Task { do { let response = try await session.respond(to: query) print(response.content) } catch { print("\(error)") } } } the code works before I updated the version, but then after I updated the version it says: Error Domain=FoundationModels.LanguageModelSession.GenerationError Code=-1 "The operation couldn’t be completed. (FoundationModels.LanguageModelError error -1.)" UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=FoundationModels.LanguageModelError Code=-1 "(null)" UserInfo={NSMultipleUnderlyingErrorsKey=(\n "Error Domain=ModelManagerServices.ModelManagerError Code=1026 \"(null)\" UserInfo={NSMultipleUnderlyingErrorsKey=(\n)}"\n)}" ), NSLocalizedDescription=The operation couldn’t be completed. (FoundationModels.LanguageModelError error -1.)} this is runned in Xcode 26.6, additional information I have also coder 27 beta 4 installed in my Mac, is this problem occurring because the Xcode 26.6 and Xcode 27 beta 4?? can u guys help me
Replies
1
Boosts
0
Views
448
Activity
3h
Pinch gesture not recognized on MTKView when attaching it to a RealityView using a ViewAttachmentComponent in a immersive space
Hello! We are seeing a problem with a SwiftUI view that wraps an MTKView and that MTKView uses gesture recognizers from UIKit. One of those gestures we are using is UIPinchGestureRecognizer. And that gesture isn’t recognized at all when the SwiftUI view is attached to a RealityView using the ViewAttachmentComponent AND the RealityView is being shown in an ImmersiveSpace. If the SwiftUI view is attached to the RealityView using the init that has an attachment closure then pinching works fine there. So this definitely seems like a bug. Here is some code to help you reproduce the problem. Run this on a Vision Pro device. A simple red square will be rendered and if a single tap or pinch gesture is recognized on the red square, it will print to the console. App Code: import SwiftUI @main struct VisionPinchProblemsApp: App { var body: some Scene { WindowGroup { MenuView() } ImmersiveSpace(id: "RedSquare") { RedSquareView() } } } View code: import MetalKit import RealityKit import SwiftUI import UIKit struct MenuView: View { @Environment(\.openImmersiveSpace) private var openImmersiveSpace @Environment(\.dismissImmersiveSpace) private var dismissImmersiveSpace @State private var showImmersiveSpace = false @State private var immersiveSpaceIsOpen = false var body: some View { Form { Toggle("Show red square", isOn: $showImmersiveSpace) .task(id: showImmersiveSpace) { if showImmersiveSpace { await openImmersiveSpace(id: "RedSquare") immersiveSpaceIsOpen = true } else { if immersiveSpaceIsOpen { await dismissImmersiveSpace() immersiveSpaceIsOpen = false } } } } .onDisappear { // Attempt to close the immersive space on the way out. Task { if immersiveSpaceIsOpen { await dismissImmersiveSpace() } } } } } struct RedSquareView: View { let metalViewAttachmentID = "metalID" var body: some View { // Adds SwiftUI view using attachments closure. // Pinching and single taps are recognized here! // RealityView { content, attachments in // if let metalViewEntity = attachments.entity(for: metalViewAttachmentID) { // metalViewEntity.position = [0, 1, -1.25] // content.add(metalViewEntity) // } // } placeholder: { // ProgressView() // } attachments: { // Attachment(id: metalViewAttachmentID) { // MetalView() // } // } // Add SwiftUI view using ViewAttachmentComponent. // Pinching is not recognized here! // Single tapping is recognized ! // Why doesn't the red square show up in the Vision Pro simulator? RealityView { content in let metalViewEntity = Entity() let metalView = MetalView() .frame(width: 500, height: 500) let component = ViewAttachmentComponent(rootView: metalView) metalViewEntity.components.set(component) metalViewEntity.position = [0, 1, -1.25] content.add(metalViewEntity) } placeholder: { ProgressView() } } } struct MetalView: UIViewRepresentable { var device: MTLDevice? init() { self.device = MTLCreateSystemDefaultDevice() } func makeUIView(context: Context) -> MTKView { let mtkView = MTKView() mtkView.device = device mtkView.clearColor = MTLClearColor(red: 1.0, green: 0.0, blue: 0.0, alpha: 1.0) mtkView.delegate = context.coordinator let pinchGesture = UIPinchGestureRecognizer(target: context.coordinator, action: #selector(context.coordinator.handlePinch(_:))) mtkView.addGestureRecognizer(pinchGesture) let tapGesture = UITapGestureRecognizer(target: context.coordinator, action: #selector(context.coordinator.handleTap(_:))) mtkView.addGestureRecognizer(tapGesture) return mtkView } func updateUIView(_ uiView: MTKView, context: Context) { } func makeCoordinator() -> Coordinator { Coordinator(self) } class Coordinator: NSObject, MTKViewDelegate { var parent: MetalView init(_ parent: MetalView) { self.parent = parent } func mtkView(_ view: MTKView, drawableSizeWillChange size: CGSize) { } func draw(in view: MTKView) { guard let drawable = view.currentDrawable else { return } guard let descriptor = view.currentRenderPassDescriptor else { return } let commandQueue = parent.device?.makeCommandQueue() let commandBuffer = commandQueue?.makeCommandBuffer() let renderEncoder = commandBuffer?.makeRenderCommandEncoder(descriptor: descriptor) renderEncoder?.endEncoding() commandBuffer?.present(drawable) commandBuffer?.commit() } @objc func handlePinch(_ sender: UIPinchGestureRecognizer) { print("Pinch detected") } @objc func handleTap(_ sender: UITapGestureRecognizer) { print("Tap detected") } } }
Replies
1
Boosts
0
Views
17
Activity
3h
App Review 1+ week
Hello, I’m posting here because I’m experiencing a very unusual issue with the App Store review process and haven’t been able to resolve it through normal support channels. Our app has been waiting in App Review for over 1 week, which is far beyond the normal review timeframe. During this period, I contacted Apple Developer Support multiple times and even submitted an expedited review request, but the situation has not progressed. Some of my inquiries have unfortunately received no response, and the app remains stuck in review without any explanation. I fully understand that review times can vary, but a 1+ week delay without any status update or communication seems highly abnormal. If any Apple staff or experienced developers have encountered a similar situation, I would greatly appreciate any guidance on how to resolve this or escalate it properly. Thank you for any help or advice.
Replies
1
Boosts
1
Views
44
Activity
3h
App Still "Waiting for Review" Since July 22 – Anyone Else Experiencing Long Delays?
Hi everyone, I'm wondering if anyone else is experiencing unusually long App Review delays. My app has been in "Waiting for Review" since July 22 at 11:04 PM, and it still hasn't entered the review process. As of today, it's been nearly two weeks with no review activity. I understand that review times can vary depending on workload, app category, and other factors, but this is significantly longer than what I've experienced before. Has anyone else recently faced similar delays? How long did your app remain in "Waiting for Review"? Did it eventually get reviewed without taking any action? Did contacting Apple Developer Support help in your case? I'm mainly trying to understand whether this is a broader issue affecting other developers or if I should reach out to Apple Support. Thanks in advance for sharing your experience.
Replies
2
Boosts
1
Views
45
Activity
3h
App Stuck in Waiting for Review - 10 Days
Hello! I submitted my app for first time review on July 24th around 12pm EST and have not yet heard anything or seen any updates in App Store Connect. Is there anything I can do to check the status or nudge it forward? I have checked for messages, rejections, or issues to resolve in App Store Connect and can't seem to find any indication of a stall reason. I also submitted a support request on July 30th inquiring about potential delays and haven not yet heard back. ID's added to the bottom of this post. Thank you for your time! App ID: 6791030400 Case #: 20000123752874
Replies
0
Boosts
0
Views
14
Activity
3h
Individual Apple Developer enrollment in India blocked by “Unable to Continue”
I am attempting to enroll in the Apple Developer Program from India through the Apple Developer app. The app immediately displays: “Unable to Continue. Contact support at https://developer.apple.com/contact/.” I cannot proceed to enrollment type selection, identity verification, agreement, or payment. The issue is reproducible on an iPhone 16 Pro Max running iOS 26.5.2 with Apple Developer app 11.0.2. I verified the Apple Account details at account.apple.com, checked the Developer Account website, and confirmed that Apple Developer System Status reports no enrollment incident. The website shows “Join the Apple Developer Program” / “Enroll today,” while the required app flow remains blocked. I have opened a Developer Support case requesting a manual enrollment-state review and have filed Feedback Assistant report FB24014432 with the exact screenshot and reproduction steps. Has Apple Developer Support identified whether this alert normally indicates a stale historical enrollment, an unresolved identity-verification state, an account-information mismatch, or another backend restriction? I am specifically trying to determine the correct official escalation, secure verification, or reset procedure. Please do not suggest web enrollment as a workaround; Apple’s documentation states that enrollment in India must use the Apple Developer app.
Replies
1
Boosts
1
Views
58
Activity
3h
Unable to enroll to apple develeoper account!
I'm trying from many days to enroll in the apple developer account, but I keep getting error again and again. I've tried with 2 different ID's same result. Please help! Unable to Continue Contact support at https://developer.apple.com/contact/.
Replies
0
Boosts
0
Views
9
Activity
3h
ManipulationComponent causes makeUIView(context:) to get called twice
Here I have some demo code that is rendering a cylinder "platter" using RealityKit and there is a red circle rendered on top of it which uses Metal and SwiftUI. When the platter appears you will see in the console that makeUIView(context:) is called twice while it is documented that it will only be called once when the view appears for the first time. So this seems like a bug. If you remove ManipulationComponent from the platter's components you will see that this problem goes away so it seems like that is the cause of the problem. Any insight here would be appreciated! Thank you. Here is what is printed in the console: Entity returned from EntityWrapper.makeEntity(context:) was already parented to another entity. This is not supported and may lead to unexpected behavior. SwiftUI adds entities to internally-managed entity hierarchies. Make UI View! This should be called once. Make UI View! This should be called once. Here is the app code: import SwiftUI @main struct SomeApp: App { var body: some Scene { WindowGroup { ContentView() } ImmersiveSpace(id: "TableTop") { TableTopPlatterView() } } } Here is the view code: import MetalKit import RealityKit import SwiftUI struct ContentView: View { @Environment(\.openImmersiveSpace) private var openImmersiveSpace @Environment(\.dismissImmersiveSpace) private var dismissImmersiveSpace @State private var showImmersiveSpace = false @State private var immersiveSpaceIsOpen = false var body: some View { Form { Toggle("Show table top", isOn: $showImmersiveSpace) .task(id: showImmersiveSpace) { if showImmersiveSpace { await openImmersiveSpace(id: "TableTop") immersiveSpaceIsOpen = true } else { if immersiveSpaceIsOpen { await dismissImmersiveSpace() immersiveSpaceIsOpen = false } } } } .onDisappear { // Attempt to close the immersive space on the way out. Task { if immersiveSpaceIsOpen { await dismissImmersiveSpace() } } } } } struct TableTopPlatterView: View { private var attachmentID: String { "RedCircle" } var body: some View { RealityView { content, attachments in if let redCircleEntity = attachments.entity(for: attachmentID) { // Lays the red circle in the platter. let rotation = Rotation3D(redCircleEntity.orientation) .rotated(by: .init(angle: .degrees(-90), axis: .x)) redCircleEntity.setOrientation(.init(rotation), relativeTo: nil) redCircleEntity.position.y = 0.026 platterEntity.addChild(redCircleEntity) content.add(platterEntity) } } placeholder: { ProgressView() } attachments: { Attachment(id: attachmentID) { MetalView() .clipShape(.circle) } } } /// The platter entity that the red circle lays on top of. private let platterEntity: ModelEntity = { let anchor = AnchorEntity( .plane( .horizontal, classification: .table, minimumBounds: [0.01, 0.01] ) ) let material = SimpleMaterial( color: .lightGray, roughness: 0.5, isMetallic: false ) let platter = ModelEntity( mesh: .generateCylinder(height: 0.05, radius: 0.475), materials: [material] ) platter.generateCollisionShapes(recursive: false) let components: [any Component] = [ InputTargetComponent(), GroundingShadowComponent(castsShadow: true), ManipulationComponent() // MARK: This is causing makeUIView to get called twice! ] platter.components.set(components) // Placed closer to the user when booted up. platter.position = [0, 1, -1.25] anchor.addChild(platter) return platter }() } // Metal view that renders a red square. struct MetalView: UIViewRepresentable { var device: MTLDevice? init() { self.device = MTLCreateSystemDefaultDevice() } func makeUIView(context: Context) -> MTKView { print("Make UI View! This should be called once.") let mtkView = MTKView() mtkView.device = device mtkView.clearColor = MTLClearColor(red: 1.0, green: 0.0, blue: 0.0, alpha: 1.0) mtkView.delegate = context.coordinator return mtkView } func updateUIView(_ uiView: MTKView, context: Context) { } func makeCoordinator() -> Coordinator { Coordinator(self) } class Coordinator: NSObject, MTKViewDelegate { var metalView: MetalView init(_ metalView: MetalView) { self.metalView = metalView } func mtkView(_ view: MTKView, drawableSizeWillChange size: CGSize) { } func draw(in view: MTKView) { guard let drawable = view.currentDrawable else { return } guard let descriptor = view.currentRenderPassDescriptor else { return } let commandQueue = metalView.device?.makeCommandQueue() let commandBuffer = commandQueue?.makeCommandBuffer() let renderEncoder = commandBuffer?.makeRenderCommandEncoder(descriptor: descriptor) renderEncoder?.endEncoding() commandBuffer?.present(drawable) commandBuffer?.commit() } } }
Replies
3
Boosts
0
Views
944
Activity
3h
No response from app reviewer since 7-17 :(
App ID: 6788510203 Case Number: 102948809441 I submitted an app on the middle of July, got my first response from a reviewer on July 16th, and again on the 17th, and have not received a response back since. After a week of not hearing back, I made and submitted a new build just to try and get it "unstuck" since it was no longer getting replies. That was last Monday at 9am. It's been 17 days now since I've last received a response. Is this common, or is my app stuck in some extended review state or something? Since my last build, it is still "waiting in review" so it seems like it's just not getting assigned to someone?
Replies
0
Boosts
0
Views
28
Activity
4h
Add two new appearance options for Control Center: More Tinted and More Glass.
Please add two appearance modes for Control Center: More Tinted: Stronger color tint with a vibrant look. More Glass: Increased transparency and a more pronounced Liquid Glass effect. This would give users more control over the visual style of Control Center while keeping the default appearance unchanged.
Replies
0
Boosts
0
Views
17
Activity
4h
Supported way to pre-approve kTCCServiceBluetoothAlways via MDM on macOS 27 (Golden Gate)
We develop a third-party endpoint security agent (DLP / device control). It needs kTCCServiceBluetoothAlways to enumerate paired Bluetooth devices and disconnect them selectively based on policy — without user interaction, since this runs unattended on managed fleets. Until recently we granted this silently via a com.apple.TCC.configuration-profile-policy (PPPC) profile pushed by MDM, or by writing directly to the TCC database — the latter no longer possible starting with macOS 27 (Golden Gate). As of macOS 27, tccd also ignores the PPPC profile approach: Override: skipping kTCCServiceBluetoothAlways ... as it is defined in deprecated PPPC profile As a result, end users now hit the standard Bluetooth access consent popup, which we have no way to suppress or pre-answer with Allow. ** Questions: ** Is there any currently supported MDM mechanism — profile-based, DDM, or otherwise — to pre-approve kTCCServiceBluetoothAlways for a specific managed app, so the popup never appears? If direct pre-approval is gone for good, is there any supported way to auto-answer the popup on the user’s behalf via policy (as exists for some other TCC services)? Is this now permanently interactive by design, or is a replacement mechanism planned for MDM-managed Bluetooth access?
Replies
0
Boosts
0
Views
11
Activity
4h
How’s everyone’s OS27 SiriAI dev experience going so far?
Anyone able to get some neat SiriAI experiences working? Anything that makes you think “man I hope other developers do this in their apps too!”? (I’m willing!)
Replies
0
Boosts
0
Views
11
Activity
4h
Rejected 3x under 2.1(b): cannot submit app version and In-App Purchases in the SAME review submission
Our app BandPro (Apple ID 6793207475) has been rejected three times under Guideline 2.1(b) because the In-App Purchase products were "not submitted for review". Everything is ready on our side, but App Store Connect will not let us put the app version and the IAPs into the SAME review submission: New binary uploaded: iOS 1.0 (build 22), attached to the version. 7 IAPs in "Ready to Submit": 4 auto-renewable subscriptions in the group "BandPro Pro" + 3 consumables. All have prices, availability in 175 storefronts, review screenshots and review notes. The app version is locked inside the REJECTED submission ("Unresolved Issues"). The only action available there is "Resubmit to App Review", which sends the version ALONE - exactly what caused the 2nd and 3rd rejections. Adding the IAPs for review creates a SEPARATE draft submission. That draft cannot be sent: it shows "To submit your items for review, add an app version for the selected platform" - but the version cannot be added because it is held by the rejected submission. We replied to App Review in the Resolution Center on Aug 1 explaining this. No response yet. We also saw the recent reply from an App Store Commerce Engineer saying the In-App Purchase submission experience was recently updated and an issue affected some submitted IAPs - our timeline matches that window. Could someone from Apple help us either: (a) attach the 7 ready IAPs to the existing submission so everything is reviewed together, or (b) release the app version from the rejected submission so we can create ONE new submission containing the version + all IAPs? We would like to avoid deleting and recreating the subscription group, since the product IDs are already live in our billing stack and on Google Play. Thank you!
Replies
0
Boosts
0
Views
38
Activity
5h
iOS 27 terminates a running app while MDM converts it to a managed app
We're working on an iOS app distributed through the App Store and installed on an MDM-enrolled device. Our MDM server uses InstallApplication to take management of the already-installed and running app. On iOS 27 betas 3 and 4, processing this command causes iOS to terminate the app and its extensions with SIGKILL. The same flow and MDM payload work without terminating the app on earlier iOS versions (iOS <=26). Environment OS: iOS 27 betas 3 and 4 Does not happen: iOS 26 or iOS 16.7.15 Device: iPhone SE 2nd Gen Enrollment: MDM-enrolled device Distribution: App Store app App state: Already installed and running when management is requested MDM command: InstallApplication Minimal MDM command The MDM server sends an InstallApplication command for the already-installed app: Attributes = { Removable = false; }; ChangeManagementState = Managed; Identifier = "APP_BUNDLE_ID"; InstallAsManaged = true; ManagementFlags = 1; RequestType = InstallApplication; We also tested the equivalent command using iTunesStoreID = APP_STORE_ID instead of Identifier, and removing InstallAsManaged. The targeted running app was terminated in the same way. Steps to reproduce Install and launch the App Store app as an unmanaged app. Enroll the iPhone in MDM. While the app is running, send the MDM InstallApplication command to take management of the existing installation. Observe the unified logs for mdmd, appstored, manageddeviced, installcoordinationd, and runningboardd. The issue can also be reproduced by initiating the same server-side flow while the app is already in the background. iOS 27 log sequence The command is accepted and appstored starts the managed-app tasks. manageddeviced then attempts to mark the app as managed using a null persona (this differs from iOS <26): The running app has a valid persona. After the failed mapping, installcoordinationd explicitly asks RunningBoard to terminate the app to disassociate that persona: After termination, removing the valid persona also fails. The managed-app task later reports success despite the mapping failures and termination. Earlier iOS comparison As an example, on iOS 16.7.15, using the same MDM command, **iOS routes the request through dmd with persona: default. The app remains alive and receives managed-app change notifications. Expected The existing installation becomes managed without terminating the running app, consistent with the behavior on earlier iOS versions. Actual manageddeviced tries to associate the app with persona (null) and fails with MIInstallerErrorDomain Code 191. That failure causes installcoordinationd to request termination of the app and its extensions to disassociate their valid persona. runningboardd terminates them with SIGKILL (isUserKill=0). The subsequent removal of the only valid persona fails with Code 242, although the managed-app task later reports success. Documentation checked The payload follows the documented InstallApplication flow for taking management of an existing app: Apple Docs WWDC26 app MDM updates We have not found a malformed field that explains the iOS 27-only failure. More info Detailed logs and additional info can be found on the Feedback report.
Replies
1
Boosts
2
Views
1.6k
Activity
5h
App has been "Waiting for Review" for over 7 days
Hello everyone, Our iOS app WSH-P (Apple ID: 6503934660) has been in "Waiting for Review" for more than 7 days. This is an app update submission, and we have not received any review feedback or requests for additional information. The status has remained unchanged since submission. Has anyone experienced similar delays recently? Is there anything we should do, or is this just due to a review backlog? Any advice would be greatly appreciated. Thank you.
Replies
0
Boosts
0
Views
22
Activity
5h
Is there a way to know when widget is installed/uninstalled?
Hello, For tracking purpose, is there a way to know when a widget is installed/uninstalled? Also, would it be possible to check which size widget was installed?
Replies
10
Boosts
1
Views
6.5k
Activity
5h