These are the Developer Forums, where developers of third-party apps for Apple's platforms ask each other for hints and tips on coding. These forums are not where Apple's actual developers chat about new features. If you have a suggestion, you should raise it at: https://feedbackassistant.apple.com/

Hide My Email is a service designed to allow users to HIDE THEIR EMAIL from apps and websites. To you, as the app developer, the email you are given is a valid email address, and you should treat it as such. The issue is in this bit of your post: For marketing reasons, I would prefer to have the user’s real email address instead of the relay email. You're not entitled to override someone's preferences and force them to receive marketing emails from you. Bypassing a Hide My Email address is doing exactly that. If the user decides they no longer want to receive emails from you, they can deactivate that email address and not receive your emails. That is their right. You have no right to override this, or to force someone to provide a different or non-'privaterelay' email address. If I download your app, and it refuses to allow a Hide My Email address, your app would be deleted immediately and I'd never use anything from you again. I'm pretty sure I'm not alone in this.

Raise a suggestion at: https://feedbackassistant.apple.com/ then post the FB number here. Don't expect to receive any feedback from Apple unless they need clarification.

Right, so report it: https://feedbackassistant.apple.com/ then post the FB number here.

You should probably raise this as a bug in the usual way. It won't really get progressed if it's only posted in these Developer Forums. Raise it at https://feedbackassistant.apple.com/ and provide Xcode version and other relevant info. You should then post the FB number here so Apple devs can link it to this post.

But I can't help you if I don't know how that widget has been created. How are the four images displayed? What modifiers are you using? Is that in Clear or Tinted mode?! I've suggested the code from WidgetKit that you can use to change the appearance of the image in the different widget styles. Can you maybe apply them to the four images in the widget and show us what it looks like in Clear and Tinted modes? .vibrant mode is used when a widget is on the Lock Screen, in StandBy, and also in Tinted and Clear modes, and you either don't show an image background, or - if your widget requires an image, like Apple's Photos widget - then you need to desaturate your image and accent your text. Try some different options, post the code used, and a screenshot of how it looks.

Right, but the code you've posted isn't making use of any of the suggestions I made - which are from WidgetKit. Those bits of WidgetKit are there to aid you in displaying the widget in the correct style for the appearance currently selected. Look at how Apple's own Podcasts widgets or Weather widgets act on the Home Screen in Clear and Tinted modes; they have no gradient or background. The recommended style for a widget background in Clear or Tinted modes is to have a clear background, i.e. no image, so you should either not display your image, or set its opacity to a low number and tweak it until it looks good. Preview your widget in Xcode, change the display mode to Clear or Tinted, then add the modifier .widgetAccentedRenderingMode(.accentedDesaturated)to the Image. Does it improve your widget?

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 iPhone and customise the Home Screen each time, just to save you some time.

This post is deemed to be sensitive, and the reason is the first two words, because they sound rude when they're put next to each other: // Use the singular of cues in place of A: for A in cues { // Do a thing }

I've tried to reproduce it in a new project, but it doesn't happen, either in the Simulator or on a physical device, possibly because it only happens when there are a bunch of views or a certain stack, who knows. Back in the original project, deploying to a physical iPhone and triggering the snapshot function is now producing this in Instruments: The call to superView.drawHierarchy(in: superView.bounds, afterScreenUpdates: true) within generateSnapshot() is selected. Everything after that is UIKitCore, Foundation or CoreFoundation, so I don't see how I'm leaking the memory. I've raised FB21074853 with the smaller project. It won't show the issue, but it might be a starting point for the guys at Apple to get to it.

What version of Xcode are you using? What version of iOS/macOS/other OS are you building for? I tried it in Xcode 26.1.1 on macOS 15.7.2, targeting iOS 26.1 and it works fine, no errors. Here's a reduced version (that also works): var dateComponent = DateComponents() dateComponent.day = Int(200 / 80) let newDate: Date = Calendar.current.date(byAdding: dateComponent, to: Date.now)! print(newDate)

I can't find any information on the Strap, and since no Apple developer has responded to any of you, I suggest you all raise feedback reports on this. At the very least Apple will see the reports and get back to you. They may not even have seen these posts on the forums.

My question on how to handle crashes is not limited to just iOS version variations issues. I was refering to general exceptions and runtime errors that can cause app termination. Thanks. TEST! You need to test your app on different versions of the operating system, and fix any bugs you find. Proactively code so that your app handles failures gracefully. For example, don't always assume there's going to be a value and force unwrap things. Provide a default value and handle it, i.e. some.filter { $0.abc == "xyz" }.first! should be some.filter { $0.abc == "xyz" }.first ?? defaultThing. Use guard let and if let.

Firstly, please ignore the pre-release Public Beta; it's irrelevant. The fact that a friend of yours is running it is irrelevant. It is not a supported version of iOS, and you should not be developing against it. Think about it... Apple might release ten betas of iOS 27; are you going to write your apps so that they run on all ten betas, even though no one will be running those betas anymore? Your friend should not be running the Public Beta. It is not supported, and you should not support it either. Secondly, the way to correctly make sure your app doesn't crash on different versions of iOS is to test your app. Xcode allows you to use multiple Simulators which will let you catch most issues. Also, you can use code such as if #available(iOS 26.0, *) to conditionally run code that applies only if that version of iOS is available on the device. If it isn't, you run some other code. I do this all the time. I have a function like this: func olderiOS() -> Bool { if #available(iOS 26.0, *) { return false } return true } // Create a global var to use it so we don't keep running the check: let isOlderiOS: Bool = olderiOS() I use it for inline checks, such as: .padding(.top, (isOlderiOS ? 10 : 5) where you can't use if #available(). Finally, you can apply conditional modifiers to code. Something like this: public struct Additional<Content> { public let content: Content public init(_ content: Content) { self.content = content } } extension View { var additional: Additional<Self> { Additional(self) } } extension Additional where Content: View { @ViewBuilder func presentationDetents_before_iOS18_0(height: CGFloat) -> some View { if #available(iOS 18.0, *) { content .presentationDetents([.height(height)]) } else { content } } } I've created the presentationDetents_before_iOS18_0 modifier because you can't use the .presentationDetents modifier before iOS 18, so this function applies it if iOS 18.0+ is available, and doesn't if we're on iOS 17 or below. I use it like this: .sheet(isPresented: $showSheet) { ChooseImageSheet(showSheet: $showSheet) .additional.presentationDetents_before_iOS18_0(height: 400) } There might be easier ways to do some of this, but it works for me.

My app was a web app running in WebView. Don't do this. No one wants to have to download an app when they could just as easily go to a website and perform exactly the same actions there. That's why your app was rejected. If the Review Team sent you a screenshot of the 'left menu' saying it didn't have enough content, then you should add more content to the app. 2-3 screens inside open WebView Write those pages as native pages inside your app rather than merely views onto a web page. Make the experience native, i.e. the user is in an app on iOS, so make the experience look and feel like they're in an app in iOS, rather than them having downloaded an app and being sent to a website. I promised my client I would develop an app for him. You seem to be coming at this from the wrong direction. You promised your client you would develop an app for them, but you're trying your hardest to simply shoehorn a website into an app 'shell'. That's not a good experience for the users, and it's not what your client wants. Approach the problem from the angle of creating an app with the features that the client needs. Build each screen as required. What you're doing seems to be merely adding a web view that goes to an existing web page. Not good.