missing package product

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:)) @

same here. I never noticed that it was stuck on wireless debugging and wondered why it'd take a minute to start the damned thing, or 3 or 4 seconds per step in the debugger. My solution was to simply restart the iPhone while connected. I have to do that from time to time but I gladly spend 1 minute every couple of hours instead of losing the 15 minutes or more per hour just waiting....and w a i t i n g.......

I could not push to the App Store in the organizer (only 'custom' available under 'method for distribution', then I can only select 'Built Products' or 'Archive', no upload to App Store, see screenshot) This issue occurs when you have a generic archive. For more information, see TN3110: Resolving generic Xcode archive issue. Is what I am trying even possible, or do the main app and app clip need to be published in the same XCode project? When you submit an App Clip for distribution to testers with TestFlight or for publishing in the App Store, you don’t submit the App Clip on its own; you export and submit the app bundle of the full app that includes the App Clip. For more information, see Distributing your App Clip.

Hello, thanks for you reply! As I've said, the crashes above have been received on our crash reporter from our Safari App Extension which is running in production on our users' machines. I haven't been able to reproduce any crash locally on my machine. Also, I just suspect that the crashes and the No context logs are the same issue, but I don't know this for certain. With that in mind, I sent a bug submission through Feedback Assistant about this. The submission includes 30 user crashes (from the crash reporter service) that may be relevant, but no crashes from my machine. I've also added a few screenshots. The feedback submission number is FB14156523.

Hi there! you're missing a closing bracket after Text(Home), so it is only rendering the first tab since it never sees an end to the tab item.

Hi! I know this post is more that 6 months old, but I'm facing the same issue and wondering if there has there been any development on this? After rolling out some security features using attestation on our app into production, we have been observing the same strange occurrences that @mahashis described and from our logs we could extract some metrics that place the total percentage of affected users in the 5% to 6% of all users using the app, amounting to above ten thousand installations. Even though it is expected some failures to happen like it is mentioned in the docs and in the comment above from @endecotp (for users migrating devices) and actual unsecured (example: jailbroken?) devices, it's hard to credit that is the case for so such a high percentage of users. Even more so because it happens when attesting a freshly generated key which typically (and per documentation advice) only happens on fresh installations of the app or when a key is reported as invalid from the DCAppAttest service api. T