Apple Maps Guides

[quote='815498021, Pushpak-Ambadkar123, /thread/815498, /profile/Pushpak-Ambadkar123'] URL Filter Network … is only for Enterprise level or MDM or supervised device. [/quote] That’s not right. You are mixing up URL filters with content filters. URL filters have strong privacy fundamentals and thus have no deployment limitations. In contrast, content filters have significant deployment limitations. See TN3134 Network Extension provider deployment for all the details. [quote='815498021, Pushpak-Ambadkar123, /thread/815498, /profile/Pushpak-Ambadkar123'] When trying to run sample project in the simulator [/quote] The simulator uses the macOS networking stack, so you can’t test low-level networking facilities there. You’ll need to test this on a real device. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This isn’t something we can help you with here on the forums. Rather, you need to seek help via official channels. For the details, see this post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The specific thing you’re looking for — distributing iOS apps to arbitrary devices not through an Enterprise team — is not possible. As you’ve noted: Developer ID is a Mac thing. Ad Hoc distribution is limited to a specific set of devices. One alternative path is to put the app on the App Store but limit who can buy it. See the discussion of custom apps on Distributing Apps on Apple Business Manager and Apple School Manager Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The Apple sample code Landmarks project uses a LazyVStack inside a ScrollView. For a List, which you want, you will need to: Put the ContainerView in the List as the first row. Set the listRowBackground of the ContainerView to EmptyView(). Set the listStyle to plain, for listRowBackground to work. Add .background(alignment: .top) { with the background you want for the ContainerView. Use readFrame() to dynamically adjust the height of the background to match the maxY position of the ContainerView. import SwiftUI struct ListHeaderScene: View { @State var headerRect: CGRect? var headerHeight: CGFloat { headerRect?.maxY ?? 0 } var body: some View { List { ContainerView() .readFrame { headerRect = $0 } .listRowSeparator(.hidden) .listRowBackground(EmptyView()) Section(Section Title) { Text(Row 1) Text(Row 2) } } .listStyle(.plain) .background(alignment: .top) { // You can swap this for an image or whatever. Color.purple .frame(height: headerHeight) .ignoresSafeArea() } } } struct ContainerView: View { var

Same issue for me. Any clues on how to resolve it anyone or we just have to wait for Apple?

hi @DTS Engineer In feedback ID https://feedbackassistant.apple.com/feedback/21352672 , we contacted PNO to investigate, and they determined that the issue was a missing WSD key. After configuring this key, the issue still persists with the same logs. PNO also reported that they still do not receive any calls from Apple services for the eligibility check step. Could you please help us check this? I have created a new feedback request for this issue: https://feedbackassistant.apple.com/feedback/21945664 Thank you.

To follow up on this, the search functionality of the archive is still broken. Additionally, the whole lists.apple.com server was down a few days ago. I still haven't received any reply from Apple. In case it helps others, I used the Wayback Machine to create an archive of the old coreaudio-api mailing list. It's available here: https://github.com/iccir/coreaudio-api-archive

First off, I want to start with a clarification here: We are in a logical deadlock. The kernel dispatches a probe command before UserCreateTargetForID returns, and both of our methods for handling this command result in a permanent hang of the registration process: Calling UserCreateTargetForID means please create the storage stack for this target. Returning from it means I've finished creating the storage stack for this target. I'm not sure how far up the stack you'll actually get, but it's conceivable that we'd get all the way through partition map interpretation and (possibly) volume format detection BEFORE UserCreateTargetForID returns. You're basically guaranteed to get I/O request before UserCreateTargetForID returns. [1] I think the upper levels of the SAM stack prevent this by returning from state before calling registerForService on their IOStorage family nubs, but there's no technical reason why they'd HAVE to work this way. That leads to here: We mark the target as Ready during the UserIni

First off, thank you for your patience with this. I wanted to make sure I'd gotten an authoritative answer on this, and it look a little while to get to the right person. Next, my answer here is primarily about Apple Silicon support. I think the same code will also work on 64-bit Intel and I'm not going to try and sort out 32-bit Intel. If you have time, Could you take a look at the code? I have submitted on the bug. One more thing to add: I have also tried using the prepare() interface of IODMACommand, but there have been no significant changes. So, first off, what doesn't matter here is the IOMemoryDescriptor configuration or inTaskWithPhysicalMask.Your trying to map 20Kb, so I would start testing with a size of 32Kb (2 pages). You could also specify a mask of: 0x0000 0000 FFFF F000ULL (32 bits, 16Kb aligned) ...but that's simply to start with the most straightforward configuration, not because other configuration won't work fine. What DOES matter here is the IOMapper argument of your IODM

Just to confirm that you need real Apple IDs to test CloudKit sharing, and that the Sandbox Apple Accounts in App Store Connect won't work. Regarding the limits or terms of service you mentioned, hopefully folks who have more insight in that area can comment. Best, —— Ziqiao Chen  Worldwide Developer Relations.