Overview

Post

Replies

Boosts

Views

Activity

TestFlight blocked account-wide since 19 Oct: all builds expired at once, BETA_CONTRACT_MISSING on new builds
Since 19 Oct 2026, TestFlight is blocked for my whole team, not for a single app. Account Team ID: 95MF867832 (individual account, I am the Account Holder) Apps: 6819072253 and 6748716751 What happened On 19 Oct 2026 at 06:13 PDT every TestFlight build on the team expired at the same second, including builds that still had weeks left. A new build uploaded on 20 Oct is VALID (expires Jan 2027), but submitting it to Beta App Review fails: App Store Connect web: "There was an error processing your request. Please try again later." API POST /v1/betaAppReviewSubmissions: 422 ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING ("Beta contract is missing for the app"). Internal testers cannot install either: "The requested app is not available or doesn't exist". Retried hourly through 23 Oct: still 422. Already checked All agreements are Active, nothing pending. The Paid Apps Agreement was activated on 13 Oct 2026. A fresh build did not help. App Store review submission itself works (an App Store version was submitted on 23 Oct); only TestFlight is affected. Reported Feedback Assistant: FB25290077 Developer Support case: 103005423668 Other developers report the same error in thread 813703, which suggests a backend issue with the TestFlight beta contract after an agreement change. Could someone from Apple please route this to the TestFlight team to re-attach the beta contract? Thank you.
1
0
25
22h
System-wide Core Location failure on macOS 27.0.1: Wi-Fi positioning knownCount=0, incorrect time zone, same failure on Wi-Fi-only iPad
I am experiencing a system-wide Location Services failure on my MacBook running macOS 27.0.1. Several days after the problem first appeared on the Mac, my iPad Pro (Wi-Fi-only model) developed a very similar issue. Both devices are in Ukraine and should use the Europe/Kyiv time zone. The Mac unexpectedly selected Cupertino, PDT, while the iPad selected a Chinese time zone. Location detection is now failing in Apple Maps, Weather, browsers, and other applications using Core Location. My iPhone continues to determine its location correctly. The macOS locationd diagnostic logs show that Wi-Fi access points are being discovered but none are recognized as known references in the observed positioning check. Steps to reproduce Connect the affected Mac to a working Wi-Fi network with internet access. Ensure Location Services are enabled. Open Apple Maps and request the current location. Attempt browser-based geolocation using a website that requests the current location. Open System Settings → General → Date & Time and enable automatic time-zone detection. Observe the inability to determine the correct location and the incorrect automatic time-zone selection. The failure persists across multiple Wi-Fi networks, including an iPhone Personal Hotspot. Expected result Core Location should correctly determine the approximate physical location in Ukraine using available positioning information. Apple Maps, Weather, browsers, and other applications should receive valid location data. Automatic time-zone detection should select Europe/Kyiv. Actual result Apple Maps cannot correctly determine the current location. Browser geolocation fails. Weather displays incorrect location-dependent information. Automatic time-zone detection selected Cupertino (PDT) on the Mac instead of Europe/Kyiv. The Wi-Fi-only iPad Pro independently selected a Chinese time zone instead of Europe/Kyiv. Automatic location detection remains unusable across applications. The problem persists after connecting to different Wi-Fi networks. The Mac problem began suddenly during normal use. Around that time, the system automatically transitioned to dark appearance for the evening (as expected), but the automatic time zone also changed unexpectedly. The iPad developed similar symptoms several days later. Troubleshooting already performed Tested multiple Wi-Fi networks. Tested internet access through an iPhone Personal Hotspot. Checked IP-based geolocation using external services; these correctly identify the geographic region. Considered VPN-related causes; the behavior is not explained by the IP geolocation results. Confirmed that Location Services work correctly on my iPhone. The simultaneous involvement of two independent devices, combined with normal iPhone positioning, suggests a possible failure in Wi-Fi-based positioning or the associated system services rather than an isolated hardware issue. Technical diagnostics On October 22, 2026, the following message was obtained from the macOS locationd unified log: 2026-10-22 22:31:00.638 Df locationd[387:2755b6] [com.apple.locationd.Position:GeneralCLX] WifiAps, querycheck, knownCount, 0, unknownCount, 17, knownCountTile, 0, knownToUnknownRatio, 0.0, queryMacAddresses.size, 34, sinceLastServerQuery, 187.15, isQueryNeeded, 1, forceQuery, 0, queryType, 0, reqType, 0 Important diagnostic fields: knownCount = 0 unknownCount = 17 knownCountTile = 0 knownToUnknownRatio = 0.0 queryMacAddresses.size = 34 isQueryNeeded = 1 These values indicate that the positioning subsystem is discovering Wi-Fi access points but has no recognized positioning references in this particular check. This resembles a previously reported Core Location / GeoServices failure. Potentially related existing reports Apple Developer Forums: https://developer.apple.com/forums/thread/835896 The discussion documents a similar system-wide location failure with knownCount = 0 despite successful Wi-Fi scanning. Feedback IDs submitted by another affected user: FB23196632 FB23366087 There are also independent reports from Ukrainian users whose Macs incorrectly determine their location or time zone as China: https://www.reddit.com/r/MacOS/comments/1nt0lli/location_glitch/ These reports may involve the same underlying issue, but a common root cause has not been confirmed. Request for investigation Please investigate whether this issue is related to: Apple's Wi-Fi positioning database or lookup service. Core Location / GeoServices processing of Wi-Fi-based location results. Incorrect, missing, or stale Wi-Fi access-point location records. Local positioning cache or Wi-Fi regulatory-domain problems. I would particularly appreciate investigation of the knownCount = 0 condition and whether it can explain the incorrect time-zone selection on two separate devices. Please route this report to the appropriate macOS Core Location / GeoServices engineering team. I can provide additional diagnostic logs and sysdiagnose data if required.
1
0
566
22h
DSA trader status stuck "In Review" since 13 October – app unavailable in its only market
My trader information under the EU Digital Services Act has been "In Review" since 13 October 2026. Since then my app has not been available in Germany, which is its only storefront. Pricing and Availability shows "Trader contact information missing". In App Store Connect I cannot edit, resubmit or view any details. What I have tried: Developer Support on 16 October 2026 (Distribution > Other Distribution Questions): no reply yet (case ID: 102998226596) Developer Support on 21 October 2026 (Reports and Payments > Paid Agreement Setup) Checked my inbox, including spam: no request for documents or verification codes App: Bowlification, Apple ID 6814083192 This looks like the same issue as https://developer.apple.com/forums/thread/848065. Is there anything I can do on my side, or could someone from the App Store Connect team take a look? Thank you.
4
0
158
22h
Apple, how are developers supposed to launch their apps when DSA verification is stuck with no response?
I’m an independent developer preparing to launch my first app in the European Union. My DSA trader verification is still pending, and the process has become a major obstacle to launching my business. I’ve already contacted Apple Developer Support twice by email. No response. No explanation. No timeline. After looking through these forums, I’ve discovered that I’m far from alone. Other developers have reported similar issues, some waiting for months without a resolution. Apple, this is a serious problem. Independent developers invest months of work, money, and energy into building products for your ecosystem. Yet a mandatory administrative verification can leave their entire launch on hold, with no visibility and seemingly no way to move forward. We understand the importance of complying with the EU Digital Services Act. That’s not the issue. The issue is being required to complete a process that appears to offer no reliable way to get help when something goes wrong. I’m not asking for special treatment. I’m asking for basic transparency and accountability. Could someone from Apple please address the following? Is Apple aware of the recurring delays affecting DSA trader verification? Is there a dedicated team or escalation process for developers whose verification is stuck? What are developers supposed to do when multiple support requests go unanswered? If other developers are experiencing the same issue, please share your experience and how long you’ve been waiting. Apple, we want to comply with your requirements. We just need a process that actually works.
0
0
18
22h
Automated price-confirmation message (3.0.0 Business: Preamble) answered, nearly 5 days with no response. Has anyone seen this clear?
App Review's automated message (3.0.0 Business: Preamble) arrived on 1 October at 10:14 AM CDT. It asked us to confirm the price of a non-consumable in-app purchase. We confirmed the price in the same thread at 10:21 AM CDT, and wrote again on 5 October at 10:00 AM CDT. As of 6 October it has been nearly 5 days since our answer, with no reply in the thread. Developer Support (case 102978876606) estimated 48 hours on 1 October. The submission still shows "Unresolved Issues" and the app version shows "Rejected". What we have already done: replied in the thread; confirmed the price in writing; left the build and all four in-app purchase items unchanged and "Ready for Review"; opened the Developer Support case above. Two questions: Has anyone gone through this exact message, and how did it end (a reply, a status change, a resubmission)? How long did it take? Are we missing a step besides replying to the question, such as resubmitting, or changing something on the in-app purchase page? App ID 6808337831. Thank you.
1
0
127
22h
15 Days Waiting for App Review – Apple, This Is Unacceptable for Paying Developers
I'm writing this post to express my serious frustration and disappointment with Apple's App Review process. We submitted our app, Virtual Pro Association, on September 28, 2026. Today is October 13, and after 15 days, our app is still not approved. Here is the timeline: September 28: Initial submission. October 6: Apple finally started reviewing our app after approximately 8 days. October 6: The app was rejected. We fixed the reported issues and resubmitted it within approximately one hour. October 13: Seven more days have passed, and our app is still stuck in "Waiting for Review." We even requested an expedited review, which Apple accepted. Apple explicitly stated that if our submission was rejected, the corrected version would automatically return to the expedited review queue. So what exactly does "expedited" mean if we are still waiting after all this time? We have contacted Apple Developer Support multiple times, but all we receive are generic responses telling us to wait, without any meaningful explanation or estimated timeline. This is not acceptable. Behind every application, there are real people working hard. Developers, designers, administrators, and entire teams invest countless hours building, testing, and preparing their products for launch. We have responsibilities, deadlines, communities waiting for our services, and projects that depend on these releases. Apple cannot simply leave developers waiting indefinitely without transparency or accountability. We pay an annual fee to participate in the Apple Developer Program. We understand that app reviews are necessary for security and quality, and we fully support that process. But paying developers should reasonably expect an efficient review service, clear communication, and predictable procedures. If Apple's App Review team cannot handle the current volume of submissions, Apple should invest in hiring more reviewers and improving its review infrastructure. Developers should not have to repeatedly contact support, request expedited reviews, and post on forums just to find out why their applications are sitting in a queue for weeks. We are not asking Apple to approve applications without reviewing them. We are asking Apple to review them within a reasonable timeframe. Our app has been tested extensively, the reported issues were corrected immediately, and we have done everything requested of us. Yet we are still waiting. 15 days. An approved expedited review request. A corrected submission. No meaningful progress. Apple, developers deserve better. We need transparency, accountability, and a review process that respects the time and work of the people who build applications for your ecosystem. How many other developers are experiencing the same situation right now?
21
17
1k
22h
Mac Catalyst: outgoing CallKit call opens FaceTime and turns on the camera
We're bringing our CallKit-based VoIP app to the Mac with Mac Catalyst. Incoming calls work fine. For outgoing calls we request a CXStartCallAction (audio only, isVideo = false), the provider fulfills it and the call connects. But at the moment the call starts dialing, macOS launches FaceTime.app, which turns on the camera preview and shows its own call screen for our call ("no video"). When the call ends, FaceTime stays open and the camera stays on until FaceTime is quit manually. The system log shows callservicesd deciding to launch the in-call application for our call: callservicesd _shouldLaunchInCallApplicationForCall: 1 callservicesd Opening URL: <private> for call <private> CoreServicesUIAgent LAUNCH: ... com.apple.FaceTime starting stopped process.Reported as FB25284357 (macOS 27.0.1, Xcode 27.1). Is this expected for third-party CallKit providers on macOS? Is there a supported way to keep the call in our own app without dropping CallKit for outgoing calls?
1
0
43
22h
macOS /etc/ssl/cert.pem still trusts the eMudhra roots: curl and python3 accept the compromised intermediates
Apple blocked the eight compromised eMudhra intermediate CAs (CVE-2026-111943) for Security.framework clients. But on macOS 27.0.1 (26A434), /usr/bin/curl and /usr/bin/python3 still accept certificates from them. These tools verify against /etc/ssl/cert.pem and do not check revocation. The file (dated Sep 24) still contains both roots that the compromised intermediates chain to: emSign ECC Root CA - G3 AAA Certificate Services To reproduce, with SSL_CERT_FILE and CURL_CA_BUNDLE not set: /usr/bin/curl -sS -o /dev/null -w '%{exitcode}\n' https://dv-g3b-emudhra.we-have-a-problem.com/ # 0 — the connection succeeds grep -E 'emSign ECC Root CA - G3|AAA Certificate Services' /etc/ssl/cert.pem # both roots are presentWith a CA bundle that does not have these roots (Homebrew ca-certificates), the same command fails with "unable to get local issuer certificate". So the system bundle is the cause. softwareupdate -l shows no update. Questions: Does Apple plan to update /etc/ssl/cert.pem for this, and will the security notes say so? Until then, is setting SSL_CERT_FILE to a separate bundle the recommended workaround for the system tools?
0
0
23
22h
App Review Pending for More Than 48 Hours – Backed: Warranty & Claim Kit
Hello Apple Developer Community, I submitted my iOS app, Backed: Warranty & Claim Kit, for App Review and received Apple's confirmation email stating that the app had been received for review. The email mentions that over 90% of apps are reviewed within 48 hours. However, it has now been more than 48 hours, and my app's status is still showing “Waiting for Review” in App Store Connect. I understand that review times can vary depending on several factors, but I would appreciate some guidance from developers who have experienced a similar delay. Has anyone recently experienced a review delay beyond 48 hours? Is it normal for an app to remain in “Waiting for Review” status for several days? At what point should I contact Apple Developer Support? App details: App name: Backed: Warranty & Claim Kit Platform: iOS Current status: Waiting for Review Time elapsed: More than 48 hours I would appreciate any advice or insights from developers who have experienced this situation. Thank you!
0
0
22
22h
Separate CGBitmapContexts drawn concurrently produce wrong pixels when another thread fills translucent shapes (FB25211753)
Hi, my first post :-) feel free to say hi! I’ve filed this as FB25211753 and am posting in case others hit it. When several threads each draw into their own CGBitmapContext (separate buffers, separate contexts), one context’s output is corrupted if another thread is filling translucent shapes at the same time. QA1238 says drawing to separate Quartz objects on separate threads is supported. With only identical renders running concurrently, 0 of 64 differ from a serial reference. With another thread filling translucent ellipses into an unrelated context, 32 of 32 differ. On macOS 27.0.1, each corrupted render has about 0.3–4.6% of its bytes wrong, by up to 219 of 255 levels. On 26.5.1 it was smaller: 0.2–0.5%, up to 55. It’s triggered by translucent ellipses or paths. Opaque fills and translucent rectangles don’t trigger it, and per-thread colour spaces don’t help. Thread Sanitizer reports no race in the test code. Configuration: MacBook Pro (M4 Pro), macOS 26.5.1 and 27.0.1, Xcode 26.4 / Swift 6.3. Minimal reproduction (Core Graphics only). Run with swiftc -O repro.swift -o repro && ./repro: // Separate CGBitmapContexts drawn on separate threads give wrong pixels while another thread fills translucent // shapes. Seen on macOS 26.5.1 and 27.0.1 (Apple M4 Pro). Core Graphics only. // Run: swiftc -O repro.swift -o repro && ./repro // Minimal repro: separate CGBitmapContexts on separate threads, Core Graphics only. import CoreGraphics import Foundation let sRGB = CGColorSpace(name: CGColorSpace.sRGB)! /// A fixed drawing: black, a few large translucent ellipses and a stroked circle. func victim() -> [UInt8] { let w = 600, h = 400 let ctx = CGContext(data: nil, width: w, height: h, bitsPerComponent: 8, bytesPerRow: w * 4, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! ctx.setFillColor(CGColor(srgbRed: 0, green: 0, blue: 0, alpha: 1)) ctx.fill(CGRect(x: 0, y: 0, width: w, height: h)) for i in 0..<6 { ctx.setFillColor(CGColor(srgbRed: 1, green: Double(i) / 6, blue: 0.3, alpha: 0.5)) ctx.fillEllipse(in: CGRect(x: 40 + i * 80, y: 100, width: 120, height: 120)) } ctx.setStrokeColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: 0.3)) ctx.strokeEllipse(in: CGRect(x: 100, y: 50, width: 400, height: 300)) let p = ctx.data!.assumingMemoryBound(to: UInt8.self) return Array(UnsafeBufferPointer(start: p, count: w * h * 4)) // read the context's own memory: no image decoding } /// Unrelated work on another context: many tiny translucent ellipses. func aggressor() { let ctx = CGContext(data: nil, width: 800, height: 500, bitsPerComponent: 8, bytesPerRow: 0, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! for k in 0..<1600 { ctx.setFillColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: Double(k % 7) / 7)) ctx.fillEllipse(in: CGRect(x: k % 800, y: k % 500, width: 1, height: 1)) } } let reference = victim() for mode in ["victims only", "victims + aggressors"] { let lock = NSLock() nonisolated(unsafe) var bad = 0, compared = 0 DispatchQueue.concurrentPerform(iterations: 64) { i in if mode != "victims only", i % 2 == 1 { aggressor(); return } let same = victim() == reference lock.lock(); compared += 1; if !same { bad += 1 }; lock.unlock() } print("\(mode): \(bad) of \(compared) renders differ from the serial reference") } Has anyone else seen this, or found a workaround other than drawing on a single thread?
4
0
1.6k
22h
First app stuck in Waiting for Review since October 13, expedite approved
Hello, Our first app, Gaft (Apple ID 6798040496), version 1.0, was submitted for review on October 13, 2026 together with its first in-app purchases (two auto-renewable subscriptions and one consumable). It is still in Waiting for Review. An expedited review was approved on October 19, and we contacted Developer Support on October 20 (case 103002520980), but there is no reply and no change in status yet. Is anything needed from our side? Thank you for your help.
0
0
19
22h
Unexpected iPad and Apple Watch screenshot tabs appearing in App Store Connect
When submitting a new version of our iOS app in 1st Oct, we noticed that iPad and Apple Watch tabs appeared in the “Previews and Screenshots” section alongside the iPhone tab. These tabs did not appear during our previous version submissions. Our app is intended for iPhone, and we do not need iPad or Apple Watch screenshot sections. We have not intentionally added support for these devices, and our submission process has remained the same. Here is a screenshot showing the tabs meanwhile our build metadata only support iphone in device family We would appreciate clarification on three points: 1. Why did this happen? Is it caused by a change in App Store Connect, something in our uploaded build, or another setting? 2. What impact does this have when submitting an app? If we submit with these tabs present but leave their screenshot sections empty, could this affect approval, supported-device listings, or distribution? 3. How can we prevent this in future submissions? Are there specific project or App Store Connect settings we should check or change?
3
0
96
22h
Aquadoku resubmission in "Waiting for Review" for 10 days after replying to a 2.1(b) request
Hello, Our app Aquadoku (Apple ID 6809423307, iOS 1.0) has been in "Waiting for Review" since October 12, 2026 (PT), with no status change for 10 days. On October 12 the submission was rejected under Guideline 2.1(b), asking where to find our in-app purchases. I replied in App Store Connect with step-by-step directions and a screen recording from a device. The in-app purchases had dropped out of the submission, so I added all three (Remove All Ads, Reveal ×10, Scan ×10) back to version 1.0 and resubmitted the same day. An expedited review was accepted for this app on October 10, and the confirmation said a resubmission after rejection would return to the expedite queue automatically. Agreements, banking and tax information are active, and there are no new messages from App Review. The Android version has been live since September 28, and iOS players are still waiting. Could someone from App Review please check whether anything is blocking this submission? Earlier thread: https://developer.apple.com/forums/thread/850351 Thank you.
0
0
9
22h
4.3(b) appeal filed Oct 9, no reply: how is "meaningfully different" judged?
I am asking two things: whether the App Review Board has my appeal, and how one sentence in the decision should be read against the guideline. I am not asking for an exception. I will follow the Board's decision. App: BeetMeet (Korea only, 19+), Apple ID 6819720059. Rejected Oct 8, 2026 under 4.3(a) and 4.3(b). I replied in App Store Connect the same day and filed an appeal through the App Review Board form on Oct 9. The form showed no case number, so I have no way to check its status except to ask here. No reply as of Oct 23. 4.3(a) is resolved. It came from an earlier record of the same app that still had a storefront. I removed every storefront from that record on Oct 8 and will not resubmit it. 4.3(b) is the question. The guideline says dating apps "are well established on the App Store and we will not accept new submissions unless they offer a meaningfully different or improved experience." The decision says the app "may include features or characteristics that distinguish it. However, there are already enough of these apps on the App Store." Read side by side, the decision allows that the app may be distinguishable and then declines on the size of the category. The guideline makes the category's size the reason for the test, not its result. If I am reading this wrong, I would like to know how it should be read, so that I can act on the actual standard instead of guessing at it. What I asked App Review to evaluate, in the demo account listed in App Review Information, takes about five minutes: a. Home > "Another me" > Report. The user's own model, built from a 91-item assessment and 13 guided conversations. Matching cannot start before this model exists. b. Situation cards. The user answers 10 relationship situations first, then grades how their own model answered each one. c. Match card. At most one person, shown only when 1,000 simulated encounters and seven staged conversations score 90% or higher. The full simulated conversation and an eleven-axis score breakdown are one tap away. If no one reaches 90%, the screen says so. There is no browsing, feed, swipe, or list anywhere in the app. d. Chat. Seven days, photos blurred until the last day, revealed only if both people consent. The three screenshots attached to the decision show the match tab, the chat tab, and the match card. Screens a and b, and the transcript and breakdown under c, are not among them. My reply in App Store Connect asked which features duplicate what is widely available and whether a and b were evaluated. The reply did not name a feature or answer either question. Two requests: Confirm whether the Oct 9 appeal is in the Board's queue. If the Board finds the difference not meaningful, say which of a, b, or c is widely available. One sentence is enough. I will build on it or stop. I agree this is a dating app. I am asking only that the guideline's own test be applied to the screens where the difference lives.
0
0
10
22h
App Stuck in "Waiting for Review" for 9 Days – No Response from Apple Support
Hello Apple App Review Team, We are experiencing an unusually long App Store review delay with our first iOS application, We would appreciate assistance in understanding why our submission has not progressed. Application Details: App Name: Shiv Travels Apple App ID: 6820842455 Platform: iOS Version: 1.0.7 Submission Date: October 14, 2026 Current Status: Waiting for Review Developer: MindForge Quantix Pvt Ltd Submission History: October 9: Our earlier TestFlight beta build (1.0.0) was rejected under Guideline 2.1(a) due to an application crash on launch. October 14: We resolved the reported crash, tested the corrected version 1.0.7 on a real iOS device, and submitted it for App Store review. October 20: Our scheduled business launch date passed while the application remained in "Waiting for Review." October 23: The application is still waiting for review, approximately nine days after submission. Actions Already Taken: Submitted an expedited review request successfully. Raised multiple Apple Developer Support tickets. Followed up with Apple Support but have not received a response. Verified that the corrected application launches and functions successfully on a real iOS device. We understand that review timelines may vary. However, the extended delay and lack of communication are affecting our business launch plans. Could Apple or fellow developers please clarify: Are there broader App Store review delays affecting new applications? Is additional verification currently required for first-time iOS submissions? Is there another official way to obtain an update on a pending expedited review request? Has anyone recently experienced a similar delay, and how long did it take for the application to enter review? We would greatly appreciate any guidance or assistance. Thank you.
0
0
3
22h
modelContainer in SwiftData
Hello, In SwiftUI within Swift Playgrounds on iPad, I get two different results depending on whether I place .modelContainer(for: Valeur.self) immediately after ContentView() or after WindowGroup {....}. If I place it after WindowGroup {....}, I can neither save to nor query the database in the preview; it only works in read-only mode. If I place it after ContentView(), it works correctly in both preview and read-write mode. Which version should I use? Thanks for your feedback.
3
0
257
22h
macOS 27.0.1: diagnosing SecItemCopyMatching errSecAuthFailed (-25293)
On macOS 27.0.1, SecItemCopyMatching returns -25293 (errSecAuthFailed) when a native app reads an existing login keychain item. We have verified that the app signature matches and that the user has added the app to the list of allowed applications. This occurs with user interaction disabled, and execution stops before connecting to the mail server. Is there an officially recommended diagnostic method to distinguish whether the cause is app authorization, the execution session, or the internal state of the keychain, without reading secret information, changing permissions, or unlocking the keychain?
1
0
15
22h
Documents TCC denial vs app-created directories: supported diagnostics and revocation on macOS 27
I'm investigating the boundary between Documents TCC protection and the app-created-file/user-intent exceptions on macOS 27.0.1. This is a request for supported diagnostics and revocation guidance, not a claim of a security bypass. Paths and process labels below are anonymised; the trace summaries describe observations, not a complete reproducer. Observed behaviour With Documents access disabled for a ChatGPT/Codex desktop app in Privacy & Security, its direct file tool created a workspace directory under ~/Documents and a new text file inside it. The file and contents were independently verified in Terminal. After the workspace was deleted manually and its absence verified, the tool recreated the directory and another test file without a new consent prompt. Restarting the app did not prevent this. No access to unrelated, pre-existing personal documents has been established. An fs_usage capture during a successful test showed an open for writing followed by WrData[A] on the test path, attributed to a local process named codex. The numeric suffix in that capture has NOT been conclusively correlated to the executor PID; it should not be treated as proof of the exact process chain. Process and signing observations A separate launchctl procinfo inspection of a local Codex exec-server showed sandboxed = no, with the desktop app as its responsible process. This establishes the inspected executor's state, not necessarily the dynamic restrictions of the exact writer or its children. The desktop bundle identifier is com.openai.codex. The embedded CLI has signing identifier codex and application identifier 2DC432GLL2.com.openai.codex.cli. These are vendor identifiers, not account identifiers. Embedded entitlement XML was read directly from the Mach-O LC_CODE_SIGNATURE superblob, because codesign diagnostics inside a later restricted tool environment were inconclusive. The desktop executable declares com.apple.security.app-sandbox = false, com.apple.security.files.user-selected.read-write = true and com.apple.security.automation.apple-events = true. The CLI's embedded entitlements include its application/team identifiers and JIT/unsigned-executable-memory permissions, with no app-sandbox entitlement. These are embedded declarations, not a claim that runtime validation or every effective grant has been verified. Being outside App Sandbox does not itself remove TCC protection. TCC chronology Earlier, a Python operation attributed to com.openai.codex requested kTCCServiceSystemPolicyDocumentsFolder. Its AUTHREQ_RESULT had authValue=0 and authReason=2. A later log recorded deletion of a Documents TCC record for that app, before the successful Codex write. Thus the earlier Python denial does not establish the decision applicable to the later write. Filtered TCC logs around the successful write contained app identity information but no matching Documents decision; a sandbox-log search found no relevant entry. Those are search results, not proof that no security check occurred. Extended attributes and application policy The parent Documents directory had a 216-byte com.apple.macl; the workspace had a 72-byte com.apple.macl. The parent's attribute remained when the child directory was deleted, and the recreated child acquired an attribute again. The identities represented by those records and their causal role are unknown. A Codex task configuration separately allowed the workspace as writable. That explains an application-policy allowance, not automatically the macOS authorisation. Filename searches did not identify a definite security-scoped bookmark; that does not rule one out. TCC database queries were inaccessible. No Full Disk Access was granted to inspect them. Questions Apple's WWDC19 session 701 explains that creating new documents in protected locations needs no consent, and that apps can access files they created or the user selected: https://developer.apple.com/videos/play/wwdc2019/701/ Does that documented exception also explain creating/recreating a directory and then accessing its descendants while the Documents switch is off on current macOS? What supported read-only diagnostics distinguish app-created-item access, a parent-directory MACL grant, security-scoped bookmarks, dynamic sandbox extensions and TCC responsible-process attribution? Is there a supported way to revoke per-item/user-intent access? Does the Documents switch intentionally leave new-file creation possible? For a user who wants to prohibit all Documents writes while retaining the desktop app, is an independently enforced filesystem sandbox required? How should that boundary be tested across direct file tools, shell children and GUI automation? I would appreciate guidance before any further disposable-file tests, attribute changes or TCC resets. No general Documents bypass or access beyond the workspace has been demonstrated.
0
0
10
22h
No response for 15 days after resubmission on October 8, stuck in "Waiting for Review"
Hello App Review team, I resubmitted my app Lumvid AI Creator (Apple ID: 6791623672) for review on October 8, 2026, following a previous rejection. As of October 23, 15 days have passed without further feedback or a review decision. I have already requested an expedited review. I also contacted Apple Developer Support under “App Review Status” on October 17, 2026 (Case ID: 102999751118), but have not received an update. Could someone from App Review please check whether anything is blocking this submission and confirm whether any additional information or action is required from me? I would appreciate help escalating case 102999751118 so the review can proceed. I am ready to provide any further details through App Store Connect. Thank you, Mikas Dema
0
0
17
22h
System protocol CPU performance question
Hello guys In my game the player sits in the middle of the screen and shoots on enemies coming all around it. (none vr/ar game) I have 3 :systems protocol already to spawn the enemies using timer and budget a different one to move them to the player direction pool system that turned off dead enemies Because reality kit is a high level framework i dont know what is the fastest way to design the bullet system for better cpu speed A. Seperated system for the bullets, asking to know the closest enemy to travel to, hit, and move to the disable pool system if died. or B. Use the same system that moving the enemies but in a seperated loop (prabably one before moving the enemies) Thanks for the help
1
0
39
22h
TestFlight blocked account-wide since 19 Oct: all builds expired at once, BETA_CONTRACT_MISSING on new builds
Since 19 Oct 2026, TestFlight is blocked for my whole team, not for a single app. Account Team ID: 95MF867832 (individual account, I am the Account Holder) Apps: 6819072253 and 6748716751 What happened On 19 Oct 2026 at 06:13 PDT every TestFlight build on the team expired at the same second, including builds that still had weeks left. A new build uploaded on 20 Oct is VALID (expires Jan 2027), but submitting it to Beta App Review fails: App Store Connect web: "There was an error processing your request. Please try again later." API POST /v1/betaAppReviewSubmissions: 422 ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING ("Beta contract is missing for the app"). Internal testers cannot install either: "The requested app is not available or doesn't exist". Retried hourly through 23 Oct: still 422. Already checked All agreements are Active, nothing pending. The Paid Apps Agreement was activated on 13 Oct 2026. A fresh build did not help. App Store review submission itself works (an App Store version was submitted on 23 Oct); only TestFlight is affected. Reported Feedback Assistant: FB25290077 Developer Support case: 103005423668 Other developers report the same error in thread 813703, which suggests a backend issue with the TestFlight beta contract after an agreement change. Could someone from Apple please route this to the TestFlight team to re-attach the beta contract? Thank you.
Replies
1
Boosts
0
Views
25
Activity
22h
System-wide Core Location failure on macOS 27.0.1: Wi-Fi positioning knownCount=0, incorrect time zone, same failure on Wi-Fi-only iPad
I am experiencing a system-wide Location Services failure on my MacBook running macOS 27.0.1. Several days after the problem first appeared on the Mac, my iPad Pro (Wi-Fi-only model) developed a very similar issue. Both devices are in Ukraine and should use the Europe/Kyiv time zone. The Mac unexpectedly selected Cupertino, PDT, while the iPad selected a Chinese time zone. Location detection is now failing in Apple Maps, Weather, browsers, and other applications using Core Location. My iPhone continues to determine its location correctly. The macOS locationd diagnostic logs show that Wi-Fi access points are being discovered but none are recognized as known references in the observed positioning check. Steps to reproduce Connect the affected Mac to a working Wi-Fi network with internet access. Ensure Location Services are enabled. Open Apple Maps and request the current location. Attempt browser-based geolocation using a website that requests the current location. Open System Settings → General → Date & Time and enable automatic time-zone detection. Observe the inability to determine the correct location and the incorrect automatic time-zone selection. The failure persists across multiple Wi-Fi networks, including an iPhone Personal Hotspot. Expected result Core Location should correctly determine the approximate physical location in Ukraine using available positioning information. Apple Maps, Weather, browsers, and other applications should receive valid location data. Automatic time-zone detection should select Europe/Kyiv. Actual result Apple Maps cannot correctly determine the current location. Browser geolocation fails. Weather displays incorrect location-dependent information. Automatic time-zone detection selected Cupertino (PDT) on the Mac instead of Europe/Kyiv. The Wi-Fi-only iPad Pro independently selected a Chinese time zone instead of Europe/Kyiv. Automatic location detection remains unusable across applications. The problem persists after connecting to different Wi-Fi networks. The Mac problem began suddenly during normal use. Around that time, the system automatically transitioned to dark appearance for the evening (as expected), but the automatic time zone also changed unexpectedly. The iPad developed similar symptoms several days later. Troubleshooting already performed Tested multiple Wi-Fi networks. Tested internet access through an iPhone Personal Hotspot. Checked IP-based geolocation using external services; these correctly identify the geographic region. Considered VPN-related causes; the behavior is not explained by the IP geolocation results. Confirmed that Location Services work correctly on my iPhone. The simultaneous involvement of two independent devices, combined with normal iPhone positioning, suggests a possible failure in Wi-Fi-based positioning or the associated system services rather than an isolated hardware issue. Technical diagnostics On October 22, 2026, the following message was obtained from the macOS locationd unified log: 2026-10-22 22:31:00.638 Df locationd[387:2755b6] [com.apple.locationd.Position:GeneralCLX] WifiAps, querycheck, knownCount, 0, unknownCount, 17, knownCountTile, 0, knownToUnknownRatio, 0.0, queryMacAddresses.size, 34, sinceLastServerQuery, 187.15, isQueryNeeded, 1, forceQuery, 0, queryType, 0, reqType, 0 Important diagnostic fields: knownCount = 0 unknownCount = 17 knownCountTile = 0 knownToUnknownRatio = 0.0 queryMacAddresses.size = 34 isQueryNeeded = 1 These values indicate that the positioning subsystem is discovering Wi-Fi access points but has no recognized positioning references in this particular check. This resembles a previously reported Core Location / GeoServices failure. Potentially related existing reports Apple Developer Forums: https://developer.apple.com/forums/thread/835896 The discussion documents a similar system-wide location failure with knownCount = 0 despite successful Wi-Fi scanning. Feedback IDs submitted by another affected user: FB23196632 FB23366087 There are also independent reports from Ukrainian users whose Macs incorrectly determine their location or time zone as China: https://www.reddit.com/r/MacOS/comments/1nt0lli/location_glitch/ These reports may involve the same underlying issue, but a common root cause has not been confirmed. Request for investigation Please investigate whether this issue is related to: Apple's Wi-Fi positioning database or lookup service. Core Location / GeoServices processing of Wi-Fi-based location results. Incorrect, missing, or stale Wi-Fi access-point location records. Local positioning cache or Wi-Fi regulatory-domain problems. I would particularly appreciate investigation of the knownCount = 0 condition and whether it can explain the incorrect time-zone selection on two separate devices. Please route this report to the appropriate macOS Core Location / GeoServices engineering team. I can provide additional diagnostic logs and sysdiagnose data if required.
Replies
1
Boosts
0
Views
566
Activity
22h
DSA trader status stuck "In Review" since 13 October – app unavailable in its only market
My trader information under the EU Digital Services Act has been "In Review" since 13 October 2026. Since then my app has not been available in Germany, which is its only storefront. Pricing and Availability shows "Trader contact information missing". In App Store Connect I cannot edit, resubmit or view any details. What I have tried: Developer Support on 16 October 2026 (Distribution > Other Distribution Questions): no reply yet (case ID: 102998226596) Developer Support on 21 October 2026 (Reports and Payments > Paid Agreement Setup) Checked my inbox, including spam: no request for documents or verification codes App: Bowlification, Apple ID 6814083192 This looks like the same issue as https://developer.apple.com/forums/thread/848065. Is there anything I can do on my side, or could someone from the App Store Connect team take a look? Thank you.
Replies
4
Boosts
0
Views
158
Activity
22h
Apple, how are developers supposed to launch their apps when DSA verification is stuck with no response?
I’m an independent developer preparing to launch my first app in the European Union. My DSA trader verification is still pending, and the process has become a major obstacle to launching my business. I’ve already contacted Apple Developer Support twice by email. No response. No explanation. No timeline. After looking through these forums, I’ve discovered that I’m far from alone. Other developers have reported similar issues, some waiting for months without a resolution. Apple, this is a serious problem. Independent developers invest months of work, money, and energy into building products for your ecosystem. Yet a mandatory administrative verification can leave their entire launch on hold, with no visibility and seemingly no way to move forward. We understand the importance of complying with the EU Digital Services Act. That’s not the issue. The issue is being required to complete a process that appears to offer no reliable way to get help when something goes wrong. I’m not asking for special treatment. I’m asking for basic transparency and accountability. Could someone from Apple please address the following? Is Apple aware of the recurring delays affecting DSA trader verification? Is there a dedicated team or escalation process for developers whose verification is stuck? What are developers supposed to do when multiple support requests go unanswered? If other developers are experiencing the same issue, please share your experience and how long you’ve been waiting. Apple, we want to comply with your requirements. We just need a process that actually works.
Replies
0
Boosts
0
Views
18
Activity
22h
Automated price-confirmation message (3.0.0 Business: Preamble) answered, nearly 5 days with no response. Has anyone seen this clear?
App Review's automated message (3.0.0 Business: Preamble) arrived on 1 October at 10:14 AM CDT. It asked us to confirm the price of a non-consumable in-app purchase. We confirmed the price in the same thread at 10:21 AM CDT, and wrote again on 5 October at 10:00 AM CDT. As of 6 October it has been nearly 5 days since our answer, with no reply in the thread. Developer Support (case 102978876606) estimated 48 hours on 1 October. The submission still shows "Unresolved Issues" and the app version shows "Rejected". What we have already done: replied in the thread; confirmed the price in writing; left the build and all four in-app purchase items unchanged and "Ready for Review"; opened the Developer Support case above. Two questions: Has anyone gone through this exact message, and how did it end (a reply, a status change, a resubmission)? How long did it take? Are we missing a step besides replying to the question, such as resubmitting, or changing something on the in-app purchase page? App ID 6808337831. Thank you.
Replies
1
Boosts
0
Views
127
Activity
22h
15 Days Waiting for App Review – Apple, This Is Unacceptable for Paying Developers
I'm writing this post to express my serious frustration and disappointment with Apple's App Review process. We submitted our app, Virtual Pro Association, on September 28, 2026. Today is October 13, and after 15 days, our app is still not approved. Here is the timeline: September 28: Initial submission. October 6: Apple finally started reviewing our app after approximately 8 days. October 6: The app was rejected. We fixed the reported issues and resubmitted it within approximately one hour. October 13: Seven more days have passed, and our app is still stuck in "Waiting for Review." We even requested an expedited review, which Apple accepted. Apple explicitly stated that if our submission was rejected, the corrected version would automatically return to the expedited review queue. So what exactly does "expedited" mean if we are still waiting after all this time? We have contacted Apple Developer Support multiple times, but all we receive are generic responses telling us to wait, without any meaningful explanation or estimated timeline. This is not acceptable. Behind every application, there are real people working hard. Developers, designers, administrators, and entire teams invest countless hours building, testing, and preparing their products for launch. We have responsibilities, deadlines, communities waiting for our services, and projects that depend on these releases. Apple cannot simply leave developers waiting indefinitely without transparency or accountability. We pay an annual fee to participate in the Apple Developer Program. We understand that app reviews are necessary for security and quality, and we fully support that process. But paying developers should reasonably expect an efficient review service, clear communication, and predictable procedures. If Apple's App Review team cannot handle the current volume of submissions, Apple should invest in hiring more reviewers and improving its review infrastructure. Developers should not have to repeatedly contact support, request expedited reviews, and post on forums just to find out why their applications are sitting in a queue for weeks. We are not asking Apple to approve applications without reviewing them. We are asking Apple to review them within a reasonable timeframe. Our app has been tested extensively, the reported issues were corrected immediately, and we have done everything requested of us. Yet we are still waiting. 15 days. An approved expedited review request. A corrected submission. No meaningful progress. Apple, developers deserve better. We need transparency, accountability, and a review process that respects the time and work of the people who build applications for your ecosystem. How many other developers are experiencing the same situation right now?
Replies
21
Boosts
17
Views
1k
Activity
22h
Mac Catalyst: outgoing CallKit call opens FaceTime and turns on the camera
We're bringing our CallKit-based VoIP app to the Mac with Mac Catalyst. Incoming calls work fine. For outgoing calls we request a CXStartCallAction (audio only, isVideo = false), the provider fulfills it and the call connects. But at the moment the call starts dialing, macOS launches FaceTime.app, which turns on the camera preview and shows its own call screen for our call ("no video"). When the call ends, FaceTime stays open and the camera stays on until FaceTime is quit manually. The system log shows callservicesd deciding to launch the in-call application for our call: callservicesd _shouldLaunchInCallApplicationForCall: 1 callservicesd Opening URL: <private> for call <private> CoreServicesUIAgent LAUNCH: ... com.apple.FaceTime starting stopped process.Reported as FB25284357 (macOS 27.0.1, Xcode 27.1). Is this expected for third-party CallKit providers on macOS? Is there a supported way to keep the call in our own app without dropping CallKit for outgoing calls?
Replies
1
Boosts
0
Views
43
Activity
22h
macOS /etc/ssl/cert.pem still trusts the eMudhra roots: curl and python3 accept the compromised intermediates
Apple blocked the eight compromised eMudhra intermediate CAs (CVE-2026-111943) for Security.framework clients. But on macOS 27.0.1 (26A434), /usr/bin/curl and /usr/bin/python3 still accept certificates from them. These tools verify against /etc/ssl/cert.pem and do not check revocation. The file (dated Sep 24) still contains both roots that the compromised intermediates chain to: emSign ECC Root CA - G3 AAA Certificate Services To reproduce, with SSL_CERT_FILE and CURL_CA_BUNDLE not set: /usr/bin/curl -sS -o /dev/null -w '%{exitcode}\n' https://dv-g3b-emudhra.we-have-a-problem.com/ # 0 — the connection succeeds grep -E 'emSign ECC Root CA - G3|AAA Certificate Services' /etc/ssl/cert.pem # both roots are presentWith a CA bundle that does not have these roots (Homebrew ca-certificates), the same command fails with "unable to get local issuer certificate". So the system bundle is the cause. softwareupdate -l shows no update. Questions: Does Apple plan to update /etc/ssl/cert.pem for this, and will the security notes say so? Until then, is setting SSL_CERT_FILE to a separate bundle the recommended workaround for the system tools?
Replies
0
Boosts
0
Views
23
Activity
22h
App Review Pending for More Than 48 Hours – Backed: Warranty & Claim Kit
Hello Apple Developer Community, I submitted my iOS app, Backed: Warranty & Claim Kit, for App Review and received Apple's confirmation email stating that the app had been received for review. The email mentions that over 90% of apps are reviewed within 48 hours. However, it has now been more than 48 hours, and my app's status is still showing “Waiting for Review” in App Store Connect. I understand that review times can vary depending on several factors, but I would appreciate some guidance from developers who have experienced a similar delay. Has anyone recently experienced a review delay beyond 48 hours? Is it normal for an app to remain in “Waiting for Review” status for several days? At what point should I contact Apple Developer Support? App details: App name: Backed: Warranty & Claim Kit Platform: iOS Current status: Waiting for Review Time elapsed: More than 48 hours I would appreciate any advice or insights from developers who have experienced this situation. Thank you!
Replies
0
Boosts
0
Views
22
Activity
22h
Separate CGBitmapContexts drawn concurrently produce wrong pixels when another thread fills translucent shapes (FB25211753)
Hi, my first post :-) feel free to say hi! I’ve filed this as FB25211753 and am posting in case others hit it. When several threads each draw into their own CGBitmapContext (separate buffers, separate contexts), one context’s output is corrupted if another thread is filling translucent shapes at the same time. QA1238 says drawing to separate Quartz objects on separate threads is supported. With only identical renders running concurrently, 0 of 64 differ from a serial reference. With another thread filling translucent ellipses into an unrelated context, 32 of 32 differ. On macOS 27.0.1, each corrupted render has about 0.3–4.6% of its bytes wrong, by up to 219 of 255 levels. On 26.5.1 it was smaller: 0.2–0.5%, up to 55. It’s triggered by translucent ellipses or paths. Opaque fills and translucent rectangles don’t trigger it, and per-thread colour spaces don’t help. Thread Sanitizer reports no race in the test code. Configuration: MacBook Pro (M4 Pro), macOS 26.5.1 and 27.0.1, Xcode 26.4 / Swift 6.3. Minimal reproduction (Core Graphics only). Run with swiftc -O repro.swift -o repro && ./repro: // Separate CGBitmapContexts drawn on separate threads give wrong pixels while another thread fills translucent // shapes. Seen on macOS 26.5.1 and 27.0.1 (Apple M4 Pro). Core Graphics only. // Run: swiftc -O repro.swift -o repro && ./repro // Minimal repro: separate CGBitmapContexts on separate threads, Core Graphics only. import CoreGraphics import Foundation let sRGB = CGColorSpace(name: CGColorSpace.sRGB)! /// A fixed drawing: black, a few large translucent ellipses and a stroked circle. func victim() -> [UInt8] { let w = 600, h = 400 let ctx = CGContext(data: nil, width: w, height: h, bitsPerComponent: 8, bytesPerRow: w * 4, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! ctx.setFillColor(CGColor(srgbRed: 0, green: 0, blue: 0, alpha: 1)) ctx.fill(CGRect(x: 0, y: 0, width: w, height: h)) for i in 0..<6 { ctx.setFillColor(CGColor(srgbRed: 1, green: Double(i) / 6, blue: 0.3, alpha: 0.5)) ctx.fillEllipse(in: CGRect(x: 40 + i * 80, y: 100, width: 120, height: 120)) } ctx.setStrokeColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: 0.3)) ctx.strokeEllipse(in: CGRect(x: 100, y: 50, width: 400, height: 300)) let p = ctx.data!.assumingMemoryBound(to: UInt8.self) return Array(UnsafeBufferPointer(start: p, count: w * h * 4)) // read the context's own memory: no image decoding } /// Unrelated work on another context: many tiny translucent ellipses. func aggressor() { let ctx = CGContext(data: nil, width: 800, height: 500, bitsPerComponent: 8, bytesPerRow: 0, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! for k in 0..<1600 { ctx.setFillColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: Double(k % 7) / 7)) ctx.fillEllipse(in: CGRect(x: k % 800, y: k % 500, width: 1, height: 1)) } } let reference = victim() for mode in ["victims only", "victims + aggressors"] { let lock = NSLock() nonisolated(unsafe) var bad = 0, compared = 0 DispatchQueue.concurrentPerform(iterations: 64) { i in if mode != "victims only", i % 2 == 1 { aggressor(); return } let same = victim() == reference lock.lock(); compared += 1; if !same { bad += 1 }; lock.unlock() } print("\(mode): \(bad) of \(compared) renders differ from the serial reference") } Has anyone else seen this, or found a workaround other than drawing on a single thread?
Replies
4
Boosts
0
Views
1.6k
Activity
22h
First app stuck in Waiting for Review since October 13, expedite approved
Hello, Our first app, Gaft (Apple ID 6798040496), version 1.0, was submitted for review on October 13, 2026 together with its first in-app purchases (two auto-renewable subscriptions and one consumable). It is still in Waiting for Review. An expedited review was approved on October 19, and we contacted Developer Support on October 20 (case 103002520980), but there is no reply and no change in status yet. Is anything needed from our side? Thank you for your help.
Replies
0
Boosts
0
Views
19
Activity
22h
Unexpected iPad and Apple Watch screenshot tabs appearing in App Store Connect
When submitting a new version of our iOS app in 1st Oct, we noticed that iPad and Apple Watch tabs appeared in the “Previews and Screenshots” section alongside the iPhone tab. These tabs did not appear during our previous version submissions. Our app is intended for iPhone, and we do not need iPad or Apple Watch screenshot sections. We have not intentionally added support for these devices, and our submission process has remained the same. Here is a screenshot showing the tabs meanwhile our build metadata only support iphone in device family We would appreciate clarification on three points: 1. Why did this happen? Is it caused by a change in App Store Connect, something in our uploaded build, or another setting? 2. What impact does this have when submitting an app? If we submit with these tabs present but leave their screenshot sections empty, could this affect approval, supported-device listings, or distribution? 3. How can we prevent this in future submissions? Are there specific project or App Store Connect settings we should check or change?
Replies
3
Boosts
0
Views
96
Activity
22h
Aquadoku resubmission in "Waiting for Review" for 10 days after replying to a 2.1(b) request
Hello, Our app Aquadoku (Apple ID 6809423307, iOS 1.0) has been in "Waiting for Review" since October 12, 2026 (PT), with no status change for 10 days. On October 12 the submission was rejected under Guideline 2.1(b), asking where to find our in-app purchases. I replied in App Store Connect with step-by-step directions and a screen recording from a device. The in-app purchases had dropped out of the submission, so I added all three (Remove All Ads, Reveal ×10, Scan ×10) back to version 1.0 and resubmitted the same day. An expedited review was accepted for this app on October 10, and the confirmation said a resubmission after rejection would return to the expedite queue automatically. Agreements, banking and tax information are active, and there are no new messages from App Review. The Android version has been live since September 28, and iOS players are still waiting. Could someone from App Review please check whether anything is blocking this submission? Earlier thread: https://developer.apple.com/forums/thread/850351 Thank you.
Replies
0
Boosts
0
Views
9
Activity
22h
4.3(b) appeal filed Oct 9, no reply: how is "meaningfully different" judged?
I am asking two things: whether the App Review Board has my appeal, and how one sentence in the decision should be read against the guideline. I am not asking for an exception. I will follow the Board's decision. App: BeetMeet (Korea only, 19+), Apple ID 6819720059. Rejected Oct 8, 2026 under 4.3(a) and 4.3(b). I replied in App Store Connect the same day and filed an appeal through the App Review Board form on Oct 9. The form showed no case number, so I have no way to check its status except to ask here. No reply as of Oct 23. 4.3(a) is resolved. It came from an earlier record of the same app that still had a storefront. I removed every storefront from that record on Oct 8 and will not resubmit it. 4.3(b) is the question. The guideline says dating apps "are well established on the App Store and we will not accept new submissions unless they offer a meaningfully different or improved experience." The decision says the app "may include features or characteristics that distinguish it. However, there are already enough of these apps on the App Store." Read side by side, the decision allows that the app may be distinguishable and then declines on the size of the category. The guideline makes the category's size the reason for the test, not its result. If I am reading this wrong, I would like to know how it should be read, so that I can act on the actual standard instead of guessing at it. What I asked App Review to evaluate, in the demo account listed in App Review Information, takes about five minutes: a. Home > "Another me" > Report. The user's own model, built from a 91-item assessment and 13 guided conversations. Matching cannot start before this model exists. b. Situation cards. The user answers 10 relationship situations first, then grades how their own model answered each one. c. Match card. At most one person, shown only when 1,000 simulated encounters and seven staged conversations score 90% or higher. The full simulated conversation and an eleven-axis score breakdown are one tap away. If no one reaches 90%, the screen says so. There is no browsing, feed, swipe, or list anywhere in the app. d. Chat. Seven days, photos blurred until the last day, revealed only if both people consent. The three screenshots attached to the decision show the match tab, the chat tab, and the match card. Screens a and b, and the transcript and breakdown under c, are not among them. My reply in App Store Connect asked which features duplicate what is widely available and whether a and b were evaluated. The reply did not name a feature or answer either question. Two requests: Confirm whether the Oct 9 appeal is in the Board's queue. If the Board finds the difference not meaningful, say which of a, b, or c is widely available. One sentence is enough. I will build on it or stop. I agree this is a dating app. I am asking only that the guideline's own test be applied to the screens where the difference lives.
Replies
0
Boosts
0
Views
10
Activity
22h
App Stuck in "Waiting for Review" for 9 Days – No Response from Apple Support
Hello Apple App Review Team, We are experiencing an unusually long App Store review delay with our first iOS application, We would appreciate assistance in understanding why our submission has not progressed. Application Details: App Name: Shiv Travels Apple App ID: 6820842455 Platform: iOS Version: 1.0.7 Submission Date: October 14, 2026 Current Status: Waiting for Review Developer: MindForge Quantix Pvt Ltd Submission History: October 9: Our earlier TestFlight beta build (1.0.0) was rejected under Guideline 2.1(a) due to an application crash on launch. October 14: We resolved the reported crash, tested the corrected version 1.0.7 on a real iOS device, and submitted it for App Store review. October 20: Our scheduled business launch date passed while the application remained in "Waiting for Review." October 23: The application is still waiting for review, approximately nine days after submission. Actions Already Taken: Submitted an expedited review request successfully. Raised multiple Apple Developer Support tickets. Followed up with Apple Support but have not received a response. Verified that the corrected application launches and functions successfully on a real iOS device. We understand that review timelines may vary. However, the extended delay and lack of communication are affecting our business launch plans. Could Apple or fellow developers please clarify: Are there broader App Store review delays affecting new applications? Is additional verification currently required for first-time iOS submissions? Is there another official way to obtain an update on a pending expedited review request? Has anyone recently experienced a similar delay, and how long did it take for the application to enter review? We would greatly appreciate any guidance or assistance. Thank you.
Replies
0
Boosts
0
Views
3
Activity
22h
modelContainer in SwiftData
Hello, In SwiftUI within Swift Playgrounds on iPad, I get two different results depending on whether I place .modelContainer(for: Valeur.self) immediately after ContentView() or after WindowGroup {....}. If I place it after WindowGroup {....}, I can neither save to nor query the database in the preview; it only works in read-only mode. If I place it after ContentView(), it works correctly in both preview and read-write mode. Which version should I use? Thanks for your feedback.
Replies
3
Boosts
0
Views
257
Activity
22h
macOS 27.0.1: diagnosing SecItemCopyMatching errSecAuthFailed (-25293)
On macOS 27.0.1, SecItemCopyMatching returns -25293 (errSecAuthFailed) when a native app reads an existing login keychain item. We have verified that the app signature matches and that the user has added the app to the list of allowed applications. This occurs with user interaction disabled, and execution stops before connecting to the mail server. Is there an officially recommended diagnostic method to distinguish whether the cause is app authorization, the execution session, or the internal state of the keychain, without reading secret information, changing permissions, or unlocking the keychain?
Replies
1
Boosts
0
Views
15
Activity
22h
Documents TCC denial vs app-created directories: supported diagnostics and revocation on macOS 27
I'm investigating the boundary between Documents TCC protection and the app-created-file/user-intent exceptions on macOS 27.0.1. This is a request for supported diagnostics and revocation guidance, not a claim of a security bypass. Paths and process labels below are anonymised; the trace summaries describe observations, not a complete reproducer. Observed behaviour With Documents access disabled for a ChatGPT/Codex desktop app in Privacy & Security, its direct file tool created a workspace directory under ~/Documents and a new text file inside it. The file and contents were independently verified in Terminal. After the workspace was deleted manually and its absence verified, the tool recreated the directory and another test file without a new consent prompt. Restarting the app did not prevent this. No access to unrelated, pre-existing personal documents has been established. An fs_usage capture during a successful test showed an open for writing followed by WrData[A] on the test path, attributed to a local process named codex. The numeric suffix in that capture has NOT been conclusively correlated to the executor PID; it should not be treated as proof of the exact process chain. Process and signing observations A separate launchctl procinfo inspection of a local Codex exec-server showed sandboxed = no, with the desktop app as its responsible process. This establishes the inspected executor's state, not necessarily the dynamic restrictions of the exact writer or its children. The desktop bundle identifier is com.openai.codex. The embedded CLI has signing identifier codex and application identifier 2DC432GLL2.com.openai.codex.cli. These are vendor identifiers, not account identifiers. Embedded entitlement XML was read directly from the Mach-O LC_CODE_SIGNATURE superblob, because codesign diagnostics inside a later restricted tool environment were inconclusive. The desktop executable declares com.apple.security.app-sandbox = false, com.apple.security.files.user-selected.read-write = true and com.apple.security.automation.apple-events = true. The CLI's embedded entitlements include its application/team identifiers and JIT/unsigned-executable-memory permissions, with no app-sandbox entitlement. These are embedded declarations, not a claim that runtime validation or every effective grant has been verified. Being outside App Sandbox does not itself remove TCC protection. TCC chronology Earlier, a Python operation attributed to com.openai.codex requested kTCCServiceSystemPolicyDocumentsFolder. Its AUTHREQ_RESULT had authValue=0 and authReason=2. A later log recorded deletion of a Documents TCC record for that app, before the successful Codex write. Thus the earlier Python denial does not establish the decision applicable to the later write. Filtered TCC logs around the successful write contained app identity information but no matching Documents decision; a sandbox-log search found no relevant entry. Those are search results, not proof that no security check occurred. Extended attributes and application policy The parent Documents directory had a 216-byte com.apple.macl; the workspace had a 72-byte com.apple.macl. The parent's attribute remained when the child directory was deleted, and the recreated child acquired an attribute again. The identities represented by those records and their causal role are unknown. A Codex task configuration separately allowed the workspace as writable. That explains an application-policy allowance, not automatically the macOS authorisation. Filename searches did not identify a definite security-scoped bookmark; that does not rule one out. TCC database queries were inaccessible. No Full Disk Access was granted to inspect them. Questions Apple's WWDC19 session 701 explains that creating new documents in protected locations needs no consent, and that apps can access files they created or the user selected: https://developer.apple.com/videos/play/wwdc2019/701/ Does that documented exception also explain creating/recreating a directory and then accessing its descendants while the Documents switch is off on current macOS? What supported read-only diagnostics distinguish app-created-item access, a parent-directory MACL grant, security-scoped bookmarks, dynamic sandbox extensions and TCC responsible-process attribution? Is there a supported way to revoke per-item/user-intent access? Does the Documents switch intentionally leave new-file creation possible? For a user who wants to prohibit all Documents writes while retaining the desktop app, is an independently enforced filesystem sandbox required? How should that boundary be tested across direct file tools, shell children and GUI automation? I would appreciate guidance before any further disposable-file tests, attribute changes or TCC resets. No general Documents bypass or access beyond the workspace has been demonstrated.
Replies
0
Boosts
0
Views
10
Activity
22h
No response for 15 days after resubmission on October 8, stuck in "Waiting for Review"
Hello App Review team, I resubmitted my app Lumvid AI Creator (Apple ID: 6791623672) for review on October 8, 2026, following a previous rejection. As of October 23, 15 days have passed without further feedback or a review decision. I have already requested an expedited review. I also contacted Apple Developer Support under “App Review Status” on October 17, 2026 (Case ID: 102999751118), but have not received an update. Could someone from App Review please check whether anything is blocking this submission and confirm whether any additional information or action is required from me? I would appreciate help escalating case 102999751118 so the review can proceed. I am ready to provide any further details through App Store Connect. Thank you, Mikas Dema
Replies
0
Boosts
0
Views
17
Activity
22h
System protocol CPU performance question
Hello guys In my game the player sits in the middle of the screen and shoots on enemies coming all around it. (none vr/ar game) I have 3 :systems protocol already to spawn the enemies using timer and budget a different one to move them to the player direction pool system that turned off dead enemies Because reality kit is a high level framework i dont know what is the fastest way to design the bullet system for better cpu speed A. Seperated system for the bullets, asking to know the closest enemy to travel to, hit, and move to the disable pool system if died. or B. Use the same system that moving the enemies but in a seperated loop (prabably one before moving the enemies) Thanks for the help
Replies
1
Boosts
0
Views
39
Activity
22h