Overview

Hello, my account is pending .i try to contact apple several times with no respond the customer service is terrible.

I’m developing a text editor that provides a line number view. This view is placed next to the NSScrollView that contains the main text view, rather than inside the scroll view. The line number view updates its drawing in sync with the NSScrollView’s scrolling and text editing in the NSTextView, so it can display the correct line numbers. This approach worked fine through macOS 15, but on macOS 26 with Liquid Glass, the line numbers end up being drawn without the expected blur/soft edge effect under the window toolbar area. In AppKit, some view controllers provide APIs to switch edge effects between soft/hard, but I can’t find any API to control this for the window toolbar region. I considered simply not drawing the numbers outside the content area, but if possible I’d like to apply the Tahoe-style soft edge effect instead. Does anyone have ideas? Is this currently impossible, meaning the only option is to file a feedback/API request? Also, for various reasons, the traditional approach of implementing line numbers by subclassing NSRulerView is difficult for my app.

Hello everyone, I wanted to check whether other developers are currently experiencing unusually long “Waiting for Review” times. Our app Aslan Wealth (App ID: 6755077470) has been stuck in Waiting for Review for quite a while and has never entered the “In Review” stage. Timeline Feb 18, 2026 – Version submitted for review Feb 23 – Contacted Apple Developer Support regarding review status Feb 24 – Received reply that the case was escalated to the review team Mar 3 – Still in Waiting for Review (confirmed by support that the app is still in the queue) Mar 7–11 – Followed up with Developer Support again Mar 12 – Still Waiting for Review So the app has now been waiting for review for more than 3 weeks without ever entering active review. Additional information All agreements are active No messages in Resolution Center Build was not modified after submission App status remains Waiting for Review Questions Has anyone else recently experienced similar multi-week delays in the “Waiting for Review” stage? If so: Did your app eventually move to In Review without changes? Did Apple provide any explanation for the delay? Is there anything developers can do to help move the process forward? Any recent data points or experiences would be really helpful. Thanks in advance.

I am planning to run the AccessoryNotifications framework on xcode26.4 and ios26.4, please refer to the documentation https://aninterestingwebsite.com/documentation/accessorynotifications I couldn't find a complete demo, but I found a demo based on AccessorySetup Kit, ASK Sample https://docs-assets.aninterestingwebsite.com/published/89f5eef578ef/SettingUpAndAuthorizingABluetoothAccessory.zip. So I plan to practice the entire process of AccessoryNotifications based on this demo. Find accessories based on ASK Sample and connect them, OK Call requestForwarding (for:), OK Add AccessoryData Provider extension to receive system notifications But this step failed. I added an extension according to the documentation, but the following method will not be executed func activate(for session: NotificationsForwarding.Session) func add(notification: AccessoryNotification alertingContext: AlertingContext, alertCoordinator: AlertCoordinating) {} I found the following error log in console.app Error 16:38:17.582340+0800 usernotificationsd ### XPC DAEventExtension decode failed: DAExtensionSession: CID 0x89B80004, DAExtensionSessionConfiguration 'AB83C506-9F35-40FB-9A68-919D43B4D098': BundleID 'com.sifli.ASKSample', DAErrorDomain:350001 'DAExtensionEvent init bad type: 42' I have tried many methods to send messages to the testing phone, local Notifications, We can't even trigger the AccessoryData Provider, activate:for,add:notification: 1.Do I have to add the following two extensions according to the document in order to debug successfully? AccessoryTransportSecurity Manages cryptographic key exchange with your accessory. AccessoryTransportAppExtension Relays encrypted data to your accessory over Bluetooth. 2.What should be selected in the extension template panel of xcode 26.4 when creating these extensions? Geniric Extension Accessory Data Transport I am currently using Geniric Extension

We are developing an MDM (Mobile Device Management) solution for device management purposes, and our current implementation process is as follows: 1. Configure DEP profile to obtain profile_uuid We configured a DEP profile with the following parameters to retrieve the profile_uuid: { "allow_pairing": true, "anchor_certs": [], "auto_advance_setup": true, "await_device_configured": false, "configuration_web_url": "", "department": "test define profile", "devices": ["MNWF07QD9M"], "is_mandatory": false, "is_mdm_removable": false, "is_multi_user": false, "is_supervised": true, "language": "zh", "org_magic": "", "profile_name": "Enrollment Profile - MNWF07QD9M", "region": "cn", "skip_setup_items": [ "Accessibility", "ActionButton", "Android", "Appearance", "AppleID", "AppStore", "Biometric", "CameraButton", "DeviceToDeviceMigration", "Diagnostics", "EnableLockdownMode", "FileVault", "iCloudDiagnostics", "iCloudStorage", "iMessageAndFaceTime", "Intelligence", "Keyboard", "MessagingActivationUsingPhoneNumber", "Passcode", "Payment", "Privacy", "Restore", "RestoreCompleted", "Safety", "ScreenTime", "SIMSetup", "Siri", "SoftwareUpdate", "SpokenLanguage", "UpdateCompleted", "WatchMigration", "WebContentFiltering" ], "supervising_host_certs": [], "support_email_address": "", "support_phone_number": "", "url": "https://mdmp.com/mdm/apple/enroll?shopId=1" } We sent a POST request to the /profile endpoint with the above payload, and the response returned the profile_uuid: 605FB5C274303C19189C9B99DCD3280D. 2. Assign the profile We sent a POST request to the /profile/devices endpoint, including the aforementioned profile_uuid and the target devices list in the request body. 3. Scan the device with Apple Configurator 2 We used Apple Configurator 2 to scan and enroll the target device. Issue Encountered After the device restarts twice, it fails to retrieve the mobileconfig file from the URL: https://mdmp.com/mdm/apple/enroll. We are using Nginx as the web server and have enabled access logging, but the logs show no incoming requests from the device to the /mdm/apple/enroll endpoint at all. Could you please help identify where we might have made a mistake in this process?

Hi everyone, I submitted my app for review on February 3, and as of March 15 it’s still showing as “In Review.” This means it’s been stuck for over six weeks now. App Apple ID: 6757989460 I reached out to App Review Support via email two weeks ago but haven’t received any response yet. The app is a standard submission (not using TestFlight, not part of an expedited appeal), and I’ve verified that all compliance and payment information are complete. Has anyone else experienced such a long delay recently? Is there any additional way to get the team’s attention or escalate the case? Thanks in advance for any insights or advice.

Hello, I started my Apple Developer enrollment using the Apple Developer app. However, the payment method available on my device cannot be accepted because the billing address is outside the United States. Is it possible to complete the membership purchase through the web instead of the app?

Hello, is there any solution for what I am facing? Ive already tried everything to sign up for a developer account. Used 7 cards (2 debit cards and 5 credit cards) + I even made a Wise account and make an online debit card. All payments wont go through. I also tried calling Apple Support but they only said to send an email because they dont have a way of contacting Apple Support for Developers. I have sent an email March 17 but up to now I havent received any reply.

We built an open-source macOS menu bar app that turns speech into text and pastes it into the active app — using SpeechAnalyzer for on-device transcription, ScreenCaptureKit + Vision for screen-aware context, and FluidAudio for speaker diarization in meeting mode. Here's what we learned shipping it on macOS 26. GitHub: github.com/Marvinngg/ambient-voice Architecture The app has two modes: hotkey dictation (press to talk, release to inject) and meeting recording (continuous transcription with a floating panel). Dictation Mode Audio capture uses AVCaptureSession (more on why below). The captured audio feeds into SpeechAnalyzer via an AsyncStream: let transcriber = SpeechTranscriber( locale: locale, transcriptionOptions: [], reportingOptions: [.volatileResults, .alternativeTranscriptions], attributeOptions: [.audioTimeRange, .transcriptionConfidence] ) let analyzer = SpeechAnalyzer(modules: [transcriber]) let (inputSequence, inputBuilder) = AsyncStream.makeStream() try await analyzer.start(inputSequence: inputSequence) While recording, we capture a screenshot of the focused window using ScreenCaptureKit, run Vision OCR (VNRecognizeTextRequest), extract keywords, and inject them into SpeechAnalyzer as contextual bias: let context = AnalysisContext() context.contextualStrings[.general] = ocrKeywords try await analyzer.setContext(context) This improves accuracy for technical terms and proper nouns visible on screen. If your screen shows "SpeechAnalyzer", saying it out loud is more likely to be transcribed correctly. After transcription, an optional L2 step sends the text through a local LLM (ollama) for spoken-to-written cleanup, then CGEvent simulates Cmd+V to paste into the active app. Meeting Mode Meeting mode forks the same audio stream to two consumers: SpeechAnalyzer — real-time streaming transcription, displayed in a floating NSPanel FluidAudio buffer — accumulates 16kHz Float32 mono samples for batch speaker diarization after recording stops When the user ends the meeting, FluidAudio's performCompleteDiarization() runs on the accumulated audio. We align transcription segments with speaker segments using audioTimeRange overlap matching — each transcription segment gets assigned the speaker ID with the most time overlap. Results export to Markdown. Pitfalls We Hit on macOS 26 1. AVAudioEngine installTap doesn't fire with Bluetooth devices We started with AVAudioEngine.inputNode.installTap() for audio capture. It worked fine with built-in mics but the tap callback never fired with Bluetooth devices (tested with vivo TWS 4 Hi-Fi). Fix: switched to AVCaptureSession. The delegate callback captureOutput(_:didOutput:from:) fires reliably regardless of audio device. The tradeoff is you get CMSampleBuffer instead of AVAudioPCMBuffer, so you need a conversion step. 2. NSEvent addGlobalMonitorForEvents crashes Our global hotkey listener used NSEvent.addGlobalMonitorForEvents. On macOS 26, this crashes with a Bus error inside GlobalObserverHandler — appears to be a Swift actor runtime issue. Fix: switched to CGEventTap. Works reliably, but the callback runs on a CFRunLoop context, which Swift doesn't recognize as MainActor. 3. CGEventTap callbacks aren't on MainActor If your CGEventTap callback touches any @MainActor state, you'll get concurrency violations. The callback runs on whatever thread owns the CFRunLoop. Fix: bridge with DispatchQueue.main.async {} inside the tap callback before touching any MainActor state. 4. CGPreflightScreenCaptureAccess doesn't request permission We used CGPreflightScreenCaptureAccess() as a guard before calling ScreenCaptureKit. If it returned false, we'd bail out. The problem: this function only checks — it never triggers macOS to add your app to the Screen Recording permission list. Chicken-and-egg: you can't get permission because you never ask for it. Fix: call CGRequestScreenCaptureAccess() at app startup. This adds your app to System Settings → Screen Recording. Then let ScreenCaptureKit calls proceed without the preflight guard — SCShareableContent will also trigger the permission prompt on first use. 5. Ad-hoc signing breaks TCC permissions on every rebuild During development, codesign --sign - (ad-hoc) generates a different code directory hash on every build. macOS TCC tracks permissions by this hash, so every rebuild = new app identity = all permissions reset. Fix: sign with a stable certificate. If you have an Apple Development certificate, use that. The TeamIdentifier stays constant across rebuilds, so TCC permissions persist. We also discovered that launching via open WE.app (LaunchServices) instead of directly executing the binary is required — otherwise macOS attributes TCC permissions to Terminal, not your app. Benchmarks We ran end-to-end benchmarks on public datasets (Mac Mini M4 16GB, macOS 26): Transcription (SpeechAnalyzer, AliMeeting Chinese): • Near-field CER 34% (excluding outliers ~25%) • Far-field CER 40% (single channel, no beamforming, >30% overlap) • Processing speed 74-89x real-time Speaker diarization (FluidAudio offline): • AMI English 16 meetings: avg DER 23.2% (collar=0.25s, ignoreOverlap=True) • AliMeeting Chinese 8 meetings: DER 48.5% (including overlap regions) • Memory: RSS ~500MB, peak 730-930MB Full evaluation methodology, scripts, and raw results are in the repo. Open Source The project is MIT licensed: github.com/Marvinngg/ambient-voice It includes the macOS client (Swift 6.2, SPM), server-side distillation/training scripts (Python), and a complete evaluation framework with reproducible benchmarks. Feedback and contributions welcome.

We built an open-source macOS menu bar app that turns speech into text and pastes it into the active app — using SpeechAnalyzer for on-device transcription, ScreenCaptureKit + Vision for screen-aware context, and FluidAudio for speaker diarization in meeting mode. Here's what we learned shipping it on macOS 26. GitHub: github.com/Marvinngg/ambient-voice Architecture The app has two modes: hotkey dictation (press to talk, release to inject) and meeting recording (continuous transcription with a floating panel). Dictation Mode Audio capture uses AVCaptureSession (more on why below). The captured audio feeds into SpeechAnalyzer via an AsyncStream: let transcriber = SpeechTranscriber( locale: locale, transcriptionOptions: [], reportingOptions: [.volatileResults, .alternativeTranscriptions], attributeOptions: [.audioTimeRange, .transcriptionConfidence] ) let analyzer = SpeechAnalyzer(modules: [transcriber]) let (inputSequence, inputBuilder) = AsyncStream.makeStream() try await analyzer.start(inputSequence: inputSequence) While recording, we capture a screenshot of the focused window using ScreenCaptureKit, run Vision OCR (VNRecognizeTextRequest), extract keywords, and inject them into SpeechAnalyzer as contextual bias: let context = AnalysisContext() context.contextualStrings[.general] = ocrKeywords try await analyzer.setContext(context) This improves accuracy for technical terms and proper nouns visible on screen. If your screen shows "SpeechAnalyzer", saying it out loud is more likely to be transcribed correctly. After transcription, an optional L2 step sends the text through a local LLM (ollama) for spoken-to-written cleanup, then CGEvent simulates Cmd+V to paste into the active app. Meeting Mode Meeting mode forks the same audio stream to two consumers: SpeechAnalyzer — real-time streaming transcription, displayed in a floating NSPanel FluidAudio buffer — accumulates 16kHz Float32 mono samples for batch speaker diarization after recording stops When the user ends the meeting, FluidAudio's performCompleteDiarization() runs on the accumulated audio. We align transcription segments with speaker segments using audioTimeRange overlap matching — each transcription segment gets assigned the speaker ID with the most time overlap. Results export to Markdown. Pitfalls We Hit on macOS 26 1. AVAudioEngine installTap doesn't fire with Bluetooth devices We started with AVAudioEngine.inputNode.installTap() for audio capture. It worked fine with built-in mics but the tap callback never fired with Bluetooth devices (tested with vivo TWS 4 Hi-Fi). Fix: switched to AVCaptureSession. The delegate callback captureOutput(_:didOutput:from:) fires reliably regardless of audio device. The tradeoff is you get CMSampleBuffer instead of AVAudioPCMBuffer, so you need a conversion step. 2. NSEvent addGlobalMonitorForEvents crashes Our global hotkey listener used NSEvent.addGlobalMonitorForEvents. On macOS 26, this crashes with a Bus error inside GlobalObserverHandler — appears to be a Swift actor runtime issue. Fix: switched to CGEventTap. Works reliably, but the callback runs on a CFRunLoop context, which Swift doesn't recognize as MainActor. 3. CGEventTap callbacks aren't on MainActor If your CGEventTap callback touches any @MainActor state, you'll get concurrency violations. The callback runs on whatever thread owns the CFRunLoop. Fix: bridge with DispatchQueue.main.async {} inside the tap callback before touching any MainActor state. 4. CGPreflightScreenCaptureAccess doesn't request permission We used CGPreflightScreenCaptureAccess() as a guard before calling ScreenCaptureKit. If it returned false, we'd bail out. The problem: this function only checks — it never triggers macOS to add your app to the Screen Recording permission list. Chicken-and-egg: you can't get permission because you never ask for it. Fix: call CGRequestScreenCaptureAccess() at app startup. This adds your app to System Settings → Screen Recording. Then let ScreenCaptureKit calls proceed without the preflight guard — SCShareableContent will also trigger the permission prompt on first use. 5. Ad-hoc signing breaks TCC permissions on every rebuild During development, codesign --sign - (ad-hoc) generates a different code directory hash on every build. macOS TCC tracks permissions by this hash, so every rebuild = new app identity = all permissions reset. Fix: sign with a stable certificate. If you have an Apple Development certificate, use that. The TeamIdentifier stays constant across rebuilds, so TCC permissions persist. We also discovered that launching via open WE.app (LaunchServices) instead of directly executing the binary is required — otherwise macOS attributes TCC permissions to Terminal, not your app. Benchmarks We ran end-to-end benchmarks on public datasets (Mac Mini M4 16GB, macOS 26): Transcription (SpeechAnalyzer, AliMeeting Chinese): • Near-field CER 34% (excluding outliers ~25%) • Far-field CER 40% (single channel, no beamforming, >30% overlap) • Processing speed 74-89x real-time Speaker diarization (FluidAudio offline): • AMI English 16 meetings: avg DER 23.2% (collar=0.25s, ignoreOverlap=True) • AliMeeting Chinese 8 meetings: DER 48.5% (including overlap regions) • Memory: RSS ~500MB, peak 730-930MB Full evaluation methodology, scripts, and raw results are in the repo. Open Source The project is MIT licensed: github.com/Marvinngg/ambient-voice It includes the macOS client (Swift 6.2, SPM), server-side distillation/training scripts (Python), and a complete evaluation framework with reproducible benchmarks. Feedback and contributions welcome.

Hi, I’m trying to enroll in the Apple Developer Program as an Individual. I attempted the payment several times, but the system says the purchase is already in the system. Under my profile the status shows “Pending”, and the payment has still not been charged from my bank account. It has been about one week since I started the enrollment, and the status hasn’t changed. I also contacted Apple Developer Support, but it has been 4 days and I haven’t received any response yet. Is this normal? Has anyone experienced a similar delay during enrollment? Thanks.

We're seeing some strange behavior of the appAccountToken when passing it to a purchase in the sandbox environment. Normally we'd expect the same account token to be set on the resulting verfication, but that's not the case. Instead the token seems to be persisted on the API side and reused for some amount of time, meaning there's a mismatch and the connection between account and purchase is lost. This happens consistently even if we send new tokens on each purchase. Has there been any updates to purchase flow in the sandbox environment on Apple's side? .purchase( options: [.appAccountToken(token)] )

We now know the IsEligibleForAgeFeatures API is NOT returning True in Brazil at least 2 days past compliance date, and we don't know if that's the right API, or how it behaves. Folks here: Is there anyone here from Brazil who has tested out this 26.4 API? Has anyone tested out the regulatory feature API? Does it return something like declaredAgeRangeRequired? I don't know how to test it in Brazil without sandbox/physically in Brazil. Much appreciated!!

I have an application which records video along with some custom metadata and a chapter track. The resultant video is stored in the Camera Roll. When sharing the video via the Share Sheet or AirDrop, the metadata track is stripped entirely (the chapter markers are preserved) Sharing via AirDrop with the "All Photos Data" option does include the metadata track, as does copying from the device with Image Capture but this is a bad user experience as the user must remember to explicitly select this option, and the filename is lost when sending this way. I have also tried various other approaches (such as encoding my metadata in a subtitle track, which I didn't expect to be stripped as it's an accessibility concern) but it's also removed. Essentially I am looking for a definitive list of things that are not stripped or if there's a way to encode a track in some way to indicate it should be preserved. The metadata is added via AVTimedMetadataGroup containing one AVMutableMetadataItem which has its value as a JSON string. I took a different approach with the Chapter Marker track (mainly because I did it first in a completely different way and didn't rework it when I added the other track). I post-process these after the video is recorded, and add them with addMutableTrack and then addTrackAssociation(to: chapterTrack, type: .chapterList) but I don't think that's the reason the chapter track persists where the custom metadata does not as other tests with video files from other sources containing subtitles etc also had their subtitle data stripped. tl;dr I record videos with metadata that I want to be able to share via Share Sheet and AirDrop, what am I doing wrong?

Hi, I’m seeing a strange TestFlight issue. My builds process successfully in App Store Connect, appear in TestFlight, and are assigned to internal testers, but installation fails immediately with: “The requested app is not available or doesn’t exist.” What I’ve verified: • builds are processed/completed • apps are visible in TestFlight • internal tester groups are configured • agreements/banking/tax are active This affects multiple apps in the same developer account. The issue started after adding a widget extension and moving to a new Swift-based workflow, so I’m trying to isolate whether this is: • signing/provisioning/entitlements • widget extension misconfiguration • or a backend issue on Apple’s side I’ve already contacted Apple Developer Support and submitted Feedback Assistant reports. Has anyone seen this exact behavior before?

Hello, Apple Developer Support Team, I registered for the Apple Developer Program using the Developer app on my Macbook. Payment and identity verification were completed successfully. Nevertheless, the phrase "Complete Your Purchase" still appears when I check in online, and my registration status is listed as Pending. Even though I've already finished the enrollment procedure, the system seems to be requesting me to do it again. I already have opened a case with Case ID: 102848342160 but had no response. Would you kindly check my account and let me know how my registration is going right now? I appreciate your help. Kind regards, Bua.

Our proposed solution to identify an app user when opening a website operated by app developer is: Apps sends a request to backed with app users auth header Backend fetches a generated authenticated url from website backend, based on users auth header App opens it in browser The browser journey is self contained within domain of the business. Would this interaction require an ATT request given that the users identity cannot be tracked back to the app user ? Thanks

I am trying to create an automation that will anable to add transactions to my app and it’s using a shared shortcut and a quick automation on the user end. it works great on the iPhone but i couldn’t find any way to make it work on my Apple Watch… any help with that?

Hi everyone, I’m honestly trying to understand what’s going on with the Family Controls API review process. I submitted my entitlement request on March 5, and as of today (March 19), there has been zero response. I also opened a support ticket on March 16, and that hasn’t received any response either. What’s confusing is that updates to another app on the same developer account were approved within days — so clearly the account is in good standing and active. At this point, it feels like there’s no visibility into what’s happening: Is the request under review? Is it waiting for additional information? Or is it just sitting in a queue indefinitely? I understand that Family Controls is a sensitive API, but a two-week silence with no status or communication makes it very difficult to plan or ship features. For those who’ve gone through this: How long did your approval actually take? Did you receive any communication during the process? Is there any reliable way to get visibility or speed this up? Right now, this is blocking a feature we’ve invested significant time building, and the lack of feedback is the most frustrating part. This is really giving me pain. Would really appreciate any insights.

We have 7 Advanced App Clip Experiences that have been stuck showing "Received" in the App Store Connect UI for 90+ days. However, after inspecting the underlying API response, we can confirm all 7 experiences show "key": "PUBLISHED", "doc_count": 7 on the backend. Despite this, scanning a QR code on a device without the app installed returns "App Clip Unavailable" on every experience. This appears to be a CDN propagation failure — the backend is PUBLISHED but the edge nodes serving iOS devices are returning stale or missing data. Evidence – – App Clip Diagnostics tool shows all green checks for our registered experience URLs (screenshots attached) – App Store Connect UI shows "Received" for all 7 experiences – Backend API response (/appclips/api/v1/experiences) shows: json"statuses": { "buckets": [ { "key": "PUBLISHED", "doc_count": 7 } ] } – iOS devices without the app installed still return "App Clip Unavailable" when scanning QR codes – App version 1.4(6) is live and Ready for Distribution – AASA file is correctly configured and verified – Bundle ID com.goodtrkr.pixlbankar.Clip is correctly associated. Business Impact – This is a production blocker for our AR platform (PixlBank[ar] — Good TRKR LLC). Our entire product delivery depends on App Clip invocation via QR code for enterprise clients. We have been engaged with Apple DTS for 90+ days: TSI Case-ID: 18681098 New Case-ID: 18880040 Feedback Assistant report filed with diagnostic screenshots and sysdiagnose provided no help. REQUEST –  Can an Apple DTS engineer confirm whether there is a known CDN propagation issue affecting App Clip Experiences that are in PUBLISHED state on the backend but not being served correctly to iOS devices? And if so, is there a way to trigger a cache flush or re-propagation for our specific experiences?