I have a SwiftUI app. It fetches records through CoreData. And I want to show some records on a widget. I understand that I need to use AppGroup to share data between an app and its associated widget. import Foundation import CoreData import CloudKit class DataManager { static let instance = DataManager() let container: NSPersistentContainer let context: NSManagedObjectContext init() { container = NSPersistentCloudKitContainer(name: "DataMama") container.persistentStoreDescriptions = [NSPersistentStoreDescription(url: FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: group identifier)!.appendingPathComponent("Trash.sqlite"))] container.loadPersistentStores(completionHandler: { (description, error) in if let error = error as NSError? { print("Unresolved error \(error), \(error.userInfo)") } }) context = container.viewContext context.automaticallyMergesChangesFromParent = true context.mergePolicy = NSMergePolicy(merge: .mergeByPropertyObjectTrumpMergePolicyType) } func save() { do { try container.viewContext.save() print("Saved successfully") } catch { print("Error in saving data: \(error.localizedDescription)") } } } // ViewModel // import Foundation import CoreData import WidgetKit class ViewModel: ObservableObject { let manager = DataManager() @Published var records: [Little] = [] init() { fetchRecords() } func fetchRecords() { let request = NSFetchRequest<Little>(entityName: "Little") do { records = try manager.context.fetch(request) records.sort { lhs, rhs in lhs.trashDate! < rhs.trashDate! } } catch { print("Fetch error for DataManager: \(error.localizedDescription)") } WidgetCenter.shared.reloadAllTimelines() } } So I have a view model that fetches data for the app as shown above. Now, my question is how should my widget get data from CoreData? Should the widget get data from CoreData through DataManager? I have read some questions here and also read some articles around the world. This article ( https://dev.classmethod.jp/articles/widget-coredate-introduction/ ) suggests that you let the Widget struct access CoreData through DataManager. If that's a correct fashion, how should the getTimeline function in the TimelineProvider struct get data? This question also suggests the same. Thank you for your reading my question.

I have a List with draggable items. According to this thread (https://developer.apple.com/forums/thread/664469) I had to use .itemProvider instead of .onDrag, because otherwise the selection of the list will not work anymore. The items in my list refer to a file URL. So the dragging allowed to copy the files to the destination of the drag & drop. Therefore I used this code .itemProvider { let url = ....... // get the url with an internal function return NSItemProvider(object: url as NSURL) } Since the update to macOS 15.1 this way isn't working anymore. It just happens nothing. I also tried to use .itemProvider { let url = .... return NSItemProvider(contentsOf: url) ?? NSItemProvider(object: url as NSURL) } but this doesn't work too. The same way with .onDrag works btw. .onDrag { let url = ....... // get the url with an internal function return NSItemProvider(object: url as NSURL) } but as I wrote, this will break the possibility to select or to use the primaryAction of the .contextMenu. Is this a bug? Or is my approach wrong and is there an alternative?

On iPadOS 26 beta, the navigation bar can appear inset underneath the status bar (FB18241928) This bug does not happen on iOS 18. This bug occurs when a full screen modal view controller without a status bar is presented, the device orientation changes, and then the full screen modal view controller is dismissed. This bug appears to happen only on iPad, and not on iPhone. This bug happens both in the simulator and on the device. Thank you for investigating this issue.

I want a different color, one from my asset catalog, as the background of my first ever swift UI view (and, well, swift, the rest of the app is still obj.c) I've tried putting the color everywhere, but it does't take. I tried with just .red, too to make sure it wasn't me. Does anyone know where I can put a color call that will actually run? Black looks very out of place in my happy app. I spent a lot of time making a custom dark palette. TIA KT @State private var viewModel = ViewModel() @State private var showAddSheet = false var body: some View { ZStack { Color.myCuteBg .ignoresSafeArea(.all) NavigationStack { content .navigationBarTitleDisplayMode(.inline) .toolbar { ToolbarItem(placement: .principal) { Image("cute.image") .font(.system(size: 30)) .foregroundColor(.beigeTitle) } } } .background(Color.myCuteBg) .presentationBackground(.myCuteBg) .sheet(isPresented: $showAddSheet) { AddView() } .environment(viewModel) .onAppear { viewModel.fetchStuff() } } .tint(.cuteColor) } @ViewBuilder var content: some View { if viewModel.list.isEmpty && viewModel.anotherlist.isEmpty { ContentUnavailableView( "No Content", image: "stop", description: Text("Add something here by tapping the + button.") ) } else { contentList } } var contentList: some View { blah blah blah } } First I tried the background, then the presentation background, and finally the Zstack. I hope this is fixed because it's actually fun to build scrollable content and text with swiftUI and I'd been avoiding it for years.

I don't know what triggered this in a previously-running application I'm developing: When I have the build target set to "My Mac (designed for iPad)," I now must delete all the app's build materials under DerivedData to get the app to build and run exactly once. Cleaning isn't enough; I have to delete everything. On second launch, it will crash without even getting to the instantiation of the application class. None of my code executes. Also: If I then set my iPhone as the build target, the app will build and run repeatedly. If I then return to "My Mac (designed for iPad)," the app will again launch once and then crash on every subsequent launch. The crash is the same every time: dyld[3875]: Symbol not found: _OBJC_CLASS_$_AVPlayerView Referenced from: <D566512D-CAB4-3EA6-9B87-DBD15C6E71B3> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Debugger/libViewDebuggerSupport.dylib Expected in: <4C34313C-03AD-32EB-8722-8A77C64AB959> /System/iOSSupport/System/Library/Frameworks/AVKit.framework/Versions/A/AVKit Interestingly, I haven't found any similar online reports that mention this symbol. Has anyone seen this behavior before, where the crash only happens after the first run... and gets reset when you toggle the target type?

My SwiftUI code runs fine on macOS, iOS(iPad) and larger iPhones, but will not display the detail view on smaller iPhones. Is there a way to force the smaller iPhones to display the detail view? And if not, When I put the App on the Apple store, for sale, will the Apple store be smart enough to flag the App as not appropriate for smaller iPhones, such as the SE (2nd and 3rd gen.) and prevent downloads? Thanks in advance for any guidance.

In a SwiftUI app for MacOS, vertical sliders that I'd created using a rotationEffect of 90° disappeared when I upgraded to Sonoma 14.5 (23F79). With rotations less than 90°, the slider is still visible, but its button is enlarged, growing in size as the rotation angle approaches 90°. Note that the sliders still work, even when rotated by 90° and invisible! The screenshot and code below demonstrates the problem, which did not exist in MacOS 14.2.1 struct ContentView: View { @State var speed = CGFloat(1) var body: some View { HStack { let angle: [Double] = [0, 45, 80, 85, 90] ZStack { ForEach(0...4, id: \.self) { i in ZStack () { Rectangle() Slider(value: $speed, in: 0...10 ) } .frame(width: 100, height: 10) .rotationEffect(.degrees(angle[i])) .offset(x: CGFloat(i * 100) - 180) } } } .padding() .frame(width: 600, height: 200) } } #Preview { ContentView() }

Hi, I am writing a calculator app in Swift 5 and decided to support eastern asian numerals to make it a bit interesting. The numeric display itself works well in Arabic langauge setting, but I have a protocol view that reports the entered data and results. I do it in a Grid with two Text items, one for the input and one for the result. The result contains a numeric string in U0660... arabic numerals, and that looks fine. The input is a construct looking like Text(number1) + Text(" ") + Text(operation), so it goes into a single Grid cell. The standard version looks like this: but the arabic version shows the numbers and operation symbols in the wrong sequence: I guess that has something to do with the mathematical symbols such as + and = simply register as ltr Text and confuse the text layout. If I localize π, the result looks different: So my question would be: How do I force a fragment such as Text(" +") to go in rtl direction? Is this a SwiftUI topic or doesit go deeper? I am looking at the Text element now, but may be that is the wrong approach.

I've been obsessed with this topic for the past couple of weeks and unfortunately there just isn't a good answer out there even from the community. Therefore I am hoping that I can summon Quinn to get an official Apple position (on what's seemingly a fairly fundamental part of using SwiftUI). Consider this simple example: import Foundation @MainActor @Observable class UserViewModel { var name: String = "John Doe" var age: Int = 30 // other properties and logic } // NetworkManager does not need to update the UI but needs to read/write from UserViewModel. class NetworkManager { func updateUserInfo(viewModel: UserViewModel) { Task { // Read values from UserViewModel prior to making a network call let userName: String let userAge: Int // Even for a simple read, we have to jump onto the main thread await MainActor.run { userName = viewModel.name userAge = viewModel.age } // Now perform network call with the retrieved values print("Making network call with userName: \(userName) and userAge: \(userAge)") // Simulate network delay try await Task.sleep(nanoseconds: 1_000_000_000) // After the network call, we update the values, again on the main thread await MainActor.run { viewModel.name = "Jane Doe" viewModel.age = 31 } } } } // Example usage let viewModel = UserViewModel() let networkManager = NetworkManager() // Calling from some background thread or task Task { await networkManager.updateUserInfo(viewModel: viewModel) } In this example, we can see a few things The ViewModel is a class that manages states centrally It needs to be marked as MainActor to ensure that updating of the states is done on the main thread (this is similar to updating @Published in the old days). I know this isn't officially documented in Apple's documentation. But I've seen this mentioned many times to be recommended approach including www.youtub_.com/watch?v=4dQOnNYjO58 and here also I have observed crashes myself when I don't follow this practise Now so far so good, IF we assume that ViewModel are only in service to Views. The problem comes when the states need to be accessed outside of Views. in this example, NetworkManager is some random background code that also needs to read/write centralized states. In this case it becomes extremely cumbersome. You'd have to jump to mainthread for each write (which ok - maybe that's not often) but you'd also have to do that for every read. Now. it gets even more cumbersome if the VM holds a state that is a model object, mentioned in this thread.. Consider this example (which I think is what @Stokestack is referring to) import Foundation // UserModel represents the user information @MainActor // Ensuring the model's properties are accessed from the main thread class UserModel { var name: String var age: Int init(name: String, age: Int) { self.name = name self.age = age } } @MainActor @Observable class UserViewModel { var userModel: UserModel init(userModel: UserModel) { self.userModel = userModel } } // NetworkManager does not need to update the UI but needs to read/write UserModel inside UserViewModel. class NetworkManager { func updateUserInfo(viewModel: UserViewModel) { Task { // Read values from UserModel before making a network call let userName: String let userAge: Int // Jumping to the main thread to safely read UserModel properties await MainActor.run { userName = viewModel.userModel.name userAge = viewModel.userModel.age } // Simulate a network call print("Making network call with userName: \(userName) and userAge: \(userAge)") try await Task.sleep(nanoseconds: 1_000_000_000) // After the network call, updating UserModel (again, on the main thread) await MainActor.run { viewModel.userModel.name = "Jane Doe" viewModel.userModel.age = 31 } } } } // Example usage let userModel = UserModel(name: "John Doe", age: 30) let viewModel = UserViewModel(userModel: userModel) let networkManager = NetworkManager() // Calling from a background thread Task { await networkManager.updateUserInfo(viewModel: viewModel) } Now I'm not sure the problem he is referring still exists (because I've tried and indeed you can make codeable/decodables marked as @Mainactor) but it's really messy. Also, I use SwiftData and I have to imagine that @Model basically marks the class as @MainActor for these reasons. And finally, what is the official Apple's recommended approach? Clearly Apple created @Observable to hold states of some kind that drives UI. But how do you work with this state in the background?

Demo project link https://cdn.pokekara.com/int/other/1737343007_fbcdee810da429552b12ffa2644d928c.zip

I am developing iOS App using SwiftUI and I notice that Myanmar font of number text on 18.4 have clipped on top and bottom. Does anyone have this issues and know the fix? I have provided the Screenshot also.

I'm unable to find the right combination modifiers to get drag and drop to work using the new .draggable(containerItemID:) and dragContainer(for:in:selection:_:) modifiers. The drag is initiated with the item's ID, the item is requested from the .dragContainer modifier, but the drop closure is never triggered. Minimal repro: struct Item: Identifiable, Codable, Transferable { var id = UUID() var value: String static var transferRepresentation: some TransferRepresentation { CodableRepresentation(contentType: .tab) } } struct DragDrop: View { @State var items: [Item] = [ Item(value: "Hello"), Item(value: "world"), Item(value: "something"), Item(value: "else") ] var body: some View { List(items) { item in HStack { Text(item.value) Spacer() } .contentShape(Rectangle()) .draggable(containerItemID: item.id) .dropDestination(for: Item.self) { items, session in print("Drop: \(items)") } } .dragContainer(for: Item.self) { itemID in print("Drag: \(itemID)") return items.filter { itemID == $0.id } } } } #Preview("Simple") { DragDrop() }

The following repro case results in a previews crash on Xcode 26 beta 3 (report attached). FB18762054 import SwiftUI final class MyItem: Identifiable, Labelled { var label: String init(_ label: String) { self.label = label } } protocol Labelled { var label: String { get } } struct HelloView: View { let label: String var body: some View { Text(label) } } struct ListView<Element: Labelled & Identifiable>: View { @Binding var elements: [Element] var body: some View { List { ForEach($elements, id: \.id) { $element in HelloView(label: element.label) // crash // Replacing the above with a predefined view works correctly // Text(element.label) } } } } struct ForEachBindingRepro: View { @State var elements: [MyItem] = [ MyItem("hello"), MyItem("world"), ] var body: some View { ListView(elements: $elements) } } #Preview("ForEachBindingRepro") { ForEachBindingRepro() } foreachbindingrepro-2025-07-12-020628.ips

I have a game app for iOS and iPadOS, which expects a full screen experience. I'd like to out of window resizing in iPadOS 26 as it negatively impacts the UI/UX of the app. I have UIRequiresFullScreen defined, but it doesn't seem to actually force full screen on iPadOS 26 anymore.

I am trying to understand why I am seeing crash reports for my code that creates a view from a NIB like the code below. The crash occurs when referencing contentView which should have been bound when the NIB was loaded. Am I missing something here other than checking the result of the loadNibNamed function call? class MyView: NSView { @IBOutlet var contentView: NSView! init() { super.init(frame: NSRect(x: 0, y: 0, width: 84.0, height: 49.0)) commonInit() } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } private func commonInit() { Bundle.main.loadNibNamed("MyView", owner: self, topLevelObjects: nil) translatesAutoresizingMaskIntoConstraints = false contentView.translatesAutoresizingMaskIntoConstraints = false addSubview(contentView) contentView.frame = self.bounds }

In Xcode 16 and Xcode 16.1 beta 2 the lazy loading of list does not work properly. Tested on physical device with iOS 17. Below is minimal code to reproduce this issue: You can see in the debug console how many child views are initialized based on the print statement. import SwiftUI @main struct TestDemoApp: App { let data = Array(1...1000) var body: some Scene { WindowGroup { List(data, id: \.self) { item in SomeView(item: item) } } } } struct SomeView: View { static var count = 0 let item: Int init(item: Int){ self.item = item Self.count += 1 print(Self.count) } var body: some View{ Text(String(item)) .frame(height: 100) } } When the view is shown the List creates all child views at once as shown in the console output: It does not loads only first 13 out of 1000 as it does in older xcode 15.2: As the List is quite often used component in Swiftui Apps, the apps will be slow, because all the data are loaded and the main thread will be stuck until all child views are loaded.

If I present "SFSafariViewController" when a "FamilyActivityPicker" is visible, it will automatically dismiss the "SFSafariViewController" and crash the "FamilyActivityPicker." I'm assuming the cause of the bug is that each is in a separate process (aside from the app), and there's some hacks to try to stop "FamilyActivityPicker" from crashing, and this is causing the new bug because "SFSafariViewController" is also in a separate process. (I'm not 100% if its just in 18.4 or iOS 18 overall...) (I'll try to file a feedback soon, but its 100% reproducible for me across multiple devices on iOS 18.4)

My app supports different plain text file formats, including the standard .txt and Markdown. When creating a new document, my app already asks which format it should have, so when saving it, I would expect that the save panel already selects that format in the popup button, but currently it always selects "Plain Text". For example, I would expect for a Markdown document that it selects "Markdown" instead of "Plain Text". Is there a way to force it to select the most specific format matching the document format?

I have some apps using SwiftData document based. They work as expected under iOS17, but not under iOS18: install the app on a iPad 11 pro (first gen) from my MacBook open the app and open an existing fils (perfect under iOS17) it shows a blank, white screen, no data I can create a new document, blank screen, no data When I open that newly created file on a iOS 17 iPad pro, it works perfect, as expected The apps were created from scratch under macOS 14.7 with the corresponding Xcode/Swift/UI version. iOS devices under iOS17 Are there any known problems with document based SwiftData-apps under iOS18, are there any changes one has to made? Thank You so much for any help!

Hi, This issue started with iOS 18, in iOS 17 it worked correctly. I think there was a change in SectionedFetchRequest so maybe I missed it but it did work in iOS 17. I have a List that uses SectionedFetchRequest to show entries from CoreData. The setup is like this: struct ManageBooksView: View { @SectionedFetchRequest<Int16, MyBooks>( sectionIdentifier: \.groupType, sortDescriptors: [SortDescriptor(\.groupType), SortDescriptor(\.name)] ) private var books: SectionedFetchResults<Int16, MyBooks> var body: some View { NavigationStack { List { ForEach(books) { section in Section(header: Text(section.id)) { ForEach(section) { book in NavigationLink { EditView(book: book) } label: { Text(book.name) } } } } } .listStyle(.insetGrouped) } } } struct EditView: View { private var book: MyBooks init(book: MyBooks) { print("Init hit") self.book = book } } Test 1: So now when I change name of the Book entity inside the EditView and do save on the view context and go back, the custom EditView is correctly hit again. Test 2: If I do the same changes on a different attribute of the Book entity the custom init of EditView is not hit and it is stuck with the initial result from SectionedFetchResults. I also noticed that if I remove SortDescriptor(\.name) from the sortDescriptors and do Test 1, it not longer works even for name, so it looks like the only "observed" change is on the attributes inside sortDescriptors. Any suggestions will be helpful, thank you.