“missing package product”

The location UIBackgroundModes key is specific to the startupdatingLocation() API that allows the app to run uninterrupted in the background, and is not necessary for the low energy APIs like significant location and region monitoring. This is what the review feedback meant as well: If the app does not require persistent real-time location updates, please remove the location setting from the UIBackgroundModes key. Indeed, the documentation you quoted says If your iOS app must keep monitoring location even while it’s in the background, use the standard location service and specify the location value of the UIBackgroundModes key to continue running in the background The standard location service mentioned here is the API I mentioned above which uses continuous GPS locations. I should also point out that the document you have referred to is an old archived document from 2016, and while some of the information might still be valid, there could be missing changes, and definitely the modern location APIs a

I don't know anything about your app or what you've submitted. All I can tell you is that there are some items that are required by the automated flow. The system will prevent you from submitting without them. But then there are still other items that are also required and app review will check for those and reject your app if they're missing. I would assume that screenshots are required for submission and that the system would display an error on a submission without them. But I'm not going to try that to test. And maybe you're talking about an update given the context of your first question? But generally speaking, once you submit, all you have to do is wait. But if you're concerned that your review might take a long time and ultimately end in rejection, then perhaps you have valid reasons for those concerns. Maybe be proactive. Reject the build yourself and resolve any lingering concerns. When you're 100% confident that your submission will be approved, then resubmit. It's always possible that you

Hello @dustinw1 We are investigating this issue, and will need to determine the impact of the change before deciding to keep the implementation or revert. To that end we need some more information: What 3rd party product is showing this behavior? If you know, what is the Bluetooth Chip Vendor and LMP Version? Are you seeing the issue with EV3, 2-EV3 or both packet types? And at some point, we might need some diagnostic logs from your end as well. To that end, the best would be to file a Bug Report and give as much detail as you can there. Once done, please post the Feedback ID of your report here, and make sure to @mention me so I can route the bug to the team right away. Argun Tekant /  WWDR Engineering / Core Technologies

Based on the above I tried reproducing this with a test project. And lo! it’s trivial to reproduce: I started with Xcode 26.3 without the Metal Toolchain 26.3 component installed. I created a new project from the iOS > App template. In the General tab of the target editor, I removed the Mac (Designed for iPad) destination. And added the Mac (Mac Catalyst) destination. I selected My Mac (Mac Catalyst) as the run destination. I chose Product > Build; the project built without any warning. In Xcode > Settings > Components, I installed the Metal Toolchain 26.3 component. I chose Product > Clean. And then Product > Build. I now see a build warning: ld: warning: search path '/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.7003.10.hJke6J/Metal.xctoolchain/usr/lib/swift/maccatalyst' not found Given the above, I can only conclude that this is a bug. I did some digging and was unable to find any more backstory (for example, I thought that

[quote='818269021, anonymousdev332299, /thread/818269, /profile/anonymousdev332299'] is both a Developer ID certificate and Apple notarization required on current macOS versions? [/quote] Yes. Developer ID signing has been required for a long time (10.8?). Notarisation for apps has been required since 10.14. [quote='818269021, anonymousdev332299, /thread/818269, /profile/anonymousdev332299'] Is [ditto] necessary to properly preserve the app bundle structure and extended attributes? [/quote] Yes and no. If you compress with the Finder then extended attributes get sequestered, which is not good. See Extended Attributes and Zip Archives. The ditto tool doesn’t do that by default. However, in an ideal world this wouldn’t matter because your code signature should not depend on extended attributes. If you find that it does, that suggests your have a bundle structure problem. We talk about this more in TN3126 Inside Code Signing: Hashes and Placing content in a bundle. As to what’s actually happening here, it’s hard

The initialization of your MapKit request will receive an error with a status field, and there is an enum you can check to see the reason — TooManyRequests. Are these limits strict daily hard limits that should never be exceeded in production? From a code perspective, you should design your code with good error handling to gracefully handle the TooManyRequests error state, in addition to the other errors in the ConfigurationErrorStatus enumeration. If you're asking this question from more of a business planning angle, see below. Is there an official pricing model for usage above the free quota, or do we need to contact Apple to request higher limits? If you start running out of the daily quota, the next thing you'll need to do is to fill out the increased capacity form and go from there. — Ed Ford,  DTS Engineer

Thank you for the replies and for sharing your experiences. Since this is our first app submission, we just wanted to double-check that our App Store Connect metadata and review information are complete and clear for the App Review team. The app is a simple B2B ordering tool for registered wholesale clients and includes reviewer login instructions in the App Review Information section. If anyone from the App Review team happens to see this thread and notices anything missing in our submission, we would really appreciate the guidance. App ID: 6759172913 Thank you again for your time. Kindest regards Jose Rodriguez

FSEventStreamRef reports changes on a directory. I have some comments below, but FSEvents are a complicated topic in their own right. If you've got a product that's actually focused on monitoring and updating a large hierarchy (this isn't actually all that common), then it might be worth starting a new thread that's focused on those issues. Does it work on file reference URLs? No, it takes the opposite approach, which is basically force you to iterate the hierarchy until it happens to stabilize. The core underlying issue here is that the file system doesn't restrict how it's modified and the API it provides only provides a picture of a particular instant in time. That is, when you ask for a directories contents what you actually get is the contents at that instant without any guarantee that they're still the current contents. Most of the time the contents don't change fast enough for that to matter, but in a frequently changing directory the past and now can diverge VERY quickly. You'll note that FSE