not sure if you guys can see with just image, but the scroll content is able to show underneath the section with the segmented pickers, and the section the background blends totally smoothly with the toolbar. from my own attempts, I am not able to make a extra long toolbar, and if i added a row just underneath the toolbar, the effect of scrolling the content under the row does not produce the effect.. I'm just wondering how Apple made this. did they just built the toolbar custom without even using swiftui toolbar? yes i am aware this is an older version of iOS, but I still want to know. thank you.

The example they gave for the hard scroll edge effect is the calendar app, but Idk if this is a bad example or if i am missing something, because the calendar app theres a date picker row below the toolbar, and from my testing, whenever theres some element between the toolbar and the scrollview, the fade and blur effect does not happen -- so in fact, the hard scroll edge effect is completely unnecessary.

when I tried ToolbarItemGroup(placement: .title) { VStack { header() }.glassEffect() } the glass effect is only applied to the element itself. And the ToolbarItemGroup does seem to have the glass effect apis either. What I want is for the overall toolbar to have the glass effect, not just the individual elements in the toolbar.

Is there a way to simulate Display Zoom settings under the Appearance tab in Settings on a device simulator? I can only find this setting in my real device.

I see online theres list of urls app can use to deeplink to Apple apps: https://github.com/bhagyas/app-urls#references-and-additional-resources are these acceptable by Apple? Apps just want to redirect the user so they can take some appropriate action.

In the Swift docs, it says cancellation uses a cooperative model, which I understand as that all jobs (ie function calls) need to handle cancellation manually even if the task containing them got cancelled. I am assuming this is still the case even with using the SwiftUi.task? The documentation for it should include a reference for how cancellation works to be complete.

UserDefaults store app-related settings, and I am just worried that if an SDK also writes to the UserDefaults, that there could be potentially some key collisions between the host app and the SDK. Is the concern just in my head or does it have merit?

I have a Xcode 26.6, and when I run the simulators for iPhone, Siri does not work, Dictation does not work. I know my Mac microphone works just fine. It just seems like the simulator is not getting my voice input.

Following up on my last question, I noticed that when we build, if there's a failure to resolve package dependencies, if previously package dependency resolution succeeded, then the failure is not treated as an error but only as a warning.

This may be an Xcode problem not with SPM, but when I add a package into my App project, as a local package, whenever I change the dependencies of the package, even if the change to the version conflicts with the app's version constraints, the Xcode build the app just fine. I have to close and reopen the project again before the Xcode detects the change and raise an error during the build process. Why can't SPM/Xcode just detect the change while the app is opened, and raise an error instead of using whatever cache it is using? Currently, the workaround is to never edit the package in the app project (even though I should be able to), but to open the package as separate project to make edits, then reopen the app project to build the app. Another workaround I'm trying out is to add the xcodebuild -resolvePackageDependencies as a step during the build process, to force the build to cancel if theres package dependency resolution errors. But why is Xcode just ignoring resolution errors ??

I am getting this error when trying to run my tests: Library not loaded: @rpath/XCTestCore.framework/XCTestCore Referenced from: <498690CD-C914-3EE9-8EC1-C3BA4EF513CA> /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/lib/libXCTestSwiftSupport.dylib Reason: tried: '/Users/<>/Library/Developer/Xcode/DerivedData/Sonnet-bqruszxvmhdevmbxdbnagkvhywae/Build/Products/Test Project-iphonesimulator/XCTestCore.framework/XCTestCore' (no such file) It is only appearing on the DeviceHub. When I run the tests in my xcode 26, with the old Simulator, they run just fine.

In the past, for any App Intent developers provide to the AppShortcutsProvider, there needed to be explicit phrases provided to trigger the AppShortcut from Siri -- and if the user try to trigger the Shortcut using a slightly different phrase then the Siri does not work. With Siri AI, will App Intents that don't fit any schemas work without needing every phrase to be explicitly programmed?

I have this code As you can see, the locale of the Environment is different from the Locale given by .current. This is a problem for me because I have code that uses String(localized:) and AttributedString. I would like to be able to preview them with the locale I set in the Environment without any additional work on my part. I assumed these Apis would use the locale set by the environment but no, it uses the locale as decided by the schema used to build the preview app. The current solution I have is to manually change the App Language in the Preview's scheme to be whatever I need to correctly localize the language in Preview.

I have this code struct TestAppleSuggestion: View { @Environment(\.locale) var locale: Locale var body: some View { VStack { VStack { Text("locale: \(locale.identifier)") Text(AttributedString(localized: LocalizedStringResource( "welcome", locale: locale ))) Text(AttributedString(localized: "welcome", locale: locale )) } } } } #Preview { TestAppleSuggestion().environment(\.locale, Locale(identifier: "fr-CA")) } Heres What I see in SwiftUi Previews The Localization is working for the LocalizedStringResource but not to the AttributedString. Why?

I'm trying to better understand how the onReceive modifier behaves in SwiftUI, specifically how its subscription lifecycle relates to view updates. Consider this example: TextField("Name", text: $name) .onReceive(Just(name)) { value in print(value) } This closure runs every time name changes. A common explanation is that SwiftUI recomputes body, which creates a new Just(name) publisher each time. However, this raises some questions for me about how onReceive actually works internally: When SwiftUI recomputes body, is the onReceive modifier recreated and resubscribed? Does SwiftUI automatically cancel the previous subscription when the view updates?