Good morning! Our app is currently a mix of UIKit and SwiftUI. All new code is SwiftUI and we’re gradually replacing old code but for now we have SwiftUI views in UIHostingControllers where needed. Our app is a dark color scheme regardless of the device light/dark setting. One issue we’ve have is that some view in the hierarchy of the UIHostingController seems to have a white background. This is not normally visible, but when sliding views on and off in navigation, there’s a hint of white showing at the edge of the view as it moves. It’s subtle but users have noticed. I thought I filed this bug some time ago but I can’t find it. Just wondering if you’re aware and if there’s any update.

Good morning! Not sure this is strictly a SwiftUI question but it is a UI question. The biggest problems we’ve had in adopting the updated UI in recent releases center around the tab bar. We’re an iOS/iPadOS app with a tabbed UI. Having the tab bar arbitrarily jump from the bottom of the screen to the top at a certain size makes laying out our UI very difficult. We’ve worked around this so far by using a custom bar, but that’s clunky and doesn’t work well with Liquid Glass. Are there any changes to this behavior in the 27 releases given the even greater emphasis on resizability?

Good morning! Our app uses a dark color scheme regardless of light/dark mode. One issue we’ve had with Liquid Glass has been that buttons in the nav bar do an animation when views are pushed or popped, and the Liquid Glass elements appear to flash during those animations. Are you aware of this behavior? Is there a solution? I suspect that the buttons are mixing in some white even though our background is near black.

Hi! I have not seen this year's video yet, so please forgive me if this is answered. I notice a couple of folks here saying that AppAttest is (at least partially) supported on macOS 27. Is this correct? My specific use case is a "designed for iPad" app running on macOS. We use App Attest to make high-value requests to our headend services and would really like this to work on macOS as well.

Greetings, I have set up two tips in my app, and my app is configured with Tips.configure([.displayFrequency(.daily)]. Tip 1 is set up with no options. Tip 2 has the IgnoresDisplayFrequency(true) option set: var options: [Option] { MaxDisplayCount(3) // We want the user to see these because it's important. IgnoresDisplayFrequency(true) } This option works as expected, as far as I can tell, in terms of making sure that Tip 2 is shown even if I've already seen Tip 1 today. If I interact with my app such that Tip 1 is displayed, and I then interact with it such that Tip 2 should be displayed, Tip 2 shows immediately, even though a day hasn't passed. However, if I do this the other way around, so that Tip 2 is displayed first, and then I interact so that Tip 1 should be displayed, my expectation would be that Tip 1 is not displayed, because another tip has already been shown today. I expected that it would not be shown until the following day, since it is not configured to ignore the tip frequency. That's not what happens, though. Tip 1 is displayed right away, even though Tip 2 has just been shown. This makes me think that setting IgnoresDisplayFrequency on Tip 2 is causing it to also be ignored when considering whether other tips should be shown. I did try omitting IgnoresDisplayFrequency option, and then as expected, only one tip is shown on a day, no matter which one is shown first.

Hi, I'm looking at adding App Attest to an app, and I think I understand the mechanics of the attestation process, but I'm having trouble figuring out how development and testing are supposed to work. Two main questions: The "App Attest Environment" -- the documentation says that attestation requests made in the .development sandbox environment don't affect the app's risk metrics, but I'm not sure how to actually use this sandbox. My understanding is that one of the things App Attest does is to ensure that your app has been appropriately signed by the App Store, so it knows that it hasn't been tampered with. But the docs say that App Store builds (and Test Flight and Developer Enterprise Program) always use the .production environment. Does App Attest actually work for local developer-build apps if you have this entitlement set? Presumably only on hardware devices since it requires the Secure Enclave? Does our headend have to do something different when verifying the public key and subsequent attested requests for an app that's using the .development sandbox? The docs do mention that a headend server should potentially track two keys per device/user pair so that it can have a production and development key. How does the headend know if a key is from the sandbox environment? Thanks!

Greetings, I'm dipping a toe into TipKit and trying it out. I placed a TipView into one of my SwiftUI views, and the default styling didn't fit well within our app, so I changed the background and text colors. However, I can't find a way to change the color of the close button ("X"). Unfortunately, the default color is very hard to see against the background color that I selected. Is it possible to set the color of that close button? For the time being, I have created a TipViewStyle that replicates the default styling with my color changes applied, but this seems unnecessarily complex for something as simple as setting the color of that button. Thanks!

Greetings, Working on adding some simple rules to my first TipKit tips. I'm following the example from the WWDC TipKit talk, which included a rule intended to ensure that the user had accessed a particular feature at least three times in the past five days. So it had code that looked like this: #Rule(Self.enteredBackyardDetailView) { $0.donations .filter { $0.date > Date.now.addingTimeInterval(-5 * 60 * 60 * 24) } .count >= 3 I'm trying to do something similar -- essentially, I want to know if the user has been using this feature for at least a day. So I tried this: #Rule(Self.viewedDetails) { $0.donations .filter { $0.date < Date.now.addingTimeInterval(-1 * 60 * 60 * 24) } .count > 0 } i.e., Is there at least one event that was donated more than a day ago? However, Xcode flags the .filter line with the message "The filter function is not supported in this rule." Huh? This smells to me a lot like the limitations that SwiftData has with not being able to do certain kinds of operations in predicates. But this was clearly intended to be supported in the design, since the exact example was shown in the WWDC session on TipKit. So, am I missing something? Is there a different way to structure this so that I can use .filter, or is there some other way of expressing the condition without using filter? I did try using .first { same expression } != nil, but Xcode then said that rules must include a count comparison... Thanks!