Overview

Summary On iOS 18 and later, Chinese text rendering shows a noticeable performance regression related to the HVF (Hierarchical Variable Font) pipeline. Environment iOS Version: iOS 18+ Framework: libhvf.dylib (Hierarchical Variable Font) Affected Font: PingFangUI.ttc (private system font, automatically used for Chinese text) Related Frameworks: CoreText, CoreGraphics, FontParser Devices: All iOS devices (more noticeable on older hardware) Background iOS 18 Change: PingFang.ttc was removed from /System/Library/Fonts/ Private PingFangUI.ttc was added (inaccessible via normal font APIs) System automatically uses PingFangUI.ttc for all Chinese text rendering PingFangUI.ttc contains HVF tables → utilizes libhvf.dylib HVF Architecture: HVF (Hierarchical Variable Font) organizes glyphs as tree structures Each glyph = Composite → multiple Parts → nested hierarchy Rendering a single character requires traversing this tree Key Observation A single Chinese glyph typically triggers ~20 calls to HVF::LoaderHVGL::loadPartAtIndex. Cache invalidation is triggered via IncrementRenderCount after every 18 glyphs: __ZNK27THierVariationsDataForkFont20IncrementRenderCountEv: ldr w8, [x0, #0x12c] add w8, w8, #0x1 str w8, [x0, #0x12c] cmp w8, #0x12 b.lo return ldr x0, [x0, #0x120] bl HVF_clear_part_cache str wzr, [x19, #0x12c] return: ret This causes the cache to be cleared before a typical sentence finishes rendering. Complete Call Stack (Rendering Hot Path) #0-1 HVF::LoaderHVGL::loadPartAtIndex #2 HVF::FlatPartCache::partAtIndex #3 HVF::PartTransformRenderer::renderComposite #4 HVF::PartTransformRenderer::render #5 HVF::PartTransformRenderer::renderToContext #6 _HVF_render_current_part #7 THierVariationsFontHandler::GetOutlinePath #8 TFontHandler::CopyGlyphPath #9 THierVariationsFontHandler::CopyGlyphPath #10 TFPFont::CopyGlyphPath #11-12 TFPFont::CopyGlyphPath / _FPFontCopyGlyphPath #13 _CGFontCreateGlyphPath #14 _CGGlyphBuilderLockBitmaps #15 _render_glyphs #16 _draw_glyph_bitmaps #17 _ripc_DrawGlyphs #18 CG::DisplayList::executeEntries #19 _CGDisplayListDrawInContextDelegate #20 _CABackingStoreUpdate_ #21-22 CALayer display/layout #23-24 CA::Transaction::commit #25-30 UIApplicationMain / RunLoop HVF::LoaderHVGL::loadPartAtIndex is consistently observed as a hot function in Instruments and in production. Cache Clear Call Stack #0 HVF::FlatPartCache::clear #1 HVF_clear_part_cache #2 THierVariationsDataForkFont::IncrementRenderCount #3 THierVariationsFontHandler::GetOutlinePath #4 TFontHandler::CopyGlyphPath #5 FPFontCopyGlyphPath #6 CGFontCreateGlyphPath #7 _render_glyphs #8 _draw_glyph_bitmaps #9 _ripc_DrawGlyphs This shows that cache clearing occurs within the glyph rendering path. Impact For a typical Chinese sentence (~20 characters): Each glyph requires multiple part loads (~20 per glyph) Cache is cleared before rendering completes Previously loaded parts cannot be reused Observed effects: Increased loadPartAtIndex invocation count Low cache hit rate Increased CPU usage in glyph rendering Main-thread blocking during Core Animation commit Regression iOS 17 and earlier: Rendering is smooth under similar workloads. iOS 18+: Increased rendering cost and visible frame drops. The issue is more pronounced on older devices such as iPhone XS and iPhone 11. Reproduction Render a Chinese text string longer than 18 characters, for example: 刷新测试中文文本用于验证渲染性能问题需要超过十八个字 Observe: Repeated loadPartAtIndex calls Frequent cache clearing Request It would be helpful to review the cache eviction strategy for HVF, particularly for complex scripts such as Chinese. Potential considerations: Adjusting or scaling the cache threshold Avoiding full cache clears during continuous rendering Improving reuse of parts across glyphs within the same rendering batch

We are currently investigating a serious issue related to Wi-Fi Aware and AccessorySetupKit. We found that some devices which originally supported Wi-Fi Aware may suddenly report that Wi-Fi Aware is not supported. After this happens, calling the following API fails: ASAccessorySession.showPicker(for:completionHandler:) API documentation: https://developer.apple.com/documentation/accessorysetupkit/asaccessorysession/showpicker(for:completionhandler:) The error returned is: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable.” Related logs: error: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable." 21:27:33.116061+0800 deviceaccessd Activating DASession: CID 0x7FC70001, BundleID xxxx, PID 542, WiFiAwareSupported: no 2026-05-26 21:27:33.118<103>21:27:33.118[E][WiFiAware::WA]@"":[ASK] showPicker callback error: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable." UserInfo={ NSDebugDescription=Current device is not Wi-Fi Aware capable., cuErrorMsg=Current device is not Wi-Fi Aware capable., NSLocalizedFailureReason=Current device is not Wi-Fi Aware capable. } Device information: Device: iPhone 16 Pro OS Version: 26.5 The device was previously able to use Wi-Fi Aware successfully. However, after the issue occurs, the system reports: WiFiAwareSupported: no The only known way to recover so far is to erase all content and settings / factory reset the device. This is not an acceptable workaround for end users and may cause a severe user experience issue. We would like to ask for your help with the following questions: Under what conditions would an iPhone that supports Wi-Fi Aware suddenly be reported as not Wi-Fi Aware capable? Is WiFiAwareSupported: no determined by hardware capability, system configuration, region setting, privacy/security policy, entitlement state, or some cached system state? Is there any known issue in AccessorySetupKit or Wi-Fi Aware on iOS 26.5 that could cause this behavior? Is there a way to recover the Wi-Fi Aware capability without requiring a factory reset? Are there any additional logs, sysdiagnose profiles, or diagnostic commands you recommend us to collect when this issue occurs? This issue is critical for us because users who encounter it will no longer be able to proceed with accessory setup, even though their device should support Wi-Fi Aware. Please let us know if you need a sysdiagnose, sample project, full device logs, or additional reproduction information. We would appreciate any guidance on the root cause and possible workaround.

Installing ZFSFSKit.appex ? /Library/ExtensionKit/Extensions/ Substituting real Mach-O (libtool wrapper ? .libs/ZFSFSKit) Installing zfs.fs ? /Library/Filesystems/ mount_zfs: Mach-O 64-bit executable arm64 Done. Signing (before pluginkit, so it sees a valid signature)... Re-signing /Library/ExtensionKit/Extensions/ZFSFSKit.appex ad-hoc (no identity). Note: requires amfi_get_out_of_my_way=1 in boot-args. Team ID: ADHOC /Library/ExtensionKit/Extensions/ZFSFSKit.appex: replacing existing signature Done. Signature: Identifier=org.openzfsonosx.filesystems.zfs.fsext Signature=adhoc TeamIdentifier=not set Entitlements: <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.application-identifier</key><string>ADHOC.org.openzfsonosx.filesystems.zfs.fsext</string><key>com.apple.developer.fskit.fsmodule</key><true/><key>com.apple.developer.team-identifier</key><string>ADHOC</string><key>com.apple.security.app-sandbox</key><true/></dict></plist> Registering with pluginkit... pluginkit -a done. Restarting fskitd... # sudo pluginkit -v -m -p com.apple.fskit.fsmodule + org.openzfsonosx.filesystems.zfs.fsext((null)) 6A12A41280FB-4190-B957-FA94DC89BB1E 2026-05-29 01:17:58 +0000 /Library/ExtensionKit/Extensions/ZFSFSKit.appex # sudo mkdir /Volumes/tank # sudo mount -F -t zfs /dev/disk4 /Volumes/tank # ls -la /Volumes/tank total 3 drwxr-xr-x 3 lundman staff 4 May 29 09:21 . drwxr-xr-x 4 root wheel 128 May 29 10:18 .. -rw-r--r-- 1 lundman staff 11 May 29 09:21 file.txt drwxr-xr-x 2 lundman staff 2 May 29 09:21 HelloWorld # cat /Volumes/tank/file.txt HelloWorld Even though FSKit isn't quite ready, I built a proof-of-concept FSKit extension to understand what the migration path looks like. This post shares what we got working, specific technical findings that weren't documented, and the gaps we hit that would need Apple's attention for a production implementation. Luckily, OpenZFS already compiles in userland for the "zdb" utility so not much work was required on that side. There were certain amount of desperation applied when we came across hurdles, so possibly some assumptions we formed are not correct. (We didn't go back and confirm the problem after it started working).

Environment Device: Apple Vision Pro (real device) OS: visionOS 26.5 Xcode: 26.5 Framework: AVFAudio / AVFoundation Summary On visionOS 26.5, tapping an empty Button consistently emits the following internal warning before the action closure executes: <<<< FigAudioSession(AV) >>>> signalled err=-19224 (<>:612) After this warning is emitted, any subsequent call to configure AVAudioSession silently stops working — audio input and output become non-functional for the lifetime of the session. If the same configuration is performed without a preceding button tap (e.g., inside View.task {}), it succeeds and audio works correctly. Reproduction Due to a dependency on LiveKitWebRTC (livekit/webrtc-xcframework) for WebRTC-based Realtime API audio, we are unable to provide a full self-contained sample project. However, the AVAudioSession configuration code involved is as follows: static func configureAudioSession() { #if !os(macOS) do { let audioSession = AVAudioSession.sharedInstance() #if os(tvOS) try audioSession.setCategory(.playAndRecord, options: []) #else try audioSession.setCategory(.playAndRecord, options: [.defaultToSpeaker]) #endif try audioSession.setMode(.videoChat) try audioSession.setActive(true, options: .notifyOthersOnDeactivation) } catch { print("Failed to configure AVAudioSession: \(error)") } #endif } Scenario A — Button tap (fails): Button("Start") { configureAudioSession() // FigAudioSession err=-19224 appears; audio stops working } Scenario B — View.task (succeeds): .task { configureAudioSession() // No warning; audio works correctly } The only difference is whether a user gesture (Button tap) precedes the call. Observed Behavior Tapping any Button on visionOS 26.5 causes FigAudioSession(AV) err=-19224 to be signalled at <>:612, even before the action closure runs. After this warning, AVAudioSession configuration appears to have no effect — setActive(true) does not throw, but audio appears to stop functioning. Configuring the session prior to any button interaction (e.g., in View.task {}) works correctly. Expected Behavior A Button tap should not implicitly interfere with the audio session state. AVAudioSession configuration should succeed regardless of the UI event context that triggers it. Questions What does FigAudioSession(AV) err=-19224 mean? Does it correspond to a documented AVAudioSession.ErrorCode? Why does a Button tap trigger a FigAudioSession signal on visionOS? Is the system performing implicit audio session management when detecting user interaction? Is there a recommended pattern for configuring AVAudioSession in response to a user gesture on visionOS? Our current workaround (View.task {}) is not suitable for on-demand audio start triggered by the user. Is err=-19224 causally responsible for the subsequent audio issue? Since setActive(true) does not throw after the warning, it is unclear whether this signal is the direct cause of the apparent audio failure or a symptom of a deeper conflict. Are there UI components or APIs on visionOS that do not trigger this signal, while still being user-interaction driven? Additional Notes Reproducible only on physical Apple Vision Pro hardware; not observed in Simulator. AirPlay mirroring is not in use during testing. No other apps are playing audio in the background at the time of reproduction. We use LiveKitWebRTC (livekit/webrtc-xcframework, revision 94ce1c9) for WebRTC audio. However, the FigAudioSession warning appears independently of the WebRTC layer — it is emitted on Button tap even before configureAudioSession() is called. We have verified that calling configureAudioSession() before performHandshake() (i.e., before WebRTC initializes its audio pipeline) does not resolve the issue when a Button tap precedes the call.

I'm on a 16" MacBook Pro M4 Max w/ 36 GB RAM Apple Pay had been working with the beta releases with not issues, but after the macOS 26.6 beta update, Apple Pay was deactivated and is showing an error message: Apple Pay has been disabled because the security settings of this Mac were modified I found suggested fixes on the non-beta Apple forums (since this issue has apparently struck past release-versions of macOS), but none of them have worked. Does anyone here have any notions? Thanks!

Hi Apple Developer Support, I am writing to escalate an urgent unresolved request regarding our app BetterUs (Team ID: TK8M23SECQ, Bundle ID: com.dalesidebottom.betterus). Timeline of attempts: ~1 May 2026 — Submitted FamilyControls Distribution entitlement request via the official form at developer.apple.com/contact/request/family-controls-distribution for bundle IDs com.dalesidebottom.betterus.shield and com.dalesidebottom.betterus.report. No confirmation number received, no response. ~20 May 2026 — Raised support case 102892887667 via developer.apple.com/contact. Received acknowledgement from Eugene. ~21 May 2026 — Replied with all requested information (date of submission, business need, bundle IDs). Today — Still no approval and no further response. It has now been over 3 weeks since the original request. What I need: The FamilyControls Distribution entitlement is already approved on my account for: com.dalesidebottom.betterus ✅ com.dalesidebottom.betterus.monitor ✅ I simply need it extended to these two sub-extensions of the same app: com.dalesidebottom.betterus.shield (Shield Configuration extension) com.dalesidebottom.betterus.report (DeviceActivity Report extension) These are not new use cases — they are part of the same approved parental screen time app. Without this, BetterUs cannot be submitted to the App Store at all. I have active testers waiting and this delay is significantly impacting our launch. I would greatly appreciate urgent attention on this matter. Thank you, Dale Sidebottom

Hello, I'm having an issue with my App Store Connect API key. The team API key is returning the following error: {'status': '401', 'code': 'NOT_AUTHORIZED', 'title': 'Authentication credentials are missing or invalid.} Account details Account Holder / Admin role Two-Factor Authentication enabled Active developer account with accepted agreements and approved apps Every App Store Connect API key I generate returns a 401 NOT_AUTHORIZED response on all endpoints (/v1/apps, /v1/bundleIds, /v1/devices, /v1/users). I have: What I've tried Revoked and regenerated keys multiple times Confirmed the Issuer ID matches exactly what is shown on the Keys page (I used the copy button) Tested from multiple browsers Verified 2FA is enabled Verified no pending license agreements Tested programmatically using a correctly formatted ES256 JWT (proper R+S raw signature, not DER-encoded) The connection reaches Apple's servers successfully — I receive a JSON 401 response rather than a network error. The JWT is correctly formed. Every endpoint returns 401. Has anyone experienced this issue? Is there something at account level that could be blocking API access entirely? Thank you.

I'm trying to submit a first-time In-App Purchase together with a new version of my macOS app, but App Store Connect doesn't seem to provide a way to do this. Setup: macOS app (Bundle ID: de.andreasmaser.Screenshots) Marketing version: 1.2, Build 1 (uploaded, processed, attached to version) IAP "Screenshots Pro" (Product ID: de.andreasmaser.Screenshots.pro) is fully configured: status "Waiting for Review", App Review screenshot present, both English + German localizations, pricing set Previous 1.1 submission was rejected under Guideline 2.1(b) because "the associated In-App Purchase products have not been submitted for review" Per Apple's documentation (https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-in-app-purchase), step 3 says: "On the right, scroll down to the In-App Purchases and Subscriptions section." The problem: This section does not exist on the macOS app version page. I scrolled through the entire page; the sections are: App Previews & Screenshots → Promotional Text → Description → Keywords → URLs/Version/Copyright → Build → Added Content → Game Center → App Review Information → App Sandbox Information → Version Release. There is no "In-App Purchases and Subscriptions" section anywhere. What I've tried: Both Version 1.1 and a fresh Version 1.2 with a freshly-uploaded build Cancelling/withdrawing the previous submission and starting a new draft Editing the IAP and re-saving (no status change) The IAP's "Submit for Review" button stays greyed out on the IAP page The submission draft panel only shows the app version, with no "+" button to add IAPs The "Submission Drafts" floating button on the IAP detail page just opens the same panel with only the app Questions: Does the "In-App Purchases and Subscriptions" section appear for macOS apps under specific conditions I'm missing? Is there a different workflow for attaching first-time IAPs on macOS apps vs. iOS apps? Is this a known App Store Connect bug, and what's the recommended workaround? Any guidance is greatly appreciated — I've been blocked on this re-submission since yesterday.

I'm in the unenviable position of needing the current UIViewController to keep an external library happy. Essentially, I need to do this in SwiftUI: import LibraryOutOfMyControl ViewControllerReader { viewController in Button("Action") { LibraryOutOfMyControl.action(with: viewController) } } My simple attempt below functions correctly but I'm relying on makeUIViewController always being immediately followed by updateUIViewController. Is the a reasonable assumption or should I set everything up assuming updateUIViewController might never be called? struct ViewControllerReader<Content>: UIViewControllerRepresentable where Content: View { @ViewBuilder var content: (UIViewController) -> Content func makeUIViewController(context: Context) -> UIHostingController<Content> { UIHostingController(rootView: content(UIViewController())) } func updateUIViewController(_ uiViewController: UIHostingController<Content>, context: Context) { uiViewController.rootView = content(uiViewController) uiViewController.view.isUserInteractionEnabled = context.environment.isEnabled } func sizeThatFits(_ proposal: ProposedViewSize, uiViewController: UIHostingController<Content>, context: Context) -> CGSize? { uiViewController.sizeThatFits(in: proposal.replacingUnspecifiedDimensions()) } }

My latest app version may have a bug that happens very rarely when opening/closing the app and AVAudioPlayer.init(contentsOf:fileTypeHint:) is called (note that everything related to audio player is protected inside try/catch blocks). But the app does start again. I tested on my Intel Mac and Mac mini 2024 without any problems. In fact we have more than 2000 Mac users that use our app daily without any problems. But we have 3 customers that have a serious problems. They have apple silicon Macs with macOS 15.7.7 and 26.5. So the app does not ever start again, after working for years. Uninstalling and deleting all hidden files over the entire hard drive related to our app and reinstalling it from the store. Does not make it start again. I saw many macOS bugs happening. Killing/Closing the app then rebooting the Mac without the option to reopen the apps. When the reboot is done our app is opened, we see a little dot underneath (nothing exists to start it on boot). I saw display problems in Monitor app. For one customer, after uninstalling our app, it does appear in App Store, but the "get" button is grey and cannot be clicked. Our app is not on the SSD and not in the garbage bin. I compiled a special version of my app with no sound, all the code related to the possible crash completely commented. I gave it to 2 users and the app does not start. After cleaning everything, rebooting and reinstalling the app, I have one customer that gets a message that the previous opening of the app crashed. But the 2 choices (do not open or reopen) don't work. It juste either do nothing or crash again and again. My Theory is that there is an old bug in macOS that my app triggered. And from that moment on, macOS will stop behaving properly. My app was compiled with the lasted Xcode and apple libraries (I only use the basic Apple libraries, no 3rd party stuff) as of last month. My customers are angry and I tell them to get help from Apple customer service. The problem is not in my app, but something get stuck in macOS that makes the app never start again. The app was working, even my latest update, then after 1 crash it never start again, even after cleaning, rebooting and reinstalling the app. I can't fix this on my side, an app that crashes should not ever break the entire OS. I want to reiterate that my app does work for me an thousands of people and that even a new version without any possible problem manually put on desktop does not start either. When we uninstall and reinstall an app, it should work as it did, not leave behind some hidden crap that makes it never start again.

Hey, I am running Xcode 26.5 and I am not able to option + click anymore on a variable or a type that is not native (String, Bool etc works). The developer documentation preview is also broken.

I'm a solo developer and owner of my companies account. I'm trying to sign on to my Mac so I can use my developer account to get a certificate for wallet use and to select the correct developer account for applications in Xcode. I'm am brand new to all this so apologize if I'm missing the simple solution. I'm not able to edit the roles of my developer account but being an Admin I should already have all the necessary access...I think. I get an error when trying to logon as a work account: Searching for the long error doesn't provide a solution in the forum or through search engines. AI says to check the roles.

To the App Review and Developer Support Teams, I am writing this post to bring an ongoing and time-sensitive App Review issue to your attention, as my submission has remained in “Waiting for Review” for an unusually long period of time and standard support channels have not yet provided a clear update or resolution. Issue Summary: My app, Cupie, was submitted for review on May 21, 2026. However, the submission has remained in “Waiting for Review” since then and has not moved to “In Review” after several days. I have already submitted an expedited review request and also contacted Apple Support regarding the delay. However, I have not yet received any clear explanation, actionable feedback, or confirmation on whether there is an issue with my account, metadata, build, agreements, or submission queue. Lack of Communication: I have opened the following support cases regarding this issue, but I have not received a meaningful update so far: Case IDs: 102900823761 102901498888 The current lack of communication makes it difficult for me to understand whether my submission is properly queued for review, whether it is stuck, or whether there is any action required from my side. Impact: This is our first public launch submission, and the delay is directly affecting our launch schedule, business operations, and user onboarding plan. We are ready to provide any additional information, test accounts, explanations, or compliance materials required for App Review. Request: I respectfully request that the App Review or Developer Support team help confirm the current status of this submission and clarify whether there is any issue preventing it from moving forward. Specifically, I would appreciate confirmation on the following: Whether my app submission is properly queued for review. Whether there is any issue with my account, metadata, build, agreements, or in-app purchase configuration. Whether the submission is delayed due to additional manual review or review queue congestion. Whether any action is required from my side to proceed. App Name: Cupie - 語音視訊、聊天交友 App ID: 6768550401 Current Status: Waiting for Review Submitted Date: May 21, 2026 Related Case IDs: 102900823761 102901498888 I would sincerely appreciate a prompt update or escalation from an Apple representative, as the submission has been waiting for review for an extended period without clear communication. Thank you for your assistance. Sincerely, Cupie Development Team

I'm trying to use SwiftUI views inside an NSToolbarItem, and I feel like I'm fighting the system. The goal is to create custom toolbar controls. I don't want AppKit or SwiftUI to recognize that there's a SwiftUI view in the toolbar and then try to style it automatically, which is what I think is happening. Consider this hierarchy: - NSToolbar - NSToolbarItem - view -> MyCustomNSView - addSubview(NSHostingView<CustomView>) So CustomView is inside an NSHostingView, which is inside an NSView, which is assigned to the .view property of an NSToolbarItem. For a while, I struggled to get this working at all because SwiftUI's layout metrics appeared to be affected by safe area insets. SwiftUI's ignoresSafeArea() only seemed to move the problem around. For now, I've disabled full-size content view, which I don't really need anyway. However, a SwiftUI Button or Menu still doesn't behave or style the way I would expect when placed inside an NSToolbarItem. They don't seem to honor many of the styling attributes or view modifiers that work elsewhere. Is there a way to tell AppKit to "ignore" the children of my NSToolbarItem and not apply toolbar-specific styling to them? Am I even correct in thinking that AppKit is recognizing a Button or Menu in the toolbar and forcibly applying styling to it? Previously, I tried implementing my "custom toolbar" entirely outside of NSToolbar, but then SwiftUI struggled with placing views under the transparent, non-existent toolbar. I'd appreciate any direction or hints here. It would be really nice to use SwiftUI for the controls I have in mind, but at the moment I can't get close to the result I'm aiming for.

My app needs both Accessibility and Input Monitoring permissions. Accessibility works as expected — calling AXIsProcessTrusted() automatically adds the app to System Settings > Privacy & Security > Accessibility, and the user just needs to toggle it on. Input Monitoring doesn't behave the same way. I'm calling CGRequestListenEventAccess() and creating a CGEvent.tapCreate(.listenOnly), but the app doesn't reliably appear in the Input Monitoring list. The user opens the pane and sees nothing to enable. What I've tried: CGRequestListenEventAccess() — shows the system prompt once per install, but doesn't always add the app to the list CGEvent.tapCreate(tap: .cgSessionEventTap, place: .headInsertEventTap, options: .listenOnly, ...) — returns nil before Accessibility is granted; after Accessibility is granted, the tap succeeds but the app still may not appear in the Input Monitoring list 3. Calling both after Accessibility is confirmed, with a delay before opening the Settings pane The flow: User grants Accessibility (app appears automatically via AXIsProcessTrusted()) App creates a listen-only CGEventTap (succeeds) App opens x-apple.systempreferences:com.apple.preference.security?Privacy_ListenEvent User sees the Input Monitoring pane but the app is not listed Environment: macOS 15 (Sequoia), signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable — this is for audio, not HID). Question: Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list? Or is there a specific entitlement, Info.plist key, or sequence of calls required on macOS 14+/15 to ensure the app appears?

My app needs both Accessibility and Input Monitoring permissions. Accessibility works as expected - calling AXIsProcesstrusted() automatically adds the app to System Settings > Privacy & Security > Accessibility, and the user just needs to toggle it on. Input Monitoring doesn't behave the same way. I'm calling CGRequestListenEventAccess() and creating a CGEvent.tapCreate(.listenOnly), but the app doesn't reliably appear in the Input Monitoring list. The user opens the pane and sees nothing to enable. What I've tried: CGRequestListenEventAccess() — shows the system prompt once per install, but doesn't always add the app to the list CGEvet.tapCreate(tsp: .cgSessionEventTap, place: .headInsertEventTap, options: listenOnly, ...) — returns nil before Accessibility is granted; after Accessibility is granted, the tap succeeds but the app still may not appear in the Input Monitoring list Calling both after Accessibility is confirmed, with a delay before opening the Settings pane The flow: User grants Accessibility (app appears automatically via AXIsProcessTrusted()) App creates a listen-only CGEventTap (succeeds) App opens x-apple.systempreferences:com.apple.preferences.security?Privacy_ListenEvent User sees the Input Monitoring pane but the app is not listed Environment: macOS 15, signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable). Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list? Or is there a specific entitlement, Info.plist key, or sequence of calls required on macOS 14+/15 to ensure the app appears?

The app idea is pretty simple, we manage small physical events through ticketing and QRs for entry. However the app reviewer insists that they are “digital” invitations and therefore mist use Apple IAP. To my understanding, digital products, services and consumables inside the app are what require Apple IAP. please correct me or guide me on what is the correct understanding. my reply to the review: Multiline requesting reconsideration under >Guideline 3.1.3(a). Xxx is a service for organizing physical events >(weddings, birthdays, corporate >gatherings) held at real venues in >xxx. The per-guest fee charged >through the app covers: Sending physical-event invitations >via xxx (the standard communication channel for event >organizers in xxx) RSVP tracking for physical attendance planning (Premium tier) >Per-guest QR codes used by gate staff to admit guests to the physical >venue The end deliverable is >admission to and management of a >real-world, in-person event. This is >materially identical to ticketing apps >(Eventbrite, Ticketmaster, ...), >reservation deposits (OpenTable, >...), and on-demand service apps >(Uber, DoorDash, ...) - all of which >use external payment processing >for physical services consumed >outside the app, per 3.1.3(a). The app does not sell digital >content or services consumed >within the app itself. No streaming >media, no in-app credit, no >subscription to in-app functionality. >The user pays only to enable real->world event logistics. BlockQuote Their reply is: Multiline Guideline 3.1.1 - Business - >Payments - In-App Purchase Issue Description We noticed that the app includes or >accesses paid digital content, >services, or functionality by means >other than In-App Purchase, which >is not appropriate for the App Store. >Specifically: The digital invitation can be >purchased in the app using >payment mechanisms other than >In-App Purchase. Apps on the United States >storefront may link out to the >default browser, using buttons, >external links, or other calls to >action, for payment mechanisms >other than in-app purchase. … BlockQuote

Hello, For developers who have gone through an App Review Board appeal — what response time did you experience? A few specific questions: Is there any way to confirm an appeal was received and queued? App Store Connect doesn't seem to show appeal status. Is it better to follow up via Contact Us, or simply wait? For those who resolved a case through the Board — was the Board's communication different from standard App Review correspondence? Trying to calibrate expectations on timing. Thanks for any shared experience.

App review reviewed one app then rejected another

We would like to use Xcode's new agentic coding feature (probably with Claude Agent). I had a look at the privacy statement, and under "Third-Party Agentic Coding Tools" it says the following: Capabilities include but are not limited to code searching, retrieving build logs, building source code, and arbitrary code execution. This is all expected, except for the bit about "arbitrary code execution". What does this mean, exactly? This sounds like a backdoor to my machine, surely that's not it? Does "code" refer to the code in my project, or any code the agent may provide? I know that other agentic coding tools may execute terminal commands, which you have to (or can select to) confirm first. Is that what is meant by arbitrary code execution? How arbitrary are we talking? And can I configure Xcode to always ask my permission first before any code is executed?