Anybody can help me with the problems of splashboard? My request is to create a launchScreen.storyboard that can follows system's theme. So in the storyboard i use the image set resource which is created in Assets.xcassets. But i encountered the following problems： when i use image set resource，the splashboard is black, seems like springboard fail to generate the ktx file. But when i move the same image file to the root of Resource directory, it works. Why???? Some image works when it is put in Image set, some file can't. But all file don't work when the image set contains both light image and dark image. Why??? Suddenly it works for when i change compression attribute to lossess，so i guess the problems hanppened when my image is compressed. And two days later, the splash board is dark again when i debug. So what is the cache strategy for the splash board and the image resource used. How can i clear the cache, delete the app is not enough? Should i restart my phone? That's all, anybody can help me?

Hey, I've been having a problem with scroll views in combination with the .geometryGroup() modifier. I have filed a Feedback (FB17698293) but I also wanted to post this here in case someone maybe has a better workaround for the problem. Problem Whenever you conditionally insert a ScrollView inside a VStack that is modified with a .geometryGroup() modifier, the scroll view content offset resets itself after the insertion animation is done, even if you started scrolling inside the scroll view during the animation and haven't let go of the screen. This happens consistently and is fully reproducible (see below), both using a simulator and a real device. Unfortunately, this is a very annoying glitch that ruins a lot of cool UX components that rely on .geometryGroup(). The weird thing is that the glitch entirely disappears, if you add a simple, non-zero (but greater than 1) .padding() modifier to the VStack (.padding().geometryGroup()). I have no idea why this fixes the glitch, but it does. However, adding a padding is not feasible in many situations, so this workaround is not ideal. Steps to reproduce Launch the code below (using a simulator or a real device) and tap "Toggle Expansion" to insert the scroll view. As the view is animating in, drag the scroll content and hold it scrolled away from the top. Wait for the animation to complete. The scroll view will reset the content offset, even though the drag gesture is still active (i.e. you haven't lifted your finger to release the scroll view) On a real device, this sometimes even leads to an even worse visual artifact where the scroll view is rendered twice for a few frames; once with the correct offset, and once with the reset offset. I wanted to include a link to a gif/video showing the glitch, but it tells me that imgur is not allowed on the forums. Expected Behavior I want the scroll view to respect the content offset, even if I started changing it mid-animation. Xcode Version I am using Xcode 16.4 (16F6) but this problem has been occurring since the .geometryGroup() modifier has been release. I was only now able to pinpoint this problem exactly, so I'm filing this feedback. Code The entire code that reproduces the problem: import SwiftUI struct ContentView: View { @State private var isExpanded: Bool = false var body: some View { VStack { if isExpanded { ScrollView { Text(loremIpsum) } } Button("Toggle Expansion") { isExpanded.toggle() } } // .padding(10) // Adding a non-zero padding makes the glitch disappear .frame(maxWidth: .infinity) .geometryGroup() .animation(.default, value: isExpanded) } } #Preview { ContentView().preferredColorScheme(.dark) } // MARK: - Mock Data let loremIpsum = """ Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt \ ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco \ laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla \ pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt \ mollit anim id est laborum. """

Device: iPhone 16 Pro Max System Version: 18.3.1 Screen width and height obtained using [UIScreen mainScreen].bounds.size are as follows Why are the two results different?

Hello, I've been trying to figure this thing for a while now, but I've not able to find any resolution. I've a UIAlertController object presented as UIAlertControllerStyleActionSheet. It's fairly straightforward code: UIAlertController *listSheet = [UIAlertController alertControllerWithTitle:NSLocalizedStringFromTableInBundle(@"Please Select a Report", nil, [LDKLocalizationTool currentBundle], @"Chart report selector") message:nil preferredStyle:UIAlertControllerStyleActionSheet]; [self.charts enumerateObjectsUsingBlock:^(ChartDefinition *chart, NSUInteger idx, BOOL *stop) { UIAlertAction *anAction = [UIAlertAction actionWithTitle:chart.graphLabel style:UIAlertActionStyleDefault handler:^(UIAlertAction *action) { // handler logic }]; [listSheet addAction:anAction]; }]; // Set the anchor point for the AlertController UIPopoverPresentationController *popoverPresenter = [listSheet popoverPresentationController]; if (popoverPresenter) { popoverPresenter.sourceView = sender; popoverPresenter.sourceRect = [sender bounds]; } // Display the AlertController [self presentViewController:listSheet animated:YES completion:nil]; However, when presented, the action sheet shows up as shown in the attached screenshot. There are no autoLayout constraints or anything like that to cause issues with layout. I'm not sure why it's causing this issue. Any suggestions or help is much appreciated! iPadOS version: 18.4 Xcode version: 16.3 M4 Mac with macOS 15.5

I am working on implementing a new Intents UI Extension and have noticed that when it is triggered via the "Hey Siri" voice command, the intent dismisses after a few seconds. However, if it is launched from the Shortcuts app, the intent remains active and does not dismiss automatically. Additionally, I’ve observed that this behavior occurs on specific iOS versions, such as 17.5.1 or 17.7. On other versions, like 17.4.1 or 18.4, the intent persists as expected. Does Siri automatically close the intent based on its own logic? Could the iOS version be influencing this behavior? Given the requirement to make the intent persistent, is there any option or configuration available to achieve this?

Dear all, Sorry if the topic has already been commented but I could not be able to find it in over 10,000 picks using the forum search field... My problem is that with any NSTextField in my app, a click will result in a memory leak. There is no code attached, just bindings to NSNumber properties. How can I fix this ? Thanks for your help. Best regards Chris

I'm currently integrating SwiftUI into an AppKit based application and was curious if the design pattern below was viable or not. In order to "bridge" between AppKit and SwiftUI, most of my SwiftUI "root" views have aViewModel that is accessible to the SwiftUI view via @ObservedObject. When a SwiftUI views need to use NSViewRepresentable I'm finding the use of a ViewModel and a Coordinator to be an unnecessary layer of indirection. In cases where it makes sense, I've just used the ViewModel as the Coordinator and it all appears to be working ok, but I'm curious if this is reasonable design pattern or if I'm overlooking something. Consider the following pseudo code: // 1. A normal @ObservedObject acting as the ViewModel that also owns and manages an NSTableView. @MainActor final class ViewModel: ObservedObject, NSTableView... { let scrollView: NSScrollView let tableView: NSTableView @Published var selectedTitle: String init() { // ViewModel manages tableView as its dataSource and delegate. tableView.dataSource = self tableView.delegate = self } func reload() { tableView.reloadData() } // Update view model properties. // Simpler than passing back up through a Coordinator. func tableViewSelectionDidChange(_ notification: Notification) { selectedTitle = tableView.selectedItem.title } } // 2. A normal SwiftUI view, mostly driven by the ViewModel. struct ContentView: View { @ObservedObject model: ViewModel var body: some View { Text(model.selectedTitle) // No need to pass anything down other than the view model. MyTableView(model: model) Button("Reload") { model.reload() } Button("Delete") { model.deleteRow(...) } } } // 3. A barebones NSViewRepresentable that just vends the required NSView. No other state is required as the ViewModel handles all interactions with the view. struct MyTableView: NSViewRepresentable { // Can this even be an NSView? let model: ViewModel func makeNSView(context: Context) -> some NSView { return model.scrollView } func updateNSView(_ nsView: NSViewType, context: Context) { // Not needed, all updates are driven through the ViewModel. } } From what I can tell, the above is working as expected, but I'm curious if there are some situations where this could "break", particularly around the lifecycle of NSViewRepresentable Would love to know if overall pattern is "ok" from a SwiftUI perspective.

Our iOS app, when running as an iOS App on Mac, crashes consistently under the following scenario: 1. Launch the app on an external display. 2. Minimize the app window. 3. Disconnect the external display. The app crashes every time under these conditions. The crash log shows the following call stack: *** Assertion failure in -[UINSWorkspace _maximumContentSizeForWindowOnScreen:], UINSWorkspace.m:401 -[UINSWorkspace _maximumContentSizeForWindowOnScreen:]: screen parameter should not be nil ( 0 CoreFoundation 0x000000018e841df0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000018e306b60 objc_exception_throw + 88 2 Foundation 0x000000018fb6aa78 -[NSCalendarDate initWithCoder:] + 0 3 UIKitMacHelper 0x00000001a9a59110 -[UINSWorkspace _maximumContentSizeForWindowOnScreen:] + 184 4 UIKitMacHelper 0x00000001a9a3e748 -[UINSSceneViewController _usableScreenSizeWithSceneSize:shouldOverride:] + 412 5 UIKitMacHelper 0x00000001a9a3d55c -[UINSSceneViewController _effectiveScaleFactorForLayoutWithOverride:] + 88 6 UIKitMacHelper 0x00000001a9a3f3a8 -[UINSSceneViewController _updateZoomFactors] + 28 7 UIKitMacHelper 0x00000001a9a3f248 -[UINSSceneViewController _updateZoomFactorsAndDoLayout] + 24 8 UIKitMacHelper 0x00000001a9a3df80 -[UINSSceneViewController _doUpdates:] + 104 9 UIKitMacHelper 0x00000001a99ad460 -[UINSSceneViewController observeValueForKeyPath:ofObject:change:context:] + 176 10 Foundation 0x000000018facb0d8 -[NSKeyValueObservance observeValueForKeyPath:ofObject:change:context:] + 388 11 Foundation 0x000000018facb0d8 -[NSKeyValueObservance observeValueForKeyPath:ofObject:change:context:] + 388 12 Foundation 0x000000018fa8f7b4 NSKeyValueNotifyObserver + 252 13 Foundation 0x000000018fb3c560 NSKeyValueDidChange + 388 14 Foundation 0x00000001903149a0 NSKeyValueDidChangeWithPerThreadPendingNotifications + 160 15 AppKit 0x00000001924673d4 -[NSThemeFrame _didChangeContentLayoutRect] + 76 16 AppKit 0x000000019246521c -[NSWindow _oldPlaceWindow:fromServer:] + 744 ) It seems like the system attempts to access a screen object that is already nil after the external monitor is removed. This leads to an assertion failure in UINSWorkspace. Is there any known workaround or update planned to address this issue? Thank you.

I am trying to make a collection view with self-sizing cells that adapt to SwiftUI content. My test platform is macOS, but it should work on iOS all the same. I chose macOS because on macOS, you can resize the window and cause more interesting scenarios with that. My layout intent is fairly simple: a one-column collection view with cells with SwiftUI content, where the collection view cells should adapt to the height of their SwiftUI content. I got it working almost correctly. The one scenario that I don’t have working is window resizing. When the window resizes, the layout and cells should adapt to the content and change their heights. I feel that I am missing something fairly basic. How do I change this project so that the layout works correctly when I change the macOS window width? Example project and video of the behavior: https://gist.github.com/jaanus/66e3d863941ba645c88220b8a22970e1

When I add a simple menu to the dock via the NSApplicationDelegate method -applicationDockMenu: and run the app from Xcode it doesn't work. -(NSMenu*)applicationDockMenu:(NSApplication*)sender { NSMenu *dockMenu = [self buildDockMenu]; if (dockMenu != nil) { NSLog(@"Returning dock menu."); return dockMenu; } else { NSLog(@"Not ready to build dock menu"); return nil; } } When I run the app, my main app window shows up but nothing logs out in -applicationDockMenu: until I click outside my app's window (so if I click the desktop background, or a Finder window, or whatever). Then after I click outside my app's main window this logs out: Returning dock menu. The "Not ready to build dock menu" message does not log out. But...when I right click on the dock icon, the menu doesn't show up. But if I stop the app from Xcode and just run it not attached to the debugger, the dock menu does show up. But this makes the debugging/testing situation not ideal.

Take a look at this simple code: import Cocoa import SwiftUI struct DemoView: View { var body: some View { Text("Click me!") .onTapGesture { print("Clicked") } } } class FlippedView: NSView { override var isFlipped: Bool { return true } } class ViewController: NSViewController { override func viewDidLoad() { super.viewDidLoad() let stackView = NSStackView() stackView.orientation = .vertical stackView.alignment = .leading stackView.spacing = 0 stackView.translatesAutoresizingMaskIntoConstraints = false let hostView = NSHostingView(rootView: DemoView()) stackView.addArrangedSubview(hostView) let scrollView = NSScrollView() scrollView.translatesAutoresizingMaskIntoConstraints = false let flippedView = FlippedView() flippedView.addSubview(stackView) scrollView.documentView = flippedView view.addSubview(scrollView) NSLayoutConstraint.activate([ scrollView.topAnchor.constraint(equalTo: view.topAnchor), scrollView.leadingAnchor.constraint(equalTo: view.leadingAnchor), scrollView.trailingAnchor.constraint(equalTo: view.trailingAnchor), scrollView.bottomAnchor.constraint(equalTo: view.bottomAnchor), ]) } } I need my scroll view to start at the very top, so i put it inside a flipped document view. But now .onTapGesture does not fire.

Is is possible to use the camera in ASWebAuthenticationSession? We want to support signing in with a QR Code in our custom OAuth flow but the browser can't seem to access the camera.

iPhone16ProMax 通过[UIScreen mainScreen].bounds.size获取屏幕宽高 使用XCode15获取屏幕宽高为430 * 930 使用XCode16获取屏幕宽高为440 * 956 这是为什么？

Hello, In a new app I am working on I noticed the FamilyActivityTitleView that displays "ApplicationToken" has wrong (black) color when phone is set to light mode but app is using dark mode via override. We display user's selected apps and the labels are rendered correctly at first, but then when user updates selection with FamilyActivityPicker, then those newly added apps are rendered with black titles. The problem goes away when I close the screen and open it again. It also doesn't happen when phone is set to dark theme. I am currently noticing the issue on iOS 18.4.1. I have tried various workarounds like forcing white text in the custom label style, forcing re-render with custom .id value but nothing helped. Is there any way how to fix this?

I'm unable to get live activity to show up in my app so I started to play with the demo app Emoji Rangers. The demo project initially only created a live activity in-app and then you're able to update it via the demo buttons. I added the following code to have it be able to start a live activity from the backend: func observePushToStartToken() { Task { for await data in Activity.pushToStartTokenUpdates { let token = data.map {String(format: "%02x", $0)}.joined() // Send token to the server print("got PUSHTOSTART TOKEN: (token)") } } } I get the token and then I use it to send this payload that should start the activity: { "aps":{ "timestamp":1743719911, "event":"start", "content-state":{ "currentHealthLevel":100, "eventDescription":"Adventure has begun!", "supercharged":true }, "input-push-token":1, "attributes-type":"AdventureAttributes", "attributes":{ "currentHealthLevel":100, "eventDescription":"Adventure has begun!", "supercharged":true }, "alert":{ "title":{ "loc-key":"%@ is on an adventure!", "loc-args":[ "Power Panda" ] }, "body":{ "loc-key":"%@ found a sword!", "loc-args":[ "Power Panda" ] }, "sound":"chime.aiff" } } } But unfortunately I get an error when I send it: [AdventureAttributes] Error creating activity: NSCocoaErrorDomain (4865) The data couldn't be read because it is missing. First step is to get this working, so I want to get your help in figuring out what I'm missing.

We are experiencing an issue with session sharing on iOS and would appreciate your guidance. We operate and control our own OpenID Connect (OIDC) server. Our iOS application uses ASWebAuthenticationSession to authenticate users. We're unable to get the authentication session to be shared between the Safari app and the app's ASWebAuthenticationSession. This results in users having to re-authenticate despite being logged in via Safari. We've attempted various configurations related to cookie SameSite settings. These adjustments resolved the session sharing issue on Android using Chrome Custom Tabs. However, no changes we've tried have enabled session sharing to work as expected on iOS. According to documentation from Apple, Microsoft, Okta, and Auth0, session sharing between Safari and ASWebAuthenticationSession should work. Question: Are there any additional settings, configurations, or platform limitations we should be aware of that could impact session sharing on iOS? Where else can we look to resolve this issue?

I’m building a macOS app using SwiftUI with a WindowGroup(id: "rootWindow") for the main UI. The app shows a countdown timer, and the timer continues to run even after the user closes the main window (clicks the red "X"). When the timer reaches 0, I want to automatically reopen that window and bring the app to the front. I’m currently using the following code to bring the app to the foreground and show the window when the app is still open (but not focused/resign active state): NSApp.activate(ignoringOtherApps: true) NSApp.windows.forEach { window in if window.identifier?.rawValue.starts(with: "rootWindow") { window.makeKeyAndOrderFront(nil) } } However, this doesn’t work when the window has been closed. At that point, NSApp.windows no longer contains my SwiftUI window, and I have no reference to recreate or reopen it. I also cannot use openWindow environment value as it requires a view. How can I programmatically reopen a SwiftUI WindowGroup window after it’s been closed, without requiring any user interaction (like clicking the Dock icon)?

When the perform method of my AppIntent returns the custom view's dialog, and after I click the "Click Test" button, my app will be launched, but this dialog does not close. How can I close it? struct QuestionResultView: View { var body: some View { VStack { if #available(iOS 17.0, *) { Button(role:.cancel, intent: OpenAppIntent()) { Text("Click Test") } } }.frame(height: 300) } } struct OpenAppIntent : AppIntent { static let title: LocalizedStringResource = "Open my app" static let openAppWhenRun: Bool = true static let isDiscoverable: Bool = false; @MainActor func perform() async throws -> some IntentResult { return .result() } } struct OpenPhotoRecognizing: AppIntent { static let title: LocalizedStringResource = "Read photo" static let description = IntentDescription("") static let openAppWhenRun: Bool = false func perform() async throws -> some IntentResult & ShowsSnippetView & ProvidesDialog{ return .result(dialog: "Demo Test") { DemoResultView() } } }

There's an easily reproducible SwiftUI bug on macOS where an app's UI state no longer updates/re-renders for "Designed for iPad" apps (i.e. ProcessInfo.processInfo.isiOSAppOnMac == true). The bug occurs in Xcode and also if the app is running independent of Xcode. The bug occurs when: the user Hides the app (i.e. it goes into the background) the user puts the Mac to sleep (e.g. Apple menu > Sleep) a total of ~60 seconds transpires (i.e. macOS puts the app into the "suspended state") when the app is brought back into the foreground the UI no longer updates properly The only way I have found to fix this is to manually open a new actual full app window via File > New, in which case the app works fine again in the new window. The following extremely simple code in a default Xcode project illustrates the issue: import SwiftUI @main struct staleApp: App { @State private var isBright = true var body: some Scene { WindowGroup() { ZStack { (isBright ? Color.white : Color.black).ignoresSafeArea() Button("TOGGLE") { isBright.toggle(); print("TAPPED") } } .onAppear { print("\(isBright ? "light" : "dark") view appeared") } } } } For the code above, after Hiding the app and putting the computer to sleep for 60 seconds or more, the button no longer swaps views, although the print statements still appear in the console upon tapping the button. Also, while in this buggy state, i can get the view to update to the current state (i.e. the view triggered by the last tap) by manually dragging the corner of the app window to resize the window. But after resizing, the view again does not update upon button tapping until I resize the window again. so it appears the diff engine is mucked or that the Scene or WindowGroup are no longer correctly running on the main thread I have tried rebuilding the entire view hierarchy by updating .id() on views but this approach does NOT work. I have tried many other options/hacks but have not been able to reset the 'view engine' other than opening a new window manually or by using: @Environment(.openWindow) private var openWindow openWindow could be a viable solution except there's no way to programmatically close the old window for isiOSAppOnMac (@Environment(.dismissWindow) private var dismissWindow doesn't work for iOS)

The app I'm converting includes two unique document types. UI-wise they have key similarities (eg contents are password protected) But serialization/model - wise. they are different documents. I have not been able to find any documentation on options for implementing this (eg use a (abstract?) base class derived from FileDocument, with two concrete sub classes? maybe just a single subclass of FileDocument that contains model details for both file types?) Stepping back from implementation options, am I crazy for attempting to use DocumentGroup to create a single app that would need to be able to open/modify/save multiple unique document types? any/all guidance much appreciated.