Show us code instead pretty much what you're doing.

Try adjusting the visibility options for the same widget in the phone settings maybe under privacy and see of the code honors the logic.

All it takes is determining if there is a paid contract on file, no spammer is going to mess with having to pay for and losing an account each time due to the cost and it allows apple to enforce the rules more. No paid contract on file then read only access is provided. As for students validate them via their institution id numbers, parents where needed or a student paid contract. This will prevent furious consumers from posting here as well.

If using an actual device, ensure the internet is accessible via WIFI or Data, the request is using SSL, and the hostname is resolvable.

Then the API limits have been exceeded.

Just like IBM approval is pending background checks ... It's the weekend, and you're not the only person ...

It looks like a nested ForEach Crash at lines 176 & 76 & 44, where one of these loops exceeds the upper bounds of its collection.

When used like this I have no issues: struct SomeView: View {     @Environment(\.dismiss) var dismiss // called via a Button or some UI action of SomeView when presented by a parent View private func save() {   DispatchQueue.main.asyncAfter(deadline: .now() + 0.763) {             dismiss()         }     } }

When you smash your left toe with a hammer remember you have nine more toes to go. What you're doing with the API is wrong and self-inflicted.

No, just the version released to the AppStore after approval

Forum access should be based on a paid contract with all the required paper work completed and once approved then access is granted to the forum. The same process for students, validate their student’s ID because by making it easily accessible for them it is opened for spammers.

Are you using Objective-C, Swift or SwiftUI?

Set break points in PostAppDelegate to see what might be causing the warning.

Something like this will only happen if an object is dereferenced during access. So some root cause analysis based on what is actually calling these APIs from user/developer code is a good place to start.

Your description of what your company does and who it is done for is reason enough for Apple not to reissue the certificate.