build disappears

In cases like this its important to distinguish the Debug/Release build configuration from Development/Release signing. See Isolating Code Signing Problems from Build Problems. Once you do that, you’re be in a better position to debug this issue. Also, my experience is that the vast majority of broadcast and multicast problems are caused by folks not using BSD Sockets correctly. See Extra-ordinary Networking > Broadcasts and Multicasts, Hints and Tips. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='867287022, Mikesch8764, /thread/807578?answerId=867287022#867287022, /profile/Mikesch8764'] Unfortunately I do not have a separate Mac to test it. [/quote] One option here is to install that beta into a VM and test it within the VM. Last I checked you can’t use App Store, and that includes TestFlight, in a VM, but you should be able to run a development-signed build from Xcode. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Are you using @Environment(.widgetRenderingMode) var widgetRenderingMode already? If not, add that to your widget view, and change how the widget looks depending on the various values of widgetRenderingMode, i.e.: var body: some View { ZStack { switch renderingMode { case .fullColor: Text(Full color) case .accented: ZStack { Circle(...) VStack { Text(Accented) .widgetAccentable() Text(Normal) } } case .vibrant: Text(Full color) default: ... } } } Also, on images, there's a modifier: .widgetAccentedRenderingMode() with options like .accentedDesaturated. Take a look at how each of those values affects your widget, and you might find out the right combination that works in each of the various Home Screen modes. Note that this is only available from iOS 18 onwards. Also note (from the dev documentation) if the Image is a subview for a group that has widgetAccentable(true) applied, this modifier may conflict. It's quicker to check the various looks in Xcode previews than it is to build and deploy to an iP

Earlier I wrote: But, honestly, it sounds like a fun weekend project And indeed it was (-: Pasted below is some iOS code that is able to detect how your code is signed using only public APIs. To do this, it uses a sneaky combination of XPC loopback and XPC peer requirement checking. This code comes with a bunch of caveats. Read the doc comment before you use it [1]. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] By my count the doc comments represent well over half the total number of lines (-: import Foundation extension CheckSelfEntitlement { /// Checks whether the current process claims the get-task-allow /// entitlement. /// /// - warning: As explained below, you shouldn’t use this routine but /// instead should use ``isGetTaskAllowTrue()``. This routine exists solely /// to illustrate the following point. /// /// This routine checks for the presence of the entitlement, rather than /// checking for it being present with a particular

I just checked Apple's documentation and found this note: If you upload a build and it remains in the Processing state for more than 24 hours, there may be an issue. To resolve the issue, submit a Feedback Assistant ticket or contact us. Document URL: https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata#view-build-upload-status I've already submitted a Feedback Assistant ticket myself. However, since the US is celebrating Thanksgiving right now, I don't expect anyone to look at it until after the holiday. I suspect this is a common issue that Apple needs to address for specific apps. So, if you run into this problem, don't just wait for it to resolve itself—be proactive and report it to Apple immediately.

I'm afraid you'll have to provide a bit more context. Do you have a specific question that someone could answer? Are you talking about building or installing? For building, the standard process is simple. Xcode > Product > Archive. There is no step two. For distribution, you can choose the Mac App Store or direct distribution. If you choose the Mac App Store, you're done with the installer package at that point. For direct distribution, you'll still need to zip the resulting app. You can do that in the Finder with control-click or double-click and choose Compress. Of course, if you're more of a masochist, there are many, many suggestions from the internet on how to make the process more difficult. You're correct that those procedures can get Kafkaesque in no time. But you don't have to do it that way if you don't want. And if you don't like those procedures, then I don't see the point of attempting them.

We have the same issue either. We use Expo (react native) and always set ios.supportsTablet to be false on building app. In the past, our app supports only iPhone, but suddenly start to show that it supports iPad and Apple Watch as well in the latest build and submit, even though we dont support it and didnt change the ios.supportsTablet setting. We hope this issue will be solved soon.

Once again I get rejected. I removed all references to dating. They just come back and hit me with a 4.3 rating and give me no guidance on what I need to do. I am filing a second appeal, but I haven't received a response from anyone. Here's my new appeal message: My app is not a dating app. It’s a real-world social discovery tool designed to help people meet others while they are out in public spaces. Users can create events, connect with others nearby, and explore Hot Zones, which show where activity is happening in a specific area. I have removed all references to dating to make that distinction clear. I continue to receive Guideline 4.3 rejections, but I have not been given any specific feedback or direction on what changes are required. Without actionable guidance, it is impossible to understand what the review team believes is duplicative or how I can bring the app into compliance. I respectfully request that someone contact me or provide more detailed clarification. I have invested significant time and

Thank you for your post. This is quite interesting for me, as I am still learning about this API myself. It is possible to “unshield” an application by modifying the ManagedSettingsStore().shield.applications array https://developer.apple.com/documentation/ManagedSettings/ShieldActionDelegate. However, the immediate disappearance of the shield depends on how the associated extension handles state updates. Typically, invoking completionHandler(.none) after modifying settings signals the system to apply changes, but immediate UI updates may require explicit app/extension design support for dynamic reloading. If this does not work, we should examine the code. Debug builds typically allow real-time data synchronization and immediate reflection of ManagedSettingsStore changes. However, TestFlight should have the same experience. Some functionality may not operate configurations in TestFlight builds, and you should file a bug for those. The shield does not necessarily require the main app