missing package product

36 minutes, base on our log, the call at 16:58 have no problem. and the app went into background from 17:00 - 17:36(screen lock), until an incoming call push woke up the app. OK. That time scale does fit my other theory, which makes my optimistic about the workaround I’m suggesting. So, you recommended we set the configuration before CallKit is first used after the app starts? At this point, my best advice would be to set the configuration before every call. There are probably cases where it would be reasonable to skip that, however: Will this overwrite the configuration of CallKit? Keep in mind that the configuration here is primarily just a set of settings that control a few key details of how CallKit handles your call. Many apps already set the configuration immediately before reporting calls—for example, to customize the ringtone based on the incoming caller or to prevent that particular call from listing in recents. That leads to here: We may give this a try, but it's difficult to determine if it will wo

If I have a complex UI with hundreds or thousands of widgets, am I expected to perform these registrations You perform the registrations you need based on what you are doing. So, if you decide to use a UIControl, then yes, you need to decide which UIControlEvent you need. As mentioned above, that's likely just primaryActionTriggered, though. And for UIView's, unless you have legacy code where you are handling responder-based delivery like touchesBegan:, touchesEnded: you should prefer UIGestureRecognizer instead. That could be one of our pre-packaged gestures, like UITapGestureRecognizer or UILongPressGestureRecognizer, or you could write your own subclass with the event protocols mentioned in UIGestureRecognizerSubclass.h. There is no centralized place recognize all the things, because not all gestures are needed all the time. For simple tapping of something on screen, you do not need UITapGestureRecognizer, UILongPressGestureRecognizer, UIPanGestureRecognizer, and UIPinchGestureRecognizer. You only

That error indicates that your device is missing some of the assets it needs to run FoundationModels. This is a bug. Please do two things. The first will help us understand how you got into a bad state in the first place, and the second may get it back into a good state. First, please take a sysdiagnose and submit it via Feedback Assistant. When you do, please include a link to your forum post. If you could also post the feedback id here when you're done, that would be helpful. How to collect a sysdiagnose Second, with WiFi turned on, navigate to Settings > Apple Intelligence & Siri. This should trigger your device to attempt to download missing assets. Wait a few minutes and then try running your code again.

Wait, no, I've now been told they grabbed java from AWS, and then stripped out parts of it to make it smaller, and as a result lost the bundle structure.

Yes, this is a system behavior. It tries to add a glass effect to existing icons even though it does not work with every icon. You cannot customize this. When you compile with Xcode 26 you will lose this effect on your existing icon too as Apple assumes you do not want the glass effect. For all other cases, use Icon Composer.

Are you absolutely certain of this? If so, then do you have any idea/guess as to how much time was between the last working call and the first failed call? 36 minutes, base on our log, the call at 16:58 have no problem. and the app went into background from 17:00 - 17:36(screen lock), until an incoming call push woke up the app. The issue began to occur on this call and subsequent calls. My intuition is that #2 will probably solve the issue, but if I'm wrong, then #3 should ensure that the issue is corrected, and the next call will work. So, you recommended we set the configuration before CallKit is first used after the app starts? Will this overwrite the configuration of CallKit? We may give this a try, but it's difficult to determine if it will work or not since it's hard to reproduce. We might need to implement this in our production environment and check the metrics to assess its effectiveness. I will discuss with team.

@DTS Engineer I apologize for the urgency and any inconvenience caused. Could you please help me track FB19683706? If this issue cannot be resolved, I may lose my job. Thank you very much for your kind assistance.

@DTS Engineer Hi Kevin, Thank you so much for the definitive and incredibly helpful answer. This clarification has saved our team a huge amount of debugging time, and we truly appreciate you sharing this specific information. That makes perfect sense and explains the behavior we were seeing. The main source of our confusion was the documentation, which lists both iOS 26.0+ and iPadOS 26.0+, leading us to assume iPhone support. Your clarification that it's currently limited to iPads with an M3 chip or better is exactly the information we were missing. Just one follow-up question for our team's planning purposes. While we understand this may not be formally documented yet, is there an official device compatibility list or a specific documentation page we should monitor for future updates on these hardware requirements? Having a definitive source to reference would be a great help for us as we define our feature set across devices. Thanks again for your help!