missing package product

Hi, In the bug description, I have mentioned a link to download our package. Please let me if that is not part of the message. regards Prema Kumar

[quote='864834022, premak, /thread/806222?answerId=864834022#864834022, /profile/premak'] Bug id is: FB20929578 [/quote] Thanks. I looked at your bug and, while there’s a sysdiagnose and a system profile, I can’t see a copy of your installer package. Did you attach it? If not, please do. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You can also fix this by setting a wallpaper in the Simulator. The iOS 26.1 simulators are missing the default wallpapers, which can trigger a crash or loop in the MercuryPosterExtension. This has happened several times in the past with other Xcode releases. I’m not sure how to set a wallpaper in the #Preview Simulator, but with this workaround you can at least debug and run apps in the regular Simulator without the high CPU load.

we have this in config : entitlements: { com.apple.developer.in-app-payments: [ merchant.net.tag ], com.apple.developer.nfc.readersession.formats: [], // Empty array - Expo will use NFC capability from Apple Developer Portal aps-environment: production }, and but we still have this error when we submit app to TestFlight [logs] [Application Loader Error Output]: Validation failed Invalid entitlement for core nfc framework. The sdk version '18.5' and min OS version '17.0' are not compatible for the entitlement 'com.apple.developer.nfc.readersession.formats' because 'NDEF is disallowed'. (ID: 377c83da-9fcc-4903-8c6e-c041d3eedb73) (409)

This is the notary log and it still contains the same critical validation errors claiming it has no signed executables or bundles. However if I skip notarization and just install it using installer -verboseR -pkg ConcealDistribution.pkg -target / it works just fine and everything installs as expected. As I mentioned in the older thread I have not changed the structure or format of this PKG and this has been working for months up until a few weeks ago when it suddenly started failing. { logFormatVersion: 1, jobId: 14cc46bd-10d5-4e9c-9ad6-86c06baad6b2, status: Invalid, statusSummary: Archive contains critical validation errors, statusCode: 4000, archiveFilename: ConcealDistribution.pkg, uploadDate: 2025-11-05T21:53:19.782Z, sha256: 48ba80a95c818ae81cadcca07afed1ef4d0d8c120a87622b200dc9935964ee26, ticketContents: null, issues: [ { severity: error, code: null, path: ConcealDistribution.pkg, message: Package ConcealDistribution.pkg has no signed executables or bundles. No tickets can be

Is this expected behavior or a bug? Is there a crucial piece missing from my setup to get multitouch working on ARView without the overlay view hack? Your input is much appreciated.

That makes sense. I think it's not going to be too bad for customers. The data in the containers is basically transient cache and temp files (another reason why this particular App Store restriction is probably inappropriate in this case). The user's programs are stored in NSDocument bundles wherever they put them on disk (these bundles are used by the IDE via security scoped URLs which we bookmark and pass to the XPC service in the new versions of the app). In all app versions, a customer can wipe the app container, even the group container, and as soon as they restart the IDE it's all recreated and works perfectly. I test this use case regularly and it's bullet proof. Financially, the app uses (very cheap) monthly auto renewing expenses. The app itself is free to download (the auto renewing subscription is required for building programs, and comes with a month free trial) and doesn't have any permanent in-app purchases that people would lose. I can work with the new developer (a good friend), custo

Thanks for your thoughtful reply! It's much appreciated. I did follow your suggestion and opened an issue requesting the same treatment for notify. My bug number is FB20920858. P.S. Part of your answer above the horizontal line appears to have been cut off, but I was curious to hear what you were going to suggest! Regarding your suggestion for moving to Swift 6.2 and enabling default main actor isolation -- I did try this by copying my minimal example to a new Swift 6 project with Default Actor Isolation set to MainActor. Alas, it still crashes (albeit on a different line; it seems an internal thread assertion fails from the group.notify call itself rather than my MainActor.assertIsolated() in the closure body). Honestly, it's still what I expected given the missing @Sendable.

Hello @sadaotokuyama ! Thank you for your question. Could you please submit feedback using Feedback Assistant? And then share the ticket number here. I think understanding your usecase would be helpful for us, and you'll be able to receive updates about any changes or improvements in the future. It is true that when you modify content inside your RealityKitContent package, the entire package will need to be rebuilt. This is inconvenient, especially when you need to make frequent changes during development. For now, I recommend focusing on ways to reduce the frequency of changes you make to the asset itself that would require a rebuild in the first place. For example, are there ways you could verify changes in an external DCC? One thing you could do now: try placing your large USDZ file outside the RealityKitContent package, and inside a separate bundle, like the main bundle. Then, when you make changes to the large USDZ file, your entire RealityKitContent package won't need

I tried different device models, and some could trigger the task normally, such as the 15 Pro Max and 12 Pro Max. However, there were also some models, such as the 17 Pro, 15 Pro, and 15, that could not trigger the task properly. Moreover, there was no additional error information to help locate the issue. I assume you're doing this on device and not the simulator, right? And did you check the Console logs to see if an error was reported there? (look for the dasd process) I also just wanted to reiterate your other points about the BGContinuedProcessingTask API, in case someone from Apple is listening: I agree that the experience on non-Dynamic Island devices is not great. The task notification banner thing is a obtrusive and redundant. My app already displays a progress bar, so displaying another progress indicator is redundant. Moreover, the banner obscures my app's UI and does not disappear automatically like normal notifications. This leaves the user uncertain if they can safely dismiss it, or if dismissin

I'm looking into rewriting our non-replicated FP as a replicated FP, and I'm running into this as well. I'd like to show some UI that includes information from the database we keep about items, and if I had the NSFileProviderItemIdentifier we give to iOS, I could use that to look up the info. I'm confused by what you're trying to do here. Your file provider is the fundamental source of truth the system relies on. I can certainly see cases where you have user-relevant data that the system doesn't have— for example, displaying metadata the system doesn't use/support or showing the contents of directories the user has configured to NO sync. What I don't understand is how this flows in the other direction. The system’s view of your data should either always match yours or diverge in ways your provider understands and controls (for example, because you’re uploading/downloading data). What am I missing here? __ Kevin Elliott DTS Engineer, CoreOS/Hardware