missing package product

We believe that MFi certification is not necessary for USB-C connections. Is this understanding correct? Yes, that's correct. The system directly supports USB mass storage devices. The system will mount the volume and make it accessible through Files.app and APIs like UIDocumentPickerViewController. Implementation Method We prefer not to use standard components like UIDocumentPickerViewController. Are there any methods to access the file system directly, or any other suitable approaches you can recommend? No, not really. You can use our standard components to get access to a directory and then provide your own navigation UI, but the only mechanism that will get you that initial access in one of our controls. In addition, there is currently an issue with cross volume bookmarks (r.102995804) which prevents resolution from working across volume mounts, so you also can't (reliably) use a bookmark to preserve access like you could on the users local storage. As things now, there isn't a good way for an iOS app to

These are the Developer Forums, where developers of apps for Apple's platforms ask each other for hints and tips on coding. These forums are NOT where Apple's actual developers chat about stuff. Your question is more of a product support one, so I'd suggest you ask it over at the Apple Support Forums. Thanks.

TLDR, no need to manage provisioning profile: Share your project folder with the virtual machine Open the project in xcode 15.4 in the virtual machine, do not change anything Click Product->Archive Once done, copy the archive to your physical machine Open the project in your physical machine, and click Window->Organizer, and distribute your app. If your project doesn't require additional build configurations, you can also use xcode cloud build to simplifiy things.

These are the Developer Forums, where developers of apps for Apple's platforms ask each other for hints and tips on coding. These forums are NOT where Apple's actual developers chat about stuff. Your question is more of a product support one, so I'd suggest you ask it over at the Apple Support Forums. Thanks.

Thank you for the detailed explanation. I have a question. This example shows undefined behavior. How can SwiftUI developers know that this behavior is undefined? I couldn't find it in the NavigationLink documentation. And thank you for the code rewrite. The sample code worked as expected. In our production code, I will avoid mixing value-destination and view-destination and will use value-destination exclusively. I also understood that using get-set binding for navigationDestination(isPresented:) can cause animation issues. To add, I am using this method to support iOS versions prior to iOS16, where navigationDestination(item:destination) is not available, and it works for versions before iOS18. However, after slightly modifying the rewritten code to match our production code, I encountered a pop issue again. Specifically, when I changed .navigationDestination(for:) to .navigationDestination(item:) within RootView, it automatically pops during the first transition from ContentView to SubVie

Thank you for the explanation at [https://developer.apple.com/forums/thread/758371]. As you understand, I am using navigationDestination(isPresented ) with get/set binding because navigationDestination(item:) is only supported from iOS 17 onwards. Our product code supports iOS 16 and later. (The product itself also supports iOS 15, so we are using NavigationView as well.) Additionally, when I modified the code provided in the post to be closer to our product code by changing navigationDestination(for:) to navigationDestination(item:), the pop issue reoccurred (during the transition from contentView to subView). Therefore, I believe this issue is not related to the view-destination or value-destination problem. As a workaround, I have confirmed that commenting out @Environment(.dismiss) defined in ContentView avoids the issue. While the code in this article is very simple, our product code is enormous and has a very complex structure, making it extremely difficult to pinpoin

I archive my app, I notarize it for direct distribution then I save it to the /Applications folder. Then I delete my Debug app from …/Xcode/DerivedData/MyApp-dal…xu/Build/Products/Debug so I am sure I have one only copy of my app on the disk. First off, a general warning around LaunchServices and development machines. Basically, very typical developer workflows often create situations which are WILDLY outside normal customer usage patterns. The same app is being created, version rev'd, deleted, created... over and over again with a volume that is WILDLY beyond what any normal user would ever do. A developer could easily do this 30-100 times a day while a normal app user might not have the app update more than a few times per year. This can be particularly problematic if you're also using your app (as a user would), not just testing, as now you have multiple versions of the app that are live and which the system can't always differentiate very well. SO, a few broad suggestions on all this: Don't assum

What is the general approach to analyzing cpu_resource_fatal.ips? In terms of how the log is structured and how it can be interpreted, my response to this thread on wakeups is a good summary of what's actually in the data. The cause is obviously different, but the collection method and data format are exactly the same. Is there a standard way to analyze it? Yes and no. Going through the process above can tell you want the stack shows, but how useful/helpful it will be is hard to predict. The reality is that the kernel is sampling a tiny portion of your overall runtime and there isn't anyway to know exactly what's missing. One point to make on the termination reason itself: 9 seconds cpu time over 9 seconds (100% cpu average), exceeding limit of 60% cpu over 15 second Any responsible background app needs to keep in mind that it's operating in a shared in environment and that it needs to contrains it's activities to account for that, particularly high priority categories like voip. The limits the syste

This is similar to FB14125143 in concept. Regardless of ObservableObject or @Observed, this is an unsupported construction of the Navigation APIs. See the answer on this post for the explanation. Regarding the get/set boolean mapping, (and I realize there is unfortunately an availability cliff between iOS 16, and iOS 17) please wherever you can afford it, don't using navigationDestination(isPresented:destination) with a get/set binding that maps to an item under the hood. Instead, use the navigationDestination(item:destination) modifier. For iOS 16, you may need to fall back to that construction, but it may result in lost frames or animations when the binding has to effectively update twice in one frame. In iOS 16, unless it's critical for deep-linking, try using view-destination links instead or represent that functionality by appending an item to the navigation path instead of setting a selection.

This example shows undefined behavior. A NavigationStack's path is comprised of: 0 or more value-destination links followed by 0 or more view-destination links. A value-destination link is one that pushes a value onto either the navigation path, or into a List's selection. e.g. NavigationLink(Foo, value: 42). A view-destination link is one that pushes a view onto the navigation path, e.g. NavigationLink(Bar) { MyDestinationView() }. Because view-destination links have a weaker notion of identity than value destination links, they can't precede them on the path. The way this example uses a get-set binding is prone to animation issues as well, since it may take multiple graph updates for that binding to toggle to true, animations can be lost. You can rewrite this like so: struct Selection: Hashable, Identifiable { var num: Int var id: Int { num } } enum Kind: Hashable { case a case b } struct RootView2: View { @State var kind: Kind = .a @State var vals: [Selection] = (1...5).map(Selection.init(num:)) @