Looks like the ticks parameter is now exposed in beta4. An example from the Apple headers: @State private var percentage = 0.5 Slider(value: $percentage) { Text("Percentage") } currentValueLabel: { Text("\(percentage)%") } ticks: { SliderTickContentForEach( stride(from: 0.0, through: 1.0, by: 0.25).map { $0 }, id: \.self ) { value in SliderTick(value) { label(for: value) } } }

The video shows a step parameter but it doesn't seem to exist in the current beta build, it doesn't compile.

There seems to be a potential bug in iOS that is causing black screen issues for 3rd party apps. We are seeing the same for our camera app where the capture session fails and the users have to reboot their devices to be able to capture photos. Others are seeing the same issue: https://developer.apple.com/forums/thread/785206 and I’ve seen other people on Twitter have the same problem across multiple apps trying to capture photos.

Did you figure this out? We are also getting reports from some of the users of our camera app that the preview remains black and they are unable to capture photos (iOS users, not sure if any iPad users had the issue as well). The only way to fix the issue is a full device reboot, restarting/re-installing the app doesn't fix the issue (it's like iOS has blacklisted the app and won't let it start a new session until the device is rebooted).

I should note that I am settings the CIRAWFilter extendedDynamicRangeAmount to 2.0 before calling outputImage and still not getting a EDR image color space. e.g. guard let filter = CIRAWFilter( imageURL: rawURL, options: [:] ) else { return nil } filter.extendedDynamicRangeAmount = 2.0 // also tried 1.0 filter.outputImage?.colorSpace -> still SDR not EDR

Thanks for taking a look. I tried some more things and it looks like it's a misleading compiler error, maybe nothing to do with the path variable at all even though the compiler says it is. I took the path variable out of the function temporarily, then it gave another error: "Task or actor isolated value cannot be sent; this is an error in the Swift 6 language mode". The containing class is marked as @Observable, so I'm assuming really it is complaining that "self" is getting pulled into the Task which can cause race conditions even though the compiler error does not say that. I added the Sendable protocol to the container class and the warning went away. Thanks for taking the time to look into it. Side note: Swift6 makes writing code miserable, it's so broken still, good idea poor execution.

I'm seeing the same. It used to work in previous versions of Xcode but not in 16.1, must be a bug.

When you select tinted your widget is rendered in accented mode. Accented mode splits the UI elements into two groups, the default group and the accented group. Basically you only get two colors the accented group will get the tinted color the other group is white. You swap your UI elements between the groups using the widgetAccentable modifier: https://developer.apple.com/documentation/swiftui/view/widgetaccentable(_:) You can still apply an opacity to the UI elements if you want. If you want them to be the original color then you can use the https://developer.apple.com/documentation/widgetkit/widgetaccentedrenderingmode property but that only applies to Image elements.

I get the same problem in multiple other places for example just running an SCNAction and having a completion handler also throws an error inside SceneKit, it seems like SceneKit is completely unusable with Swift6 enabled, I'm not sure how it can be so broken unless I'm doing something wrong, very frustrating.

It is more efficient if you reuse the same geometry instance across all SCNNode instances, so create it outside the loop, then you will only get one draw call for all the spheres instead of one draw call per node.

It doesn't seem like you can reduce the draw calls using multiple entities, but instead I used the new LowLevelMesh to render lots of geometry available in iOS18.

We were also having this issue. It was recommended to make sure that any images you have aren't too big, ideally somewhere around the size of the widget dimensions, that should help fix this problem. Reducing the size of the images we were using as backgrounds to our widgets seems to have helped us.

Great, thank you!

Was this ever clarified by an Apple employee? It doesn't seem like we should have to tick the diagnostics box based on the statement: "You are not responsible for disclosing data collected by Apple." for crash logs and diagnostics provided in the xcode interface, otherwise every app in the app store would have to have this option checked if it was required.

The WeatherKit option is un the Capabilities tab not App Services. You also need to register a WeatherKit key in the top level Keys section in the developer site. Once you have completed both of those step, this question has information on how to call the REST API using a JWT: https://developer.apple.com/forums/thread/707418