build disappears

[quote='867728022, shara7, /thread/806187?answerId=867728022#867728022, /profile/shara7'] I assume this is simply a bug [/quote] That’s correct. If you’re building a macOS product and this is causing you significant amounts of grief, it might make sense to ship an update to your product that embeds your program in an app-like wrapper (per Kevin’s suggestion above). Otherwise, my advice is that you wait for a fix. And, no, I don’t have any info to share as to when that fix will actually land. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='808430021, wudiandy, /thread/808430, /profile/wudiandy'] does App Store Connect require the new build to originate from the same Xcode project … ? [/quote] No. [quote='808430021, wudiandy, /thread/808430, /profile/wudiandy'] does it only validate the Bundle Identifier and Version/Build Number? [/quote] Yes. Well, it validates a bunch of other stuff as well, but in terms of identifying your app that’s always done by its bundle ID. After that it runs a bunch of validation checks, one of which is to check the versions. Your proposed approach should work just fine; I’ve worked with many developers who’ve done this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

See Fixing an untrusted code signing certificate for information about the unable to build chain to self-signed root error. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This is very reminiscent of the problems I see when installing two apps with the same main executable build UUID. See the Build-time considerations section of TN3179 Understanding local network privacy and thence TN3178 Checking for and resolving build UUID problems. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='808473021, raunits, /thread/808473, /profile/raunits'] we need to wrap them in a framework [/quote] Right. And there’s no built-in support for that. There are a couple of paths you might take here: Wrap it yourself. Use a mergeable library. The first option is obvious, but surprisingly tricky. You have to manually create a .framework wrapper around your dynamic library. The tricky part [1] is in crafting the correct Info.plist. I generally recommend that you create a test framework using Xcode and then crib the on-disk structure from that. Alternatively, you could update the build process for that “independent codebase” to create a mergeable library. You can then create a framework within your own app and merge that mergeable library into it. IMPORTANT Do this for each of the platforms you support, and remember that the device and the simulator are different platforms. Your best option here is to do it separately for each platform, and then merge it all together into one XCFramework. Finally,

You definitely want to use automatic code signing for this stuff (-: Try this: In Signing & Capabilities, enable automatic code signing on both targets. Then remove the App Groups capability from each target. Select a real device as a run destination and choose Product > Build. I’d expect that to work (-: Back in Signing & Capabilities, add the App Groups capability to the app target. And enable the relevant group from the list shown by that capability. Try building again. Repeat steps 4 through 6 for the widget target. How far do you get? And if things fail, what error do you see? Also, what version of Xcode are you using? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Try this: Using Xcode, create a new project from one of the iOS > App template. During the creation process, select your team, that is, the team that the app was transferred to. And enter the bundled ID of that transferred app. Build that for the device (so not the simulator). Does that work? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='808475021, StanLey-Pliszko, /thread/808475, /profile/StanLey-Pliszko'] Why does local codesign --verify pass but Apple notarization service fails? [/quote] I’ve seen this happen for a couple of reasons: Case sensitivity Packaging To test the first: Create a case sensitive APFS disk image. Use the Finder to copy your app to it. Run your codesign --verify test against that copy. On the packaging front, it’s common for apps using third-party tooling to not follow the guidelines in Placing content in a bundle. When that happens, the app can end up with a code signature that relies on extended attributes. And when that happens you can run into problems during notarisation because of the various ways that those extended attributes are packaged. To test this: Build your app to a disk image. Use xattr to check entire app bundle for extended attributes starting with the com.apple.cs. prefix. Finally, I want to address two other things that are unlikely to be the cause of this issue but you should fix

[quote='808594021, AckwelFoley, /thread/808594, /profile/AckwelFoley'] the end goal is to mount a user's entire home directory via my FSKit [/quote] That’s gonna be really challenging. FSKit is based on app extensions, and app extensions are fundamentally scoped to a given user. [quote='808594021, AckwelFoley, /thread/808594, /profile/AckwelFoley'] Is there a way to enable my FSKit module globally [/quote] No. Honestly, I think that’d make a reasonable enhancement request. On the networking side of things, macOS allows developers to package a Network Extension provider as a system extension, which runs globally. If you do file an ER, please post your bug number, just for the record. What’s your distribution plan here? Is this something you’re building for yourself? Or something you plan to ship to a wide range of users? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Any updates? Our builds are still stuck during the Archive step. Ticket 102756662562. Would appreciate any guidance.

If all your assertions about the portal settings, provisioning profile, the entitlement file and it's contents are correct, the remaining cause I can think of for the signed app not having the entitlement is either the entitlement file is not being built into the bundle, or there is a different entitlement file being build into the bundle that is missing the aps-environment key. I would suggest to check the building/signing process you are using that it is not missing the correct entitlement file. Of course it wouldn't hurt to double check that your previous assertions about the various relevant points are still correct.