On a supervised device running iOS 18 without any AirDrop restrictions applied, when a profile with allowListedAppBundleIDs restriction key is installed, the AirDrop sound plays. But still the accept prompt does not appear, making it impossible to accept files. The prompt works as expected on iOS 18 devices to which the allowListedAppBundleIDs restriction is not installed. This issue occurs only on supervised iOS 18 devices to which the allowListedAppBundleIDs restriction is being applied. Device must be in iOS 18 version > Install the (allowListedAppBundleIDs restriction) profile with the device > Try to AirDrop files to the managed device. The expected result is that the accept prompt must pop up but it does not appear. This issue is occurring irrespective of any Whitelisted bundle ID being added to the allowListedAppBundleIDs restriction profile. Have attached a few Whitelisted bundle ID here com.talentlms.talentlms.ios.beta, com.maxaccel.safetrack, com.manageengine.mdm.iosagent, com.apple.weather, com.apple.mobilenotes, gov.dot.phmsa.erg2, com.apple.calculator, com.manageengine.mdm.iosagent, com.apple.webapp, com.apple.CoreCDPUI.localSecretPrompt etc. Have raised a Feedback request (FB15709399) with sysdiagnose logs and a short video on the issue.

Hello, We applied for the Apple Developer Enterprise Program because we develop internal mobile applications intended only for our employees. Our application was rejected without any specific reason being provided. We have opened multiple support cases through Apple Developer Support, but we have not received a response or clear guidance so far. We fully understand that the Apple Developer Forums may not be able to review or approve enrollment applications directly. However, we would appreciate guidance on how to escalate this issue to the appropriate Apple Developer Enterprise Program Enrollment Team. We are fully prepared to provide any required official documentation, institutional verification, authorization letter, MDM/distribution plan, or technical details. Program: Apple Developer Enterprise Program Use case: Internal employee-only applications Support case numbers: 102**946, 102*283, Thank you for your guidance.

Herkese merhaba, 19 Haziran 2026 tarihinde Apple Geliştirici Programı üyeliği satın aldım. Ödeme banka hesabımdan başarıyla tahsil edildi. 20 Haziran'da Apple'dan bir e-fatura ve siparişimin işleme alındağı söylemeden başka bir e-posta aldım. Ancak, Apple Developer hesabımda oturum açtığımda, hala “Enroll Today” düğmesini görüyorum. Hesabım ucretsiz bir geliştirici hesabına benziyor ve ucretli üyelik özelliklerine erişemiyorum. Satın alma işlemi için kullandığım Apple Hesabıyla oturum açtım. Üyelik ayrıca Apple Hesabımın abonelikler bölümünün altında da görünmüyor. Bu konuyu daha önce yaşayan var mı? Aktivasyon ne kadar sürdü ve bunu çözmek için ne yaptınız? Teşekkür ederim.

How control camera Zoom in and Zoom out from external remote by sending HID

My Enrollment ID: 74P7XBUXVP. I submitted the application on 25th May. The status remains ‘Pending’—'Your enrollment is being processed’, and I have not received any further instructions or payment link. The process is significantly impacting my project timeline. I don't have any contact to support via emails or otherwise. I would appreciate if the Apple Developer Enrollment Team review my case and find a resolution.

Hi, Need some advice on a broken enrollment loop. I registered as an individual in the UK last week. Since enrollment, I have: Day 1: Received the "Your order is being processed" email Day 2: Received the "Review your Apple Developer Program enrollment" email requesting ID verification, and I uploaded my ID as soon as I got the email Day 4: Received an invoice number and "your order has been confirmed" from Apple However, as I log on to developer.apple.com, the website is still stuck saying "To continue your enrollment, complete your purchase now", despite Apple having successfully taken payment from my card and processed the enrollment. If I click it, it attempts to loop me back into a transaction I have already completed. I opened a ticket (Case ID: 102910351530), but got no email response. Attempting to use the phone callback system has been impossible. I have also tried requesting callbacks during their UK (and Ireland) business hours on working days. Every time the system dials my phone, I ended up being placed on hold with the music without anyone actually taking the call. There was once I've even had to endure 4 hours straight on the call before I eventually had to hang up. I completely understand that WWDC is around the corner and support queues are likely heavily backlogged, but the callback loop seems fundamentally broken. A few questions: Is anyone else registering as a developer in the UK / Ireland experiencing the same issue? Is there a path to escalate the issue to human support? Case ID: 102910351530 Any insight or guidance from fellow devs or Apple moderators would be incredibly appreciated. Thank you in advance!

On my Apple Developer Account, all I see is "Your enrollment is being processed. Your enrollment ID is JYD86Q79DM." This has been ongoing for 4 weeks now. This is the first time I am enrolling to the program and need to know time it takes and if I am missing any steps? Please advise We are keen on uploading our app to the Apple Store but we need to begin testing asap and without the approval of our Dev account this is not possible. Is there any Apple verified team here to respond?

Case Number: 102905844463 I'm posting here in the hope that someone from Apple or the developer community can advise on the appropriate escalation path. Our Apple Developer Organization account appears to have been compromised approximately one week ago. The primary Apple ID associated with the account was info at tadarab.com. Prior to losing access, we received multiple unsolicited Apple verification code SMS messages. Shortly thereafter, Apple sent a security notification confirming that a new trusted phone number ending in **9794 had been added to the account. The original trusted phone number ending in **4346 was no longer being used for verification. Since then: We have completely lost access to the primary Apple ID. The original Apple ID is no longer recognized through Apple's account recovery process. Team members associated with the organization appear to have been removed. Developer certificates appear to have been removed. We can no longer access App Store Connect or the Apple Developer account. A support case was opened immediately after the incident. Unfortunately, after a week of communication, support has not yet addressed the reported account compromise and instead responded that they could not verify our association with the Developer Program membership—which is itself one of the consequences of the apparent takeover. My main concern is understanding how a trusted verification phone number could be changed and an entire Developer Organization account effectively taken over without the legitimate owner being able to prevent or recover from the change. Has anyone experienced a similar situation, and is there a recommended escalation path within Apple for Developer Organization account compromises? Any guidance would be greatly appreciated.

We found an issue where the DetailURL configured in a Declarative Device Management OS update declaration is displayed on the device’s Software Update screen, but tapping the link does not open the URL on some iOS versions. This issue appears to occur specifically on iOS 26.4. The same behavior could not be reproduced on iOS 17.x or iOS 18.x devices using the same MDM command configuration and the same URL. Environment: MDM command: Declarative OS Update command Command configuration: Target OS Version: 26.5 Build Version: 23F77 DetailURL: Appleデバイスのソフトウェアアップデート宣言型構成 - Apple サポート (日本) Device requirements: Supervised iOS device Managed by MDM Connected to Wi-Fi OS update available No Safari restriction or browser launch restriction configuration profile applied Reproduction Steps: Prepare a supervised iOS device managed by MDM. Send a Declarative Device Management OS update command with the following configuration: Target OS Version: 26.5 Build Version: 23F77 DetailURL: Appleデバイスのソフトウェアアップデート宣言型構成 - Apple サポート (日本) After the command is applied, open the device Settings app. Go to General > Software Update. Confirm that the URL configured in DetailURL is displayed on the Software Update screen. Tap the displayed URL. Expected Result: The displayed DetailURL should open in Safari or the default browser. Actual Result: On iOS 26.4 devices, the URL is displayed on the Software Update screen, but tapping the link does not open Safari or navigate to the URL. On other tested iOS versions, the URL opens correctly. Test Results: Reproduced / Not working: iPhone 15 Pro, iOS 26.4: reproduced 3/3 iPhone 17e, iOS 26.4: reproduced Not reproduced / Working: iPhone SE, iOS 17.7: Safari opens successfully iPhone 14 Pro Max, iOS 17.6.1: Safari opens successfully, 0/3 reproduced iPhone 12 Pro, iOS 18.7.7: Safari opens successfully iPhone 11 Pro Max, iOS 18.7.8: Safari opens successfully, 0/3 reproduced Additional Notes: We confirmed that Safari usage restrictions and browser launch-related configuration profiles were not applied on the affected test device. A sysdiagnose was collected from the affected iPhone 15 Pro running iOS 26.4. From the logs, it appears that the Settings app / Preferences attempts to open Safari, but the URL cannot be opened. The log suggests that an invalid or unexpected URL may be passed from the Settings app when the Software Update screen link is tapped. This issue does not appear to be specific to the MDM server implementation, because the same Declarative OS Update configuration works correctly on iOS 17.x and iOS 18.x devices. Based on current testing, this may be an iOS 26.4-specific issue with how the Software Update screen handles the DetailURL link.

We have a managed iOS app, distributed to managed iPhones through Apple Business Manager, and we are offering a TestFlight version. When users install a TestFlight Version, it is relatively quickly replaced by the current release. Is there a way to prevent this?

Requesting com.apple.managed-keychain Entitlement for Enterprise S/MIME Cert Visibility Platform: iOS | Distribution: MDM (Microsoft Intune) | Not App Store We are developing an internal enterprise iOS app (EMS Assist, com.company.supportcompanion) for Company deployed exclusively to Intune-managed devices. Our requirement: Read S/MIME certificates pushed to the device via Intune SCEP profiles to: Confirm cert presence in the MDM-managed keychain Read expiry date (kSecAttrNotValidAfter) to warn users before expiry Distinguish between missing, expired, and valid cert states What we have tried: Standard SecItemCopyMatching query — returns only app-installed certs, not MDM-pushed certs Graph API (deviceConfigurationStates) — confirms profile compliance but does not expose actual cert expiry or keychain presence Our understanding: com.apple.managed-keychain is required for an app to access MDM-managed keychain items on supervised devices, combined with a matching keychain-access-groups entitlement and the cert profile configured as "always available" in MDM. Questions: Is com.apple.managed-keychain the correct entitlement for this use case? Does it apply to SCEP/PKCS-issued certificates specifically, or only other MDM keychain items? Has anyone successfully accessed Intune-pushed S/MIME certs from an iOS app using this entitlement? Any guidance from the community or Apple engineers would be appreciated.

Hi, I have not received any communication for more than 5 days now in the request to be issued with D-U-N-S Number

Is system_profiler the recommended approach for retrieving installed application data on macOS? If not, what is the preferred and reliable alternative to fetch a consistent and complete list of installed applications?

I am writing to kindly request assistance regarding my Apple Developer Program enrollment. I submitted my application exactly one week ago, completed all required information, and successfully paid the $99 enrollment fee. I received a payment confirmation, but the status remains "Pending Approval" with no further updates or response from Apple. Could you please advise on the typical current processing time for Apple Developer Program approvals in 2026? Is a one-week waiting period normal, or should I take any additional steps?

Hello everyone, We’re currently facing an issue with an existing Apple Developer Organization account tied to our company. The original account holder is no longer accessible/unavailable, and our organization needs ownership transferred so we can continue deployment and App Store operations. Over the past ~4 weeks we have: Submitted a CEO-signed authorization letter Contacted Apple Developer Support multiple times via phone/email Had the case escalated to a senior technician/team Been told we would receive a callback within a week However, we still have not received follow-up communication or resolution, and our app launch is currently blocked because we cannot access the organizational developer account. We are considering temporarily enrolling under an Individual Developer account to continue deployment while the organizational escalation remains pending. A few questions: Has anyone successfully gone through a manual organizational account holder reassignment? What was the actual timeline for resolution? Is there a more effective escalation path to Developer Program Operations? Would enrolling as an Individual account create issues later when transferring the app back to the organization account? Any insight or recommendations would be greatly appreciated. Thank you!!!

Good afternoon! I registered a developer account. I paid for the account. It said, "Please wait 48 hours." The money was debited. Then I received a request to send a document. I sent my document, but I still haven't received a response. It's been more than a week. Then I submitted a support ticket, but I still haven't received a response. Ticket number 20000112618805. Please help me solve my problem.

We've put in a feedback assistant request, but not sure if we will get feedback in that channel or not and also want to highlight for others. When replacing a basic passcode profile on a macOS device with a passcode declaration, the user is required to change the password after logging out and back in. Explicitly including the "ChangeAtNextAuth" key set equal to false, set required a password change after logging out and back in. Once the declaration is active and the password has been changed, future updates to the passcode declaration do not require a password change unless the existing password is not compliant. Steps to reproduce: Install a basic passcode profile on a macOS device Ensure the existing password matches the requirements specified in the profile Install a passcode declaration with the same settings as the passcode profile currently installed Remove the traditional passcode profile from the device After the passcode declaration is installed, check the local pwpolicy with the command pwpolicy getaccountpolicies and look for the key policyAttributePasswordRequiredTime Log out of the macOS device Log back into the macOS device and you are presented with a change password prompt Expected result: Simply replacing an existing passcode profile with the exact same settings in a passcode declaration should not require a password change if the existing password is compliant. Actual results: After replacing the passcode profile with a passcode declaration, a password change was required even though the existing password was compliant. Initial testing was done with a macOS VM running 15.5. Additional testing has now been done with a macOS VM running 26.4.1 and the same behavior was observed.

เนื่องจากได้อ่านรายละเอียดเกี่ยวกับแล้วตรงและสิ่งที่เจอทั้งหมดหลังจากได้ทีการแจ้งไปเรื่องโดนแฮ็กข้อมูลและถูกโจรกรรมข้อมูลส่วนบุคคลทั้งหมด เจอสถานณ์ตรงตามส่วน คำเตือนเนื้อหาที่ละเอียดอ่อนทั้งหมด ตอนนี้สภาพจิตใจย้ำแย่เป็นอย่างมากและท้อใจอย่างที่สุดเพราะโดเดี่ยวสู้กับปัญหาและพยายามหาหลักฐานเพียงผู้เดียวซึ่งไม่เหลืแคนที่ไว้วางใจได้แม้แต่คนเดียว เพราะโดนใส่ร้ายทุกรูปแบบจนเสียงชื่อเสียงเหมือนกับผลักทุกคนออกไปจากชีวิตจนไม่เหลือแม้คนเดียวที่รับฟังทำให้พูดความจริงทั้งหมดไม่มีใครเชื่อและรับฟังแม้แต่คนเดียว เหตุที่แจ้งไปก่อนหน้านี้เป็นเวลาเกือบ 8 เดือนกว่าๆแล้วจนถึงปัจจุบันนี้ ยังไม่ได้รับกาคช่วยเหลือหรือไม่มีการช่วยเหลือใดๆทั้งสิ้น

If I have a macOS devices enrolled in MDM, with a DDM policy defined to deliver passcode settings to the device I can run: sudo pwpolicy -getaccountpolicies to see the configuration on the device. I can subsequently run: sudo pwpolicy -clearaccountpolicies Then all passcode policies applied in my declarations are cleared from the device allowing the user to set and use any password they want with no bearing on the delivered passcode settings. I have left my macOS devices for days on and off network and the pwpolicy data never returns. The passcode settings do not restore on the device until I do one of the following: manually re-push all declarations from MDM log off and log back on reboot the computer It was my understanding that DDM was meant to assess device state and self heal on its own without requiring an MDM service to re-push any commands. Based on this finding this seems broken or I may misunderstand how DDM is supposed to work. macOS version: 26.4.1

Hi, I’m looking for clarification on TN3134: Network Extension provider deployment, specifically iOS deployment requirements for: packet tunnel provider DNS proxy provider From the documentation: Packet Tunnel Provider App extension (min iOS 9.0): per-app mode requires a managed device DNS Proxy Provider App extension (min iOS 11.0): supervised devices only App extension (min iOS 11.0): per-app mode requires managed devices Issue I implemented a DNS proxy using NEDNSProxyManager. Works as expected in debug builds on a local device Fails to configure when distributed via TestFlight Console Output (TestFlight build) error 10:05:39.872258-0500 nehelper The production version of *** is not allowed to create DNS proxy configurations. Use MDM to create DNS Proxy configurations for the production version of ***. Question Is it possible to distribute a DNS proxy provider for use on non-MDM / non-supervised devices? If not: Is the limitation strictly enforced at distribution/runtime? Is a packet tunnel provider the only viable alternative for App Store distribution? There is a lot of different VPN apps on the App Store that appear to work out of the box without MDM or supervision, which suggests they are using a different deployment model. Thank you for any clarification or guidance!