UIKit application. I have a UISegmentedControl which displays flags, using the emoji for the text of the segment (SegmentedControl defined in stroryboard). Depending app is in Portrait or Landscape, the segmented control is displayed vertically or horizontally. When horizontal, nothing to do, direct display from stroryboard, works as expected. When vertical (Portrait), I have to rotate the UISegmentedControl π/2. And To get the flags properly oriented, I rotate each image -π/2. That works fine when compiling with Xcode 16.4. But when compiling with Xcode 26.3, rotation of segments do not work. Here is the illustration, compile on target simulators 26.2 in both cases (3rd image explained below):                             Xcode 16.4           -               Xcode 26.3 subviews rotated   -     removed subviews rotation Now the code. I subclassed UISegmentedControl to draw at will. class SegmentedControlRotable: UISegmentedControl { @IBInspectable var vertical : Bool = false // IBInspectable is now ignored override func draw(_ rect: CGRect) { if vertical { self.transform = CGAffineTransform(rotationAngle: CGFloat.pi / 2.0) for subview in self.subviews { subview.transform = CGAffineTransform(rotationAngle: -CGFloat.pi / 2.0) // reverse rotate // 3rd picture: this line commented out. } } else { // does no change self.transform = CGAffineTransform(rotationAngle: 0.0) for subview in self.subviews { subview.transform = CGAffineTransform(rotationAngle: 0.0) } } } // More code with touchesEnded, works OK in both cases } In fact, with Xcode 26, segments are always drawn on an horizontal line. l I noticed that the structure of self.subviews is different. 19 subviews in Xcode 16, 12 in Xcode 26. I removed the rotation of subviews, and it's OK. Just flags are now vertical (as illustrated above). What do I miss ? How to rotate the subviews in Xcode 26 ?

I find these sample projects quite valuable: https://developer.apple.com/documentation/widgetkit/emoji-rangers-supporting-live-activities-interactivity-and-animations https://developer.apple.com/documentation/coredata/sharing-core-data-objects-between-icloud-users . Both use Swift 5, and it is not trivial to adopt Swift 6 with them. Any plans to update them? What is best approach for adopting Swift 6 on such sample code?

In Swift 6.4 or later, a RegexBuilder pattern can hang when an unbounded quantifier repeats a body that can match the empty string, where that body begins with NegativeLookahead. I've opened a corresponding issue and PR to resolve the issue in swift-experimental-string-processing. See below for a reproduction and a workaround. The regression affects apps running on OS 27 built with Xcode 27, which includes Swift 6.4. Running apps built with Xcode 27 on OS 26 or earlier demonstrates the expected behavior. Links: Issue: https://github.com/swiftlang/swift-experimental-string-processing/issues/865 PR: https://github.com/swiftlang/swift-experimental-string-processing/pull/866 FB23419149 and FB23179771 https://forums.swift.org/t/regexbuilder-infinite-loop-when-nullable-capture-starts-with-negativelookahead/87713 Reproduction In the reducer below, matching "A" repeatedly invokes the capture transform with an empty substring without advancing through the input. import RegexBuilder let regex = Regex { ZeroOrMore { Capture { NegativeLookahead { "a" } ZeroOrMore(.digit) } transform: { String($0) } // invoked repeatedly with "" } } _ = "A".matches(of: regex) // never returns Reduced string form: _ = try! Regex(#"(?:(?!a)\d*)*"#).firstMatch(in: "A") // never returns The issue is in the same forward-progress class as PR #851, which skips a nullable quantification's child subtree. Lookaround groups need the same treatment. The regression first appears in Swift 6.4-dev toolchains. I observed the issue in code running on iOS 27 beta 1 (24A5355q), then traced the regression to PR #849 in swift-experimental-string-processing. Workaround In the meantime, wrap the capture contents in Optionally { }: import RegexBuilder let digits = Regex { NegativeLookahead { "a" } ZeroOrMore(.digit) } let regex = Regex { ZeroOrMore { Capture { Optionally { digits } } transform: { String($0) } } } _ = "A".matches(of: regex)

I'm building an app with a UISplitViewController as the base, with the main content being a UITabBarController. I'm targeting iOS 26+ and using UIKit. I've customised the tabbar on iOS to have a different font family and size, and used some custom images. Running the same app on iPad, the tabbar moves to the top of the screen, ignores ALL the appearance proxy settings and strips out the images. Its now just giant floating text. Also noticed in portrait mode when the side bar from the split view is open, it compresses the width of the tab bar down to only show 2 elements at a time, with this weird custom scroll thing to move to the rest of the tabs. If the text wasn't so massive, maybe it could fit more. I really hate every inch of this thing. Its looks ugly and functions bizarrely. Why does it ignore all the tabbar appearance settings, and how can I customise it to add icons back with smaller text? Ideally I don't want to use one of the hacks to force it to think its compact mode to bring back the old tabbar, as i'm relying on traits already to fix some SplitView annoyances and don't want those to break. But would love to have the old tab bar style. Are there any settings or toggles that I can use?

With the 27 OSes using UserDefaults.standard.integer(forKey: ) can cause a crash with EXC_BAD_ACCESS (code=1, address=0x0) It has been seen on a Multiplatform app, up to now tested on iOS/iPadOS and visionOS 27 Beta 1. In our code we use UserDefaults.standard.integer(forKey: ) from a singleton called during the SwiftUI app init(), and we don't know yet if this is the only moment there is a crash as we can't go farther. The API should return 0 if it can't get a value. There is no reason the app should crash if the API conforms to its contract. Running the same code from Xcode on iOS 26 runs it without issue. FeedBack FB23310748

I’ve been experimenting with Foundation Models and built a small Swift package that wraps LanguageModelSession with simple context management. The current approach checks the transcript token count using tokenCount(for:), compacts the transcript when it reaches a threshold, and retries once if exceededContextWindowSize is thrown. I’d appreciate feedback on whether this is a sensible use of Foundation Models APIs, especially around rebuilding a session from a compacted Transcript. GitHub: https://github.com/ricky-stone/FoundationContext

Description I've encountered a consistent hang/freeze issue in SwiftUI applications when using nested LazyVStack containers with Accessibility Inspector (simulator) or VoiceOver (physical device) enabled. The application becomes completely unresponsive and must be force-quit. Importantly, this hang occurs in a minimal SwiftUI project with no third-party dependencies, suggesting this is a framework-level issue with the interaction between SwiftUI's lazy view lifecycle and the accessibility system. Reproduction Steps I've created a minimal reproduction project available here: https://github.com/pendo-io/SwiftUI_Hang_Reproduction To Reproduce: Create a SwiftUI view with the following nested LazyVStack structure: struct NestedLazyVStackView: View { @State private var outerSections: [Int] = [] @State private var innerRows: [Int: [Int]] = [:] var body: some View { ScrollView { LazyVStack(alignment: .leading, spacing: 24) { ForEach(outerSections, id: \.self) { section in VStack(alignment: .leading, spacing: 8) { Text("Section #\(section)") // Nested LazyVStack LazyVStack(alignment: .leading, spacing: 2) { ForEach(innerRows[section] ?? [], id: \.self) { row in Text("Section #\(section) - Row #\(row)") .onAppear { // Load more data when row appears loadMoreInner(section: section) } } } } .onAppear { // Load more sections when section appears loadMoreOuter() } } } } } } Enable Accessibility Inspector in iOS Simulator: Xcode → Open Developer Tool → Accessibility Inspector Select your running simulator Enable Inspection mode (eye icon) Navigate to the view and start scrolling Result: The application hangs and becomes unresponsive within a few seconds of scrolling Expected Behavior The application should remain responsive when Accessibility Inspector or VoiceOver is enabled, allowing users to scroll through nested lazy containers without freezing. Actual Behavior The application freezes/hangs completely CPU usage may spike The app must be force-quit to recover The hang occurs consistently and is reproducible Workaround 1: Replace inner LazyVStack with VStack LazyVStack { ForEach(...) { section in VStack { // ← Changed from LazyVStack ForEach(...) { row in ... } } } } Workaround 2: Embed in TabView TabView { NavigationStack { NestedLazyVStackView() // ← Same nested structure, but no hang } .tabItem { ... } } Interestingly, wrapping the entire navigation stack in a TabView prevents the hang entirely, even with the nested LazyVStack structure intact. Questions for Apple Is there a known issue with nested LazyVStack containers and accessibility traversal? Why does wrapping the view in a TabView prevent the hang? Are there recommended patterns for using nested lazy containers with accessibility support? Is this a timing issue, a deadlock, or an infinite loop in the accessibility system? Why that happens? Reproduction Project A complete, minimal reproduction project is available at: https://github.com/pendo-io/SwiftUI_Hang_Reproduction

I'm looking for a way to prevent my app from displaying in screenshots and screen recordings. There appears to be plenty of options for UIKit/iOS but nothing I can find for macOS. userDidTakeScreenshotNotification @Environment(.sceneCaptureState) private var captureState Obviously it's possible though as I remember back in the day you couldn't take screenshots of the DVD Player etc.

I’m working on a storyboard-based AppKit application that uses an NSWindowController containing an NSSplitViewController with multiple child view controllers. The hierarchy is roughly: NSWindowController └── NSSplitViewController ├── NSViewController ├── NSViewController └── NSViewController I am trying to provide dependencies during storyboard instantiation using either @IBSegueAction or instantiateInitialController(creator:), rather than configuring everything after initialisation. What I attempted I added custom initialisers to my view controllers so I can pass dependencies at creation time: class SplitViewController: NSSplitViewController { let dependency: Dependency init?(coder: NSCoder, dependency: Dependency) { self.dependency = dependency super.init(coder: coder) } required init?(coder: NSCoder) { print("init(coder:) was called") fatalError("init(coder:) is not supported") } } I then attempted to intercept storyboard instantiation using @IBSegueAction, trying it in both the window controller and the split view controller: @IBSegueAction func makeSplitViewController(_ coder: NSCoder) -> NSSplitViewController? { SplitViewController(coder: coder, dependency: dependency) } I also tried attaching the segue action at different points in the storyboard, but the behaviour did not change. Observed behaviour Regardless of where I place the segue action, AppKit still appears to call: required init?(coder: NSCoder) This means my custom initialiser is never used for the split view controller or its children. Background reference I found this older known issue in the Xcode 11 release notes: “A Segue Action on a relationship segue between a NSWindowController and a View Controller is currently not supported and ignored. (48252727)” This suggests that, at least historically, AppKit relationship segues ignored segue actions entirely. Has this limitation since been fixed in modern Xcode/macOS SDK releases, or are relationship segues involving NSWindowController still incompatible with @IBSegueAction? More generally, what is the intended way to provide dependencies to an NSSplitViewController and its child view controllers in a storyboard-based AppKit application? I am also unclear whether instantiateInitialController(creator:) participates in the creation of container hierarchies like split view controllers, or only top-level controllers.

I'm trying to build a profile-style screen similar to X (Twitter), Instagram, or YouTube. The layout is roughly: ┌──────────────────────────┐ │ Profile Header │ │ Cover image │ │ Avatar │ │ Bio / Stats │ └──────────────────────────┘ ┌──────────────────────────┐ │ Tab Bar │ │ Posts | Media | Likes │ └──────────────────────────┘ ┌──────────────────────────┐ │ Tab Content │ │ │ │ ScrollView / List │ │ OR │ │ Empty State VStack │ │ │ └──────────────────────────┘ Requirements: The profile header should collapse while scrolling up. The tab bar should remain pinned. Once the header is fully collapsed, the active tab's scroll view should start scrolling. While scrolling down, the active tab should scroll back to the top first, then the header should expand. Some tabs may contain: ScrollView + LazyVStack List a non-scrollable VStack (for empty states) The behavior should remain consistent regardless of which tab is active. This feels very similar to Jetpack Compose's NestedScrollConnection, where parent and child scroll containers can cooperatively consume scroll deltas. In SwiftUI, I have explored: ScrollView GeometryReader PreferenceKey Scroll offset tracking Custom UIScrollView wrappers A UIViewControllerRepresentable approach that intercepts pan gestures and coordinates scrolling manually However, I haven't found a SwiftUI-native way for a parent container and child scroll view to negotiate scroll consumption. My questions are: Does SwiftUI provide any equivalent to Compose's NestedScrollConnection? Is there a recommended way to implement this profile-screen pattern purely in SwiftUI? How are people handling cases where some tabs contain scrollable content while other tabs contain only static content? Is bridging to UIKit currently the only practical solution for this kind of coordinated scrolling behavior? Any guidance or examples would be greatly appreciated.

Hi, I have a app group registered in mac os app called gorup.com.company.app and i am saving the key/values in userdefaults to this with suitname. within the mac os app the group userdedaults write/read are working fine. I have a switt cli app with same app group registered in the code signing entitilement for the swit cli app. trying to read the group user default key value registered in mac os app in swift cli app returning no value. this was working fine with macOS 26. Is there some changes have been made in macos 27 in regaard to this?

I have an application which records video along with some custom metadata and a chapter track. The resultant video is stored in the Camera Roll. When sharing the video via the Share Sheet or AirDrop, the metadata track is stripped entirely (the chapter markers are preserved) Sharing via AirDrop with the "All Photos Data" option does include the metadata track, as does copying from the device with Image Capture but this is a bad user experience as the user must remember to explicitly select this option, and the filename is lost when sending this way. I have also tried various other approaches (such as encoding my metadata in a subtitle track, which I didn't expect to be stripped as it's an accessibility concern) but it's also removed. Essentially I am looking for a definitive list of things that are not stripped or if there's a way to encode a track in some way to indicate it should be preserved. The metadata is added via AVTimedMetadataGroup containing one AVMutableMetadataItem which has its value as a JSON string. I took a different approach with the Chapter Marker track (mainly because I did it first in a completely different way and didn't rework it when I added the other track). I post-process these after the video is recorded, and add them with addMutableTrack and then addTrackAssociation(to: chapterTrack, type: .chapterList) but I don't think that's the reason the chapter track persists where the custom metadata does not as other tests with video files from other sources containing subtitles etc also had their subtitle data stripped. tl;dr I record videos with metadata that I want to be able to share via Share Sheet and AirDrop, what am I doing wrong?

Hi everyone, I've been working on a problem that I think many of us building AI in Swift are facing: how do you debug why an AI agent behaves differently between runs? Traditional logging tells you what happened. But when a model skips a step, changes its reasoning order, or produces a different output with identical input — you're left staring at walls of logs with no clear answer to why. I've released DProvenanceKit — a reasoning observability framework for Swift that lets you: Record every reasoning step an agent takes (non-blocking, async-safe) Query for reasoning patterns ("find runs where X happened but Y didn't") Diff two executions to see structural differences Detect regressions automatically with rule-based validation Think of it as Git for AI logic. Example: Swift // Record an execution try await DProvenanceKit.run(contextID: "case-123", store: store) { DProvenanceKit.record(.documentEvaluated(documentID: "DocA", score: 0.95)) DProvenanceKit.record(.conflictDetected(reason: "timeline_inconsistency")) DProvenanceKit.record(.finalDecisionMade(approved: false)) } // Query for suspicious patterns let suspiciousRuns = try await store.queryRuns( TraceQueryDSL() .requiring(step: "conflictDetected") .missing(step: "documentEvaluated") // Find runs where conflict was reported but no docs evaluated ) // Diff two runs let diff = engine.diff(base: runA, comparison: runB) print(diff.changes) // See exactly which steps appeared, disappeared, or moved The design: Built specifically for on-device AI (macOS/iOS) with Apple Foundation Models, MLX, or Core ML Non-blocking recording (touches only in-memory buffer) Durable, crash-safe persistence with SQLite WAL Works with async/await context propagation Status: Experimental (core engine complete, actively evolving). Free for development/testing under BSL 1.1. GitHub: https://github.com/Therealdk8890/DProvenanceKit I'm curious if this resonates with anyone here building AI in Swift. What debugging/observability challenges are you facing with AI systems?

In 2018, Apple staff noted that Safari App Extensions had no direct API to communicate with the containing app, and suggested app groups or opening a custom URL scheme as workarounds. On iOS Safari Web Extensions, app groups work for persistence, but opening the containing app from the native extension/background flow does not appear reliable. iOS launch policy seems to require a direct user gesture, and I have not found a documented way for the extension flow to reliably continue into the containing app. Is there a supported iOS architecture for completing an extension-initiated workflow in the containing app, or is the intended model to persist data and require the user to manually open the app? My current architecture is: JavaScript in the Safari Web Extension extracts article content from the page. The native Extension Handler receives that content via native messaging. The Extension Handler writes an encoded request into the App Group container. The containing app watches the App Group container using DispatchSource.makeFileSystemObjectSource and processes new requests. This works on macOS. It also works on iOS when the containing app is already running. The problem is that on iOS, if the containing app is not already running, there is no app process to observe the filesystem event or process the request. I have tried treating the Extension Handler as the place to do more work, but in practice it seems suited only for short-lived relay/persistence work. It is not a reliable place for my app’s main processing pipeline, which includes rendering article content and uploading it to a third-party service. My app is a Safari-native “read later” style tool that uploads simplified articles to the reMarkable Cloud. The containing app contains most of the functionality: SwiftUI UI, WebKit/WebPage rendering, account/cloud logic, and upload orchestration. The Safari extension captures the article, but the app needs to run to complete the user-visible workflow. From a user’s perspective, tapping the Safari extension toolbar button is the action that initiates the workflow. Is there any supported way for that user-initiated extension action to launch or wake the containing iOS app so it can process pending App Group requests? Or should Safari Web Extensions on iOS be designed only to persist work and then ask the user to manually open the containing app? If manual app launch is the intended model, it would be helpful for the documentation to state this explicitly. The current tripartite model strongly suggests that the JavaScript extension, native handler, and containing app can collaborate as parts of one workflow, but on iOS the containing app appears to be available only out-of-band unless already running.

I submitted this to Feedback Assistant as FB22331090 and wanted to share a minimal reproducible example here in case others are seeing the same issue. Environment: Xcode 26.4 or Xcode 26.3 Apple Swift version 6.3 (swiftlang-6.3.0.123.5 clang-2100.0.123.102) Effective Swift language version 5.10 Deployment target: iOS 17.0 The sample app builds successfully for normal development use, but archive fails. The crash happens during optimization in EarlyPerfInliner while compiling the synthesized deinit of a nested generic Coordinator class. The coordinator stores a UIHostingController. Minimal reproducer: import SwiftUI struct ReproView<Content: View>: UIViewRepresentable { let content: Content func makeUIView(context: Context) -> UIView { context.coordinator.host.view } func updateUIView(_ uiView: UIView, context: Context) { context.coordinator.host.rootView = content } func makeCoordinator() -> Coordinator { Coordinator(content: content) } final class Coordinator { let host: UIHostingController<Content> init(content: Content) { host = UIHostingController(rootView: content) } } } Used from ContentView like this: ReproView(content: Text("Hello")) Steps: Create a new SwiftUI iOS app. Set deployment target to iOS 17.0. Add the code above. Archive. Expected result: Archive succeeds, or the compiler emits a normal diagnostic. Actual result: The Swift compiler crashes and prints: "Please submit a bug report" "While running pass ... SILFunctionTransform 'EarlyPerfInliner'" The crash occurs while compiling the synthesized deinit for ReproView.Coordinator. Relevant log lines from my archive log: line 209: Please submit a bug report line 215: While running pass ... EarlyPerfInliner line 216: for 'deinit' at ReproView.swift:19:17 One more detail: The same sample archived successfully when the deployment target was higher. Lowering the deployment target to iOS 17.0 made the archive crash reproducible. This may be related to another forum thread about release-only compiler crashes, but the reproducer here is different: this one uses a generic UIViewRepresentable with a nested Coordinator storing UIHostingController.

Summary We have identified a reproducible world tracking drift regression in ARKit on LiDAR-equipped iOS devices running iOS 26.4 and later. A static virtual node anchored at the world origin visually drifts from its initial position as the user moves around a real-world scene, despite the scene remaining physically static. The same code produces stable, drift-free results on non-LiDAR devices running identical OS versions. Device & OS Observations Testing was performed across four devices on iOS 26.4 using the same application build and ARWorldTrackingConfiguration settings. Non-LiDAR devices — iPhone 14 and iPhone 15 — produced stable, drift-free tracking in all test runs. No world origin displacement was observed regardless of how long or how far the user walked. LiDAR-equipped devices — iPhone 14 Pro and iPhone 16 Pro — exhibited consistent, reproducible drift. A static node placed at the world origin visually shifted from its initial position as the user moved through the scene. The same devices were stable on earlier iOS versions, confirming this is a regression introduced in iOS 26.4. Technical Observations Nature of drift: A SCNNode placed statically at the ARKit world origin (SCNVector3(0, 0, 0)) visually displaces from its original position as the user walks around a static real-world scene. The displacement is not random — it accumulates directionally as the user moves, consistent with a sensor fusion or coordinate anchoring error. Trigger condition: The drift occurs during normal walking motion around a fixed point of interest, such as circling a parked vehicle. It does not appear when the device is held still. LiDAR specificity: The drift is exclusive to devices with a LiDAR scanner. Identical hardware configurations — same iOS build, same ARWorldTrackingConfiguration settings — on non-LiDAR devices produce no drift whatsoever. This isolates the regression to the LiDAR sensor's contribution to ARKit's internal Visual-Inertial Odometry (VIO) fusion pipeline. No API-level workaround found: There is currently no public ARKit API to selectively disable the LiDAR scanner's contribution to VIO. All available configuration-level options have been evaluated without resolving the drift. ARWorldTrackingConfiguration Options Evaluated The following configuration changes were applied individually and in combination. None resolved the drift on LiDAR devices: isAutoFocusEnabled = false — No improvement videoHDRAllowed = false (disabled) — No improvement planeDetection = [] (disabled) — No improvement sceneReconstruction = .mesh — No improvement worldAlignment: .gravity vs .gravityAndHeading — No improvement Minimal Reproduction Case The drift can be reproduced with a minimal ARKit scene: Create an ARSCNView with ARWorldTrackingConfiguration using default settings. Add a single static SCNNode (e.g., a small sphere or axes geometry) at SCNVector3(0, 0, 0) when the session starts. Run the app on a LiDAR-equipped device (iPhone Pro, iPad Pro with LiDAR) on iOS 26.4 or later. Walk in a circle around the node's approximate real-world position. Expected: The node remains visually fixed at its world position throughout the walkthrough. Actual: The node drifts from its initial position, increasingly displaced from its world origin anchor as walking continues. We want to know if Apple has made any internal updates to ARKit, particularly after the OS 26.4 upgrade. Thanks!

I've tried multiple variations of the below but nothing seem to work. The output is alwaysError: sharePath blabla Not ValidFor some reason NetFSMountURLSync is not working in Swift 4.import Cocoaimport NetFS@NSApplicationMainclass AppDelegate: NSObject, NSApplicationDelegate { var fileSystemProtocol: String = "smb" var logServer: String = "smb://myservername" var logShareName: String = "/Scripts" var userName: String = "" var password: String = "" func applicationDidFinishLaunching(_ aNotification: Notification) { mountShare(serverAddress: logServer, shareName: logShareName, userName: userName, password: password) } func applicationWillTerminate(_ aNotification: Notification) { } func mountShare( serverAddress: String, shareName: String, userName: String, password: String) { let fm = FileManager.default let mountPoint = "/Volumes/".appending(shareName) var isDir : ObjCBool = false if fm.fileExists(atPath: mountPoint, isDirectory:&amp;isDir) { if isDir.boolValue { unmount(mountPoint, 0) print("unmount \(mountPoint)") } } let sharePath = NSURL(string: "\(serverAddress)\(shareName)")! let mounted: Int32 = NetFSMountURLSync(sharePath, nil, nil, nil, nil, nil, nil) if mounted &gt; 0 { print("Error: sharePath: \(sharePath) Not Valid") } else { print("Mounted: \(sharePath)") } }}

Providing a response and feedback to this: https://origin-devforums.apple.com/forums/thread/827311 and https://developer.apple.com/forums/thread/827043?page=1#889020022 I have a created a feedback/bug report with ID FB22823733 Feedback Report: I have created a feedback report as well like recommended with this ID: FB22823733, with more elaborate images of my implementation, also see here More clarity: Yes, this is for an iOS app(iOS 18+) but testing and debugging on Xcode(MacOS 15.7.7, M4 24GB), which traps or hangs on getting to [PhotogrammetrySample] even while using the lazy sequence and the contentsOf as specified in your docs. I also tried using the PhotogrammetrySession folder run but its still failed with : CoreOC.PhotogrammetrySession.Error 6 and I understand to mean alignment failed. What can be done or do you guys expose any functions that can be used to aid, or handle these internally, can't find any internally. The ObjectMasks are actually segmentation masks from an ML algorithm . To replicate try calling PhotogrammetrySession(input: [PhotogrammetrySample]) with contentsOf as captured on your documentation, even with like 30 image set or is there something I'm missing.

How to build the below UI using SwiftUI? I tried to use Picker with wheel style, but it is not the same as the screenshot. The screenshot came from the iOS built-in calendar app. Add a new calendar event Click "Repeat" Choose "Custom" Click "Every day" The required picker wheel will be displayed Picker("Every", selection: $interval) { ForEach(1..<366) { interval in Text("\(interval)").tag(interval) } } .pickerStyle(.wheel)

It seems that the behavior of the .copy rule in SPM packages has changed in Xcode 27. This change now results in raw files being copied into the bundle without compilation, resulting in crashes and missing resources since uncompiled resources cannot be used by the OS. More specifically, in Xcode 26, when .copy was applied to resources such as storyboards, asset catalogs, etc. it would cause Xcode to compile those resources into the respective storyboardc or Assets.car before copying. Xcode 27 does not do this and instead copies the raw files. I do understand that there is a difference between .process and .copy, and the documentation does state that the process rule needs to be used for those files. Is this a regression in Xcode 27 or is copy not compiling anything expected behavior? Submitted FB23115950