Overview

hello, i have an issue spawning continued background processing tasks: they are never started, even after restarting the device, regardless of which app spawns a task. deleting and reinstalling an app, or installing a new app that didn't exist before also does not work. it can be reproduced by setting your device local time to one year in advance and then trying to spawn the task. the task will not start and even after returning to the proper date, all apps on the device are still unable to spawn any. i also believe there are other things that trigger this issue (or something related), as many of my users have complained about tasks not starting. prior to my changing the date of my device, they worked perfectly for me. one user changed their date to test at the same time as me and the only fix they found was erasing their device and restoring a backup. on ios 26 tasks fail silently, but on ios 27 with the new api to submit a task, an error is caught: Error Domain=BGTaskSchedulerErrorDomain Code=1 "connection to service with pid 94 named com.apple.duetactivityscheduler" UserInfo={NSDebugDescription=connection to service with pid 94 named com.apple.duetactivityscheduler} in addition, a more detailed error with a stack trace is logged at the same time: <NSXPCConnection: 0x10c60c0a0> connection to service with pid 94 named com.apple.duetactivityscheduler: Exception caught during decoding of reply to message 'submitTaskRequest:withHandler:', dropping incoming message and calling failure block. Ignored Exception: Exception while decoding argument 0 (#1 of invocation): <NSInvocation: 0x10c6d72c0> return value: {v} void target: {@?} 0x0 (block) argument 1: {@} 0x0 Exception: value for key 'NS.objects' was of unexpected class 'NSSet' (0x20620c358) [/System/Library/Frameworks/CoreFoundation.framework]. Allowed classes are: {( "'NSDate' (0x20620c268) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSError' (0x2061fd3b0) [/System/Library/Frameworks/Foundation.framework]", "'NSNumber' (0x2061fd478) [/System/Library/Frameworks/Foundation.framework]", "'NSData' (0x20620c650) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSArray' (0x20620c6c8) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSString' (0x2061fd428) [/System/Library/Frameworks/Foundation.framework]", "'NSDictionary' (0x20620c538) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSURL' (0x20620c678) [/System/Library/Frameworks/CoreFoundation.framework]" )} ( 0 CoreFoundation 0x000000019fbc2e0c 43092235-E272-3CAF-B9AE-76669EC5AE46 + 622092 1 libobjc.A.dylib 0x000000019f940298 objc_exception_throw + 88 2 Foundation 0x00000001a002beac E642F95D-61DA-3E8C-A2D2-CFEB7F7B688B + 126636 3 Foundation 0x00000001a0035090 E642F95D-61DA-3E8C-A2D2-CFEB7F7B688B + 163984 ...

Context: While fuzzing my encrypted messenger Kalego, I noticed a single core pinned at 100% for over an hour while the other nine sat idle. No crash, no error. I sampled the thread with the macOS sample tool and found the culprit: a global runtime hook intercepting every single throw. Root Cause: The Swift runtime exposes a writable pointer _swift_willThrow. Apple's test frameworks install their own observers into this slot. On every throw, XCTest bridges the Swift error to an autoreleased NSError, captures the call stack, and accumulates it in memory until the end of the test method. The Numbers (Measured on M5, Swift 6.3.3, Release): Plain Executable: 20.5 ns / iteration Swift Testing: 295 ns / iteration (14x slower) XCTest: 749 ns / iteration (36x slower) XCTest under xcodebuild/CI: ~1100 ns (54x slower) The Real Defect (Memory Leak): It's not just slow. Under XCTest, each observed throw leaks ~2.1 KB of memory. 2,000,000 throws in a single test method cost +4,031 MB. At fuzzing scale, this turns a slow test into an instant Out-Of-Memory crash. The Fixes: Move the hot loop to a standalone executable (best for fuzzing). Use return nil instead of throw on hot paths. Wrap the loop body in autoreleasepool { } to stop the memory leak. (Advanced/Situational) Safely disable the observer using dlsym and defer (code provided in the full report). Full Report & Reproducible Code: I wrote a complete 12-page report with 21 experiments, the assembly disassembly, and all the reproduction code. You can check the numbers on your own machine here: https://github.com/MagicYassin/xctest-throw-cost Appreciate any technical feedback👨🏻‍💻☁️☁!

On macOS 27.0 seed 6 (26A5421a) / Xcode 27 beta 6, the first touch of AssetPackManager.shared in a Managed Background Assets macOS app fatals at AssetPackManager.swift:360 with The app couldn't be validated: The app group with the ID "TEAMID.group.example.app" is inaccessible — with the app signed with exactly that group, BAAppGroupID matching, containerURL(forSecurityApplicationGroupIdentifier:) returning a real directory, and the container present on disk. I tried varying it and got the same result: App Sandbox on/off; the group spelled team-prefixed and iOS-style at every point of use. Notably, in the iOS-style build the message still names the team-prefixed identifier, which appears nowhere in that build — so the framework composes the prefixed form itself and validates that. The Mac provisioning profile authorizes group.example.app explicitly plus the auto-added TEAMID.* wildcard, and since the portal only registers group.-style IDs, no profile can list the prefixed form by name. Is this a known issue in seed 6? Is there a workaround? And does Managed Background Assets on macOS assume a Mac App Store / TestFlight distribution context for its app-group validation, in a way a development-signed app can't satisfy? Filed as FB24525451 with three crash reports (sandboxed, unsandboxed, iOS-style) and a sysdiagnose.

A paged ScrollView loses its page when the window is resized on iPadOS 27: ScrollView(.horizontal) { HStack(spacing: 0) { ForEach(pages) { page in PageView(page).containerRelativeFrame(.horizontal) } } .scrollTargetLayout() } .scrollTargetBehavior(.paging) .scrollPosition(id: $selection) Expected: the selected page stays edge-aligned after the resize (as TabView(.page) does). Actual: The content offset is preserved in points, not pages — the view rests between pages. scrollPosition(id:) writes nil during the resize, so the selection can't be recovered from the binding. Both .paging and .viewAligned are affected. Repro project (broken ScrollView, TabView control, and workaround side by side, with live instrumentation): https://github.com/katebrr/PagedScrollResizeLab Why not TabView(.page): it has no API for scroll position/progress observation (our analytics depend on it), inter-page spacing, partial-width peeking pages, or pausing the swipe mid-gesture. Workaround (Workaround/View+ScrollPositionResize.swift in the repo): restore the last non-nil selection via scrollTo one Task.yield() after the resize. Works, but lands a frame late and relies on undocumented behavior. Questions: Is this behavior intended, or a bug? Is there a supported way to keep a paged ScrollView anchored to its page across resizes? Is there a more robust formulation than scrollTo after Task.yield()? Filed as FB24688033.

Inquiry) A Linux-based embedded device is connected to an iPhone using a USB-C cable. The device operates as a USB device and presents a standard CDC-ECM Ethernet interface. The iPhone operates as the USB host. When the iPhone screen is on: 以太网接口被正确识别。 分配IPv4和IPv6地址。 互联网接入正常。 大约在 iPhone 被锁定 30 秒后，USB 连接进入暂停状态，以太网数据传输停止。 我们启用了USB远程唤醒。定期触发它有助于保持以太网接口的可用，当 iPhone 屏幕开启时网络会恢复。然而，屏幕关闭时以太网数据仍然无法保持活跃状态。 问题） 这在iOS上是正常的行为吗？ 有没有支持的方法可以在 iPhone 锁定时保持 USB 以太网数据活跃？ USB远程唤醒是否支持输入网络流量？ 助理在恢复后是否需要发送任何CDC链接通知？ 这需要支持MFi还是特定的iOS权限？ 谢谢。

A sandboxed Mac app with correct CloudKit entitlements fails to connect to com.apple.cloudd (the CloudKit daemon) when distributed via TestFlight (Mac Team Store Provisioning Profile). The identical binary works correctly when launched from Xcode (Mac Team Provisioning Profile also present). All entitlements are correctly embedded and the App ID is properly configured in Apple Developer Portal. Environment macOS 26.5.1 (25F80) Xcode 26.5 (17F42) SwiftData with NSPersistentCloudKitContainer / ModelConfiguration(cloudKitDatabase: .private(...)) Steps to Reproduce Create a sandboxed Mac app using SwiftData with CloudKit sync Enable iCloud + CloudKit in Signing & Capabilities Archive and distribute to TestFlight (Mac Team Store Provisioning Profile) Install via TestFlight on macOS 26 and launch Check Console for kernel sandbox messages Expected Result CloudKit connects to com.apple.cloudd and syncs data, matching behavior of the iOS version using the same container. Actual Result Console shows repeated kernel sandbox denials followed by CloudKit setup failure: kernel Sandbox: CheatSheet Mac(82347) deny(1) mach-lookup com.apple.cloudd kernel Sandbox: CheatSheet Mac(82347) deny(1) mach-lookup com.apple.duetactivityscheduler CheatSheet Mac CoreData+CloudKit: Failed to set up CloudKit integration for store Error Domain=CKErrorDomain Code=6 "Error connecting to CloudKit daemon." Key Diagnostic Finding When launched from Xcode, taskgated-helper validates both the Mac Team Store Provisioning Profile AND the Mac Team Provisioning Profile, and CloudKit succeeds: cloudd: TCC approved access for container containerID=iCloud.com.michaelendres.CheatSheet:Production When launched from TestFlight, only the Mac Team Store Provisioning Profile is present, and the sandbox denies com.apple.cloudd despite identical entitlements in the binary: codesign -d --entitlements shows: com.apple.developer.icloud-services: [CloudKit] com.apple.developer.icloud-container-identifiers: [iCloud.com.michaelendres.CheatSheet] com.apple.developer.icloud-container-environment: Production com.apple.security.app-sandbox: true Conclusion The Mac Team Store Provisioning Profile on macOS 26 does not appear to grant the sandbox exception for mach-lookup com.apple.cloudd, while the Mac Team Provisioning Profile (development) does. This prevents any Mac App Store / TestFlight app using CloudKit from syncing on macOS 26.

I have a watchOS app on a cellular Apple Watch (Series 11, watchOS 26.6) that periodically uploads small HTTPS payloads to a backend. It needs to keep working when the paired iPhone is absent and the watch is on its own cellular connection. What I observe: Foreground, no phone, cellular: uploads work. Background, no phone, cellular-only (no Wi‑Fi): nothing uploads for hours. The instant the watch joins Wi‑Fi (app still in background): the whole backlog flushes at once via my background URLSession. My questions: Is a background URLSession transfer over cellular ever expected to run without Wi‑Fi (e.g. while charging), or is Wi‑Fi effectively required in practice? Any configuration that improves the odds? 2. During an active HKWorkoutSession (which keeps the app executing), will a high-level URLSession data task reliably complete over cellular with the phone absent? And is using a workout session to keep a non-fitness background uploader alive acceptable, or is there a sanctioned alternative? 3. Is there any other supported mechanism for periodic background cellular upload from a phoneless watch that I'm missing? Any help would be greatly appreciated. Thank you!

My domain vendezo.com is completely clean on Google Safe Browsing and VirusTotal, but Safari still shows a Deceptive Website Warning. Request through websitereview.apple.com was ignored. Please help

I am using an 11-inch M4 iPad Pro. I first noticed severe battery drain while the iPad was idle. After checking the device, I found that several unrelated functions had stopped working at the same time: Front and rear cameras show a black screen Face ID does not work LiDAR does not work Flashlight does not work Apple Pencil is not detected, paired, or charged through the magnetic charging area Apple Diagnostics at the Genius Bar also reported failures involving the front camera, rear camera, Face ID, and LiDAR. I was told at the Genius Bar that, because the device is outside the standard warranty period, it would be treated as an out-of-warranty hardware failure and would not qualify for free repair. There has been no drop or liquid damage. I have already performed multiple force restarts, updated iPadOS, and factory-reset the device several times, but the symptoms remain unchanged. What seems unusual is that several functionally separate systems became unavailable at nearly the same time, together with severe standby battery drain. Because of that, I am wondering whether this could be related to embedded software, firmware, power management, or low-level hardware control rather than several independent hardware components coincidentally failing at once. Has anyone seen a similar issue on an M4 iPad Pro, or is there any known firmware or system-level failure that could cause this pattern?

Hi all, My app has been stuck in the "Waiting for Review" status since August 13 (US Time), and today is August 23. It has been 10 days without any status updates or messages from the App Review team. App ID: 6800282515 Submission Date: Aug 13, 2026 Developer Support Request Submitted: Aug 19 (No response yet) Expedited Review Requested: Aug 20 (No response yet) Current Status: Waiting for Review Since both support inquiries and expedited requests haven't received a reply after several days, I am concerned there might be an internal system hold or communication breakdown regarding this submission. Could someone from Apple please look into this or advise if any additional documentation/action is needed from my side? Thanks for your help!

Hi everyone, I’m looking for some clarification regarding Privacy Manifest requirements (PrivacyInfo.xcprivacy) after resolving a validation issue on my latest submission. In my previous build, I ran into an issue related to NSPrivacyTracking and NSPrivacyTrackingDomains. I updated the manifest to ensure NSPrivacyTracking is set to <true/> alongside our App Tracking Transparency (ATT) prompt, and restricted NSPrivacyTrackingDomains strictly to the required ad service endpoints (googleadservices.com, googlesyndication.com, doubleclick.net, etc.), removing any broad domains. I have just submitted the corrected build: • App Name: Girls vs Boys Tapping • Version: 1.1.2 • Build: 112 • Apple ID: 6809284204 • Status: Waiting for Review Since this is my first time submitting with the updated privacy manifest format after resolving that error, my question is: Once the build enters the review queue with these specific tracking domains and ATT configured, does App Review require any additional documentation in the review notes regarding the ad network tracking domains, or is the .xcprivacy file inside the bundle sufficient for automated validation and review? Just want to make sure everything is 100% in order so there are no unexpected hold-ups while it's in the queue. Thanks in advance for any insights!

We have a password entry field with a "show password" button. The button effectively turns the "secure text entry" textfield into a non-secure text entry field allowing the user to view what they typed in. When VoiceOver is enabled, I am not including that button in the UI; it doesn't seem to make sense to me for the following reasons. If you properly test with the screen curtain, the functionality is useless. You don't see anything. I've tried to explain this to my accessibility team. It's also quite ridiculous to offer to show a blind user their password, I'm sure they'd love to see it, but they just can't. This would almost seem insulting as well. If by toggling that button, and turning a secure text entry into a non-secure text entry, now the app is literally speaking their password aloud. This seems like a security vulnerability to me. What if someone else overhears the password spoken aloud. The accessibility team is insisting that I need to include the "show password" button when VoiceOver is enabled. This is the response I received. "functionality should be the same for VI users as for sighted users. It may happen that a VI user wants to check what is typed into password field in order to correct mistakes". Again, I don't agree with that because functionality should not be the same. Functionality should be changed and altered as necessary to make the user experience as accessible as possible. And in this scenario, to me the functionality doesn't make sense at all in a VoiceOver setting. Any thoughts on this? Am I incorrect here? Are there benefits of including a "show password" button to a user utilizing VoiceOver? What should then the functionality be? Speak the password aloud? Thanks.

Hi, My first app has been stuck since 14 August. App Review asked for more information. I sent it all back the same day. An hour later they replied: "Thank you for providing this information. We will continue the review, and we will notify you if there are any further issues." That was three and a half weeks ago and I have heard nothing since. I asked in the same thread on 2 September, no answer to that either. It still says Unresolved Issues and I haven't touched the build or the metadata since 14 August. So five weeks after submitting I'm sitting here with an app I can't release and nobody answering. It's getting to me, I won't lie. How do you get a submission unstuck? Is there anything I should be doing on my side? BlissGuru, Apple ID 6793882449, submission ID f3b964a4-7fdd-4190-9958-db93fc19958e, submitted 31 July. Thanks, Vincent

Hi, I’m hoping someone here has come across this before, because I’ve pretty much run out of options with Developer Support. I’ve been trying to enrol in the Apple Developer Program for quite a while. After a lot of back and forth, Apple eventually told me the problem is that my trusted device or 2FA phone number is associated with several other Apple Accounts. I can understand how this might have happened. I’ve been using Apple products for years and I’ve helped family, friends and other people set up and troubleshoot their Apple devices over that time. Some of these associations could be years old. The problem is that Apple understandably won’t tell me which accounts are involved because of privacy. I don’t have a problem with that and I’m not asking for anyone else’s account information. But it leaves me stuck. I’ve basically been told that I need to remove my details from those accounts, while at the same time there’s no way for me to know which accounts they are. Developer Support have now told me they’ve gone as far as they can with it. I’m quite happy to prove who I am. I have an Australian passport, I can verify my current phone number and devices, and I’m happy to provide whatever other identification Apple needs. I also noticed Apple’s identity verification documentation says to contact Support if you need to verify your identity using a method other than the Apple Developer app. I’ve asked about this, but so far I haven’t been able to find anyone who can actually move the enrolment forward. I’m not trying to get around Apple’s security. I just need some way of proving that I am who I say I am when the normal enrolment system can’t do it. I already have a fairly extensive Developer Support case for all of this, which I’m happy to provide privately to Apple staff if needed. Has anyone else run into this? Or, if someone from Apple sees this, is there another team or a manual verification process that Developer Support can refer this to? Thanks, Tom

Team: TS447Y97LA Please help identify the underlying failure for two automatic Xcode Developer ID submissions: a904af7c-751d-4e79-9f16-f71f16163ad5 — received SHA-256 a185ebe3860985d0e5f6a07e00348008687a636731a88033d620e3cb3f9ec6aa, 9,454,788,726 bytes. 1f55d5d3-f96f-47d5-ba91-b7372c213ad7 — received SHA-256 efe2aaa7c3714c68d82d4efc1eab9f14c9cc0751ef78c9b3a0856f1b53757ece, a fresh signing/export attempt. Both logs return Invalid/4000 and name these arm64 paths: Pelican.app/Contents/MacOS/Pelican Pelican.app/Contents/XPCServices/PelicanInference.xpc/Contents/MacOS/PelicanInference For the first submission only, we retained the exact Xcode upload ZIP and submitted app. Independent full comparison confirmed the received hash, all 117 ZIP members, and every app resource and metadata entry. There are 115 matching app entries plus two consistent Apple ZIP metadata entries. Python and installed libarchive independently reproduce identical bytes, CRCs, types and permissions. Raw local/central records, ZIP64 values, ranges and footer are consistent; there are no data descriptors or symlinks. The extracted host and all three XPC services pass deep, strict, all-architecture local codesign verification with exact Apple/Team/Developer-ID requirements. Earlier retained code-page, CMS and timestamp-binding diagnostics also passed. These local checks do not override the notary result. The second submission has not received the first submission's full independent ZIP comparison. The inference model contains one 5,349,771,222-byte stored member requiring ZIP64 sizes. Later Methods and host metadata also require ZIP64 offsets. We have not established this as a cause, or inferred success for code parts absent from the issue list. Which exact object and verifier stage failed: the named Mach-O CodeDirectory/CMS, an enclosing resource seal, or archive extraction? Is there a specific error code or documented resource-size limitation relevant to this member? If more evidence is needed, what is the smallest targeted diagnostic? We saw the workflow guidance about excluding huge data from notarization and would like to know whether it applies here before changing the distribution. The separate inert public carrier job, 9e033029-3914-436d-992b-96bd261637de, is now Accepted. At 2026-09-07 18:32 UTC, its exported app passed strict local verification, stapler validation and Gatekeeper assessment as Notarized Developer ID. This confirms the small control succeeded; it does not establish why the larger app failed. The full product remains Invalid. The proposed attachment contains the two issue logs, complete member/hash records, four-part size/signature map and a short result summary. No models, apps, profiles, certificates, credentials, account logs or system diagnostic are attached. The original artifacts can be discussed if a specific follow-up is needed.

Hello, I'm developing Verde, a Matter irrigation system (soil moisture sensors, a hub, and a multi-valve irrigation controller). My question is about Matter device type support in Apple Home, not about hardware or commissioning. The failure: when an endpoint declares certain device type IDs, Home refuses to create the accessory and reports that the device is not supported. Change nothing but the device type ID, and the same accessory is created and works. So this is Home rejecting a device type, not a pairing, discovery or hardware problem. Water Valve — 0x0042 Device type 0x0042 Water Valve (Matter 1.3) Cluster 0x0081 Valve Configuration and Control Result in Apple Home Not supported — accessory is not created Result on other Matter controllers Created and controllable Substitute we now ship: device type 0x010A On/Off Plug-in Unit with cluster 0x0006 On/Off. Accepted by Home immediately, and toggling the endpoint operates the valve. The substitution works but is a misrepresentation: the user sees a row of "plugs" for a device that controls irrigation valves. There are no valve semantics, no open/close vocabulary, and nothing tells Home — or an automation the user writes — that switching this on releases water. Soil Sensor — Matter 1.5 Device type Soil Sensor / soil measurement, introduced in Matter 1.5 Result in Apple Home Not available Substitute we now ship: 0x0307 Humidity Sensor with cluster 0x0405 Relative Humidity Measurement, because that is what Home renders. Soil moisture therefore appears in Home as air humidity — conceptually wrong, wrong icon, and it contaminates any humidity-based automation the user has set up. The CSA positioned the 1.5 soil types explicitly for irrigation use with Matter water valves, so the two gaps above are the same gap for us. Multi-endpoint valve controller — composition Our controller is a single accessory exposing seven independently controlled valve endpoints (endpoint IDs 1–7). Endpoints exist only for valves the installer has enabled, so the composition can legitimately change after a configuration change. Two questions on this: Changed composition isn't picked up. When an endpoint is removed, Home keeps showing it until the accessory is deleted and re-added. Is there a supported way to make Home re-read a device's composition in place? Preferred shape. For seven valves, does Apple prefer one accessory with seven endpoints, or a Bridge (0x000E) exposing seven separate accessories? 4. What we're asking Is Water Valve 0x0042 planned for Apple Home, and is there a timeframe we can plan to? Is the Matter 1.5 Soil Sensor device type planned? Until then, is substituting On/Off Plug-in Unit for a valve, and Humidity Sensor for soil moisture, acceptable to Apple? We'd rather follow your guidance than ship a misrepresentation we later have to undo — and than have a valve presented to users and automations as a plug. For a multi-endpoint valve controller: guidance on composition, and on refreshing a changed endpoint list in Home. Is there an authoritative, current list of the Matter device type IDs Apple Home accepts, more specific than the general support article? Designing against it is far cheaper than building an accessory and discovering Home will not create it.

Regarding the 'weight list' of Siri: can you all provide technical specifics on how a model qualifies for this list, and can a developer-supplied model/adapter ever handle requests that originate from the system-wide Siri interface?

I'm building a Matter irrigation system and I've hit a device-type wall in the Home app. This is not a commissioning or pairing problem - the accessory is found, setup proceeds, and then Home declines to create the accessory, reporting that the device is not supported. The controlled comparison, which is why I'm confident it is the device type and nothing else: Endpoint declares 0x0042 Water Valve (Matter 1.3) with cluster 0x0081 Valve Configuration and Control -> Home: NOT SUPPORTED, accessory is not created. Endpoint declares 0x010A On/Off Plug-in Unit with cluster 0x0006 On/Off -> Home: created, works, valve opens and closes. Same hardware, same firmware image, same network, same iPhone. The only variable is the device type ID. Other Matter controllers accept the 0x0042 version and control it correctly. Water Valve (0x0042) - is this device type supported by the Home app in any current or announced iOS version? If not, is support planned? Right now I ship the plug-in-unit substitution because it is the only thing Home will accept. It works, but it misrepresents the device: the user sees a row of "plugs" that are actually irrigation valves, with no valve semantics and nothing telling Home - or an automation the user writes - that switching this on releases water into a garden. Soil Sensor (Matter 1.5) - same question. Matter 1.5 added soil sensing (moisture, optionally temperature), explicitly positioned for irrigation paired with Matter water valves. Is it supported or planned in Home? Today I publish soil moisture on a Relative Humidity Measurement endpoint (0x0405) because that is what Home renders, so garden soil moisture appears as air humidity and pollutes any humidity-based automation the user has. The general question, which is the one I actually want answered: is there an authoritative list of the Matter device type IDs the Home app accepts? The public support article describes categories in prose (lights, plugs, switches, thermostats, sensors...), but gives no device type IDs, so there is no way to check a design against it before building. I would like to design to the list rather than discover at pairing time that Home will not create my accessory. A related composition question: my controller is a single accessory with seven independently controlled valve endpoints, and endpoints exist only for valves the installer has enabled. When a valve is disabled and its endpoint disappears, Home keeps showing it until the accessory is removed and re-added. Is there a supported way to make Home re-read a device's composition in place - and for seven valves, does Apple prefer one accessory with seven endpoints, or a Bridge (0x000E) exposing seven accessories? Setup: Matter over Wi-Fi (2.4 GHz), esp-matter / connectedhomeip, test VID 0xFFF1 during development. iOS 17 and 18, iPhone 12, Home hub present. Happy to provide the full endpoint and cluster composition or logs if useful.

I am trying to add testers to External Tester groups for a couple of our iOS apps and after adding them it shows "No Builds Available". This is despite the app being available to that External Tester group with other people having already installed the latest version of the app which is "Available" and not expired. Can someone please fix this? It is so frustrating the number of times I try and release apps to TestFlight and there's some issue blocking me, completely out of my control and I have to rely on someone at Apple fixing something on this terrible AppStoreConnect system.

Hello, I’m looking for guidance regarding an Apple Developer Program enrollment issue that has remained unresolved despite multiple contacts with Apple Support. I enrolled as an Individual and successfully paid the $99 Apple Developer Program membership fee. The payment was charged and I received an official Apple invoice. Initially, Apple Developer Support informed me that my membership had been successfully purchased and activated and showed the membership status as Processed. Shortly afterward, however, I received another message stating: “For one or more reasons, your enrollment in the Apple Developer Program couldn’t be completed.” I contacted Developer Support under: Case 20000136025222 Developer Support subsequently indicated that the issue appeared to be related to my Apple Account and directed me to Apple Support. I contacted Apple Support directly and successfully completed Apple Account verification. The Apple Support advisor could not identify why Developer Support had redirected the enrollment issue to them. I then attempted enrollment again through the official Developer website. Immediately after selecting Individual / Sole Proprietor and clicking Continue, I receive: “Your enrollment could not be completed. Your enrollment in the Apple Developer Program could not be completed at this time.” No request for identity documents or additional verification is presented. I also have another Developer Support case: Case 20000142610492 At this point, I would appreciate guidance from Apple Developer Support on whether my enrollment requires a manual identity/compliance review or additional Developer identity verification. I am fully prepared to provide my passport, government-issued identification, payment invoice, or any other required documentation through Apple’s secure verification process. Could Apple Developer Support please review or escalate these cases to the appropriate Enrollment/Membership team or Senior Advisor and advise what specific verification or action is required from my side? Thank you.