“Apple Maps Guides”

i [want] to determine ip address of guest os without any cooperation from guest. Thanks for confirming that. This is a fundamentally tricky problem to solve, at least in the general case. The guest chooses how it’s going to assign IP addresses to an interface, and the host has no direct control over that choice. However, there may be an indirect way to do this: Virtualization framework lets you create a network that’s backed by a vmnet network (VZVmnetNetworkDeviceAttachment). vmnet framework lets your configure a network with a specific DHCP mapping (vmnet_network_configuration_add_dhcp_reservation). There are some significant caveats: The guest must default to using DHCP. You can’t support bridged mode (VMNET_BRIDGED_MODE), because in bridged mode the guest isn’t talking to the vmnet DHCP server. This is all new in macOS 26. But otherwise I think it’ll work. So please try it out and let me know how you get along. ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten D

We're experiencing the same issue and wanted to add our voice to this thread. Our app also has the Contactless Pass Provisioning capability approved and has been working fine for a long time, but we started seeing the exact same Ineligible profile error a couple of days ago — without any changes on our end. We've confirmed that the entitlement (com.apple.developer.contactless-payment-pass-provisioning) is present in the downloaded provisioning profile, and the capability is still enabled in the Developer Portal. Despite that, Xcode continues to mark our profiles as ineligible. This is now blocking us from releasing an important bug fix to our customers. We'd really appreciate any update on the timeline for a resolution. Is there anything we can do in the meantime to work around this, or should we simply wait for a fix on Apple's side? Thank you for escalating this internally.

Lemme start you out with Understanding NEHotspotConfigurationErrorInternal. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I think you should file a bug about this. It’s hard to be sure exactly what’s going on, but your description certainly sounds like there’s an issue on the Apple side of the fence. Please post your bug number, just for the record. I have some general advice about filing Wi-Fi bug reports in… ah… Filing a Wi-Fi Bug Report. In this case, however, I recommend that you also install the Accessory Setup Kit for iOS/iPadOS debug profile, available from our Bug Reporting > Profiles and Logs page. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='822120021, AntonPastrevich, /thread/822120, /profile/AntonPastrevich'] We've filed FB22448572 for this [/quote] Thanks. That’s the best path forward for this. [quote='822120021, AntonPastrevich, /thread/822120, /profile/AntonPastrevich'] Is there a known issue with securityd’s keychain authentication after 26.4? [/quote] Well there is now that you’ve filed a bug about it (-: Seriously though, as I mentioned on that other thread you found, macOS 26.4 has significant changes to how we unlock the login keychain. In that thread, the developer is doing something unusual, and it’s not clear what the right path forward is. But in your case my understanding is that you’re doing something pedestrian — accessing a keychain item from early in your app’s lifecycle — and that makes the path forward clear: File a bug so that the keychain team can investigate. Which is what you’ve done (-: [quote='822120021, AntonPastrevich, /thread/822120, /profile/AntonPastrevich'] Would migrating to the data protection keychain …

It looks like you’re trying to report a bug. If so, the best place to do that is in Feedback Assistant. See Bug Reporting: How and Why? for lots of hints and tips for that process. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='883809022, Mingmiu, /thread/822198?answerId=883809022#883809022, /profile/Mingmiu'] I reported it as FB22333352 [/quote] Thanks. That’s definitely the right path forward for this. IMPORTANT I noticed that you didn’t attach a sysdiagnose log to your bug report. Even though this problem is easy to reproduce, a sysdiagnose will help with the routing of your issue internally. So please reproduce the problem, trigger a sysdiagnose log, and then attach it to this bug. For more information about sysdiagnose logs, see Bug Reporting > Profiles and Logs. For context, that alert says: 允许 “testNetwork”使用无线 数据？ 关闭无线数据时，部分功能可能无法 使用。 [无线局域网与蜂窝网络] [仅限无线局域网] [[不允许]] A machine translation is: Allow testNetwork to use wireless data? When wireless data is turned off, some functions may not be available. [Wireless LAN and Cellular Network] [Wireless LAN only] [[Now Allowed]] This alert only shows up if the iPhone was bought in China, where iOS gives the user the option to control an app’s access to Wi-Fi (normally the

Hello Apple Developer Support, I subscribed to the Apple Developer Program and the payment was charged successfully, but my account is still showing “Pending – Subscribe your membership.” I haven’t received any confirmation email yet. Order number: W1374779571 Could you please check the status of my subscription? Thank you,

@ssmith_c took the words out of my mouth - as a phone is not a dedicated central device that only communicates wth your accessory, it will not accept parameters that is not suitable for itself at the time. So you may see the same parameters accepted once, and rejected later. As for the parameters being compliant, they are not correct. It is missing the rule: Interval Max * (Peripheral Latency + 1) LESS THAN 6 seconds. With your settings that value is 18 seconds. You may have mistaken the peripheral latency to be the time, but actually it is supposed to be the number of connection intervals. The minimum latency you can request with your connection interval selections is 60ms, by setting the latency value to zero. General connection parameter request guidelines: Peripheral Latency ≤ 30 connection intervals. Supervision Timeout from 6 seconds to 18 seconds. Interval Min ≥ 15 ms. Interval Min ≤ 2 seconds. Interval Min is a multiple of 15 ms. One of the following: Interval Max at least 15 ms greater than Interval