Anyone else seeing this? I reported the regression back in March 2025 and have no reply from Apple. My apps are Obj-C, in case it matters. DESCRIPTION After updating to iOS 18.3.x, | noticed a regression in the title menu behavior of my UlDocumentViewController-based shipping apps on the App Store [1]: Instead of displaying the document icon supplied by the app, the share menu item displays a placeholder icon instead, and iconservicesagent error messages are emitted in the log stream [2]. STEPS TO REPRODUCE Install one of the apps from note [1] below. Launch the app, tap the document/title menu at top center of the screen, and observe first menu item. RESULTS Expected: App-provided document icon displayed to left of first menu item ("W-1" or "W68" document icon). Actual: Placeholder icon displayed. REGRESSION Occurs: iOS 18.3 (iPad) iOS 18.3.1 (iPhone) iOS 18.3.2 (iPhone) Does Not Occur: iOS 18.2,18.3 Simulator iOS 18.0-18.2? [| no longer have a device with < 18.3 to confirm regression point] NOTES: [1] WOZNIAC-1 <https://apps.apple.com/us/ app/wozniac-1/id6474085354> and WOZNIAC-68 <https://apps.apple.com/us/app/ wozniac-68/id6736677781>. [2] When the problem occurs, the following log messages are omitted: Error returned from iconservicesagent image request: <|STagIcon: 0x30299c040> Tag: alvm, Class: public.filename-extension, Base type: public.item - <|SImageDescriptor: Ox300dd5860> - (37.00, 48.00)@3x v:40000 1:5 a: 0:0:0:0 t:() b:0 s:2 ps:0 digest: 0D3223D0-9AЕ3-3B19-A081-ACACE55691B7 error: Error Domain=NSOSStatusErrorDomain Code=-609 "Client is disallowed from making such an icon request" UserInfo={NSLocalizedDescription=Client is disallowed from making such an icon request}

Hi folks, there's currently a known issue in TipKit due to which it won't show popover tips on buttons that are inside a SwiftUI ToolbarItem. For example, if you try this code, the popover tip will not appear: ToolbarItem { Button(action: {...}) { Label("Tap here", systemImage: "gear") } .popoverTip(sampleTip) } There's an easy workaround for this issue. Just apply a style to the button. It can be any style. Some examples are bordered, borderless, plain and borderedProminent. Here's a fixed version of the above code: ToolbarItem { Button(action: {...}) { Label("Tap here", systemImage: "gear") } .buttonStyle(.plain) // Adding this line fixes the issue. .popoverTip(sampleTip) } Hope this helps anyone running into this issue.

Hi everyone, I'm experiencing a weird visual glitch with PickerStyle(.segmented) placed inside a ToolbarItem(placement: .principal). When navigating between views or switching segments, the text doubles/overlaps temporarily during the transition animation (as shown in the screen recording).

Hi everyone, I'm experiencing a weird visual glitch with PickerStyle(.segmented) placed inside a ToolbarItem(placement: .principal). When navigating between views or switching segments, the text doubles/overlaps temporarily during the transition animation (as shown in the screen recording).

Filed as FB23362414, with a minimal sample: https://github.com/mesqueeb/Swiftui-Gesture-Detection-Failures While a SwiftUI DragGesture is held (trackpad click-drag), a two-finger magnify (trackpad pinch) permanently cancels it: onChanged stops firing the instant the magnify is recognized. onEnded is never delivered — the gesture is torn down with no terminal event. Continued motion of the same, still-pressed finger after the pinch is not re-detected. The drag only recovers after a full release and re-press. Throughout, the AppKit NSEvent stream keeps delivering .leftMouseDragged (and a clean .leftMouseUp on release), so the OS is still tracking the drag — it's SwiftUI's gesture arbitration that discards it. No gesture composition avoids this: .simultaneousGesture, .highPriorityGesture, varying gesture order, and .exclusively(before:) in both directions were all tried; none delivers a terminal onEnded or resumes the drag after the pinch. Steps to reproduce (full sample in the repo — ./build.sh run): Press-hold and drag a shape with the trackpad (do not release). Without lifting the drag finger, perform a two-finger pinch. End the pinch and keep moving the same finger. Expected: onChanged continues for the still-pressed finger; onEnded fires when it's lifted. Actual: onChanged stops at the pinch and never resumes; onEnded never fires. Workaround: driving the gestures off AppKit NSEvent instead of SwiftUI works correctly — the sample has a toggle to switch between the two so you can compare side by side. Tested on macOS 26.3.1 (25D771280a) and macOS 27.0 Beta (26A5353q), Apple Silicon, built-in trackpad. Has anyone else run into this, or found a SwiftUI gesture composition that survives the pinch?

I'm really struggling to get a handle on all the different aspects of Control Widgets. I wish the docs led with comprehensive visual examples. I'm trying to make a Control Widget that shows the user a quick status of something (on or off), and lets the user change that status, but when they turn it off, it can be turned off for a period of time. I want to present some options in a manner similar to the Focus widget. When you first display widets on macOS, you get this: On the Focus widget, see how it has a round button with a moon, the word "Focus", and a disclosure chevron? I want to reproduce that. If you click the moon button, it turns that focus mode on. If you click anywhere else, it shows this: And even those controls are quite fancy, expanding when you click on them. How do I get that second level of UI?

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 not sure if this is a ”care later in the summer” situation, but on beta 1, with an .adaptive Grid Item, a scrolling LazyVGrid will hop and “bounce” when scrolling back up from the bottom of the grid. I can see the scrollbar visibly hopping as item views are re-created. Anyone else seeing this?

I've got a Mac Document App using SwiftUI and SwiftData. All is working well with the models editing, etc. There's a feature I need to implement, and can't seem to make it work. From the main window of the app, I need to be able to launch an auxilliary window containing a view-only representation of the model being edited. The required workflow is something like this: Open a document (SwiftData) Select a sub-model of the document Launch the aux window to display the view of the model data (must be in a separate window, because it will be on a different physical display) Continue making edits to the sub-model, as they are reflected in the other window So, below is the closest I've been able to come, and it's still not working at all. What happens with this code: Click on the "Present" button, the encounter-presentation Window opens, but never loads the data model or the view. It's just an empty window. This is the spot in the main view where the auxiliary window will be launched: @State var presenting: Presentation? = nil var presentingThisEncounter: Bool { presenting?.encounter.id == encounter.id } @Environment(\.openWindow) var openWindow ... if presentingThisEncounter { Button(action: { presenting = nil }) { Label("Stop", systemImage: "stop.fill") .padding(.horizontal, 4) } .preference(key: PresentationPreferenceKey.self, value: presenting) } else { Button(action: { presenting = Presentation(encounter: encounter, display: activeDisplay) openWindow(id: "encounter-presentation") }) { Label("Present", systemImage: "play.fill") .padding(.horizontal, 4) } .preference(key: PresentationPreferenceKey.self, value: nil) } Presentation is declared as: class Presentation: Observable, Equatable { Here's the contents of the App, where the DocumentGroup & model is instantiated, and the aux window is managed: @State var presentation: Presentation? var body: some Scene { DocumentGroup(editing: .encounterList, migrationPlan: EncounterListMigrationPlan.self) { ContentView() .onPreferenceChange(PresentationPreferenceKey.self) { self.presentation = $0 } } Window("Presentation", id: "encounter-presentation") { VStack { if let presentation = presentation { PresentingView(presentation: presentation) } } } } And the definition of PresentationPreferenceKey: struct PresentationPreferenceKey: PreferenceKey { static var defaultValue: Presentation? static func reduce(value: inout Presentation?, nextValue: () -> Presentation?) { value = nextValue() } }

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.

I've been hitting a weird SwiftUI bug with navigation and state loss and I've managed to reproduce in a very tiny sample project. I've submitted a Feedback FB21681608 but thought it was worth posting here incase any SwiftUI experts can see something obviously wrong. The bug With deeper levels of navigation hierarchy SwiftUI will dismiss views when backgrounding the app. Any work around would be appreciated. This happens in a real app where we have to navigate to a settings screen modally and then a complex flow with other sheets. Sample code Happens in the simulator and on device. import SwiftUI struct ContentView: View { @State private var isPresented = false var body: some View { Button("Show first sheet") { isPresented = true } .sheet(isPresented: $isPresented) { SheetView(count: 1) } } } struct SheetView: View { private enum Path: Hashable { case somePath } @State private var isPresented = false var count: Int var body: some View { NavigationStack { VStack { Text("Sheet \(count)") .font(.largeTitle) // To recreate bug show more than 4 sheets and then switch to the app switcher (CTRL-CMD-Shift-H). // All sheets after number 3 dismiss. Button("Show sheet: \(count + 1)") { isPresented = true } } .sheet(isPresented: $isPresented) { SheetView(count: count + 1) } // Comment out the `navigationDestination` below and the sheets don't dismiss when app goes to the background. // Or move this modifier above the .sheet modifier and the sheets don't dismiss. .navigationDestination(for: Path.self) { _ in fatalError() } } } }

With iOS 27's automatic resizability for iPhone apps on iPad and in iPhone Mirroring, what's the recommended pattern for views that need genuinely different layouts at different size classes — is ViewThatFits the intended tool, or should we still branch on size class for larger structural changes? — Divya Ravi, Senior iOS Engineer

Any view that is content for the tabViewBottomAccessory API fails to retain its state as of the last couple of 26.1 betas (and RC). The loss of state happens (at least) when the currently selected tab is switched (filed as FB20901325). Here's code to reproduce the issue: struct ContentView: View { @State private var selectedTab = TabSelection.one enum TabSelection: Hashable { case one, two } var body: some View { TabView(selection: $selectedTab) { Tab("One", systemImage: "1.circle", value: .one) { BugExplanationView() } Tab("Two", systemImage: "2.circle", value: .two) { BugExplanationView() } } .tabViewBottomAccessory { AccessoryView() } } } struct AccessoryView: View { @State private var counter = 0 // This guy's state gets lost (as of iOS 26.1) var body: some View { Stepper("Counter: \(counter)", value: $counter) .padding(.horizontal) } } struct BugExplanationView: View { var body: some View { ScrollView { VStack(alignment: .leading, spacing: 16) { Text("(1) Manipulate the counter state") Text("(2) Then switch tabs") Text("BUG: The counter state gets unexpectedly reset!") } .multilineTextAlignment(.leading) } } }

Does anybody know if I'm missing something here? I'm using .mapStyle(.elevation(.realistic)), which enables the 3D map view, but it causes significant lag when driving in real life, especially at speeds above 50 mph. Everything works perfectly in the Simulator with no issues, but real world performance is much worse. The phone starts heating up almost immediately when driving in this mode through urban areas with 3D map data. Interestingly, the phone does not heat up on motorways, and performance is excellent there. (I guess because there's not so much 3D data to show on motorways) This mode looks fantastic and is one of the most requested features from my users, so I'm trying to figure out how to make it work properly. I've tested both SwiftUI and UIKit implementations and get the same result in both. Also I'm using an iPhone 17 Pro Max and an iPad 11, same result on both, including CarPlay import MapKit import CoreLocation struct ContentView: View { @State private var locationManager = LocationManagerDelegate() @State private var cameraPosition: MapCameraPosition = .userLocation(followsHeading: false, fallback: .automatic) @State private var isTracking: Bool = false var body: some View { Map(position: $cameraPosition) { UserAnnotation() } .mapStyle(.imagery(elevation: .realistic)) .onChange(of: locationManager.location) { _, location in guard isTracking, let location else { return } withAnimation(.linear(duration: 0.5)) { cameraPosition = .camera(MapCamera( centerCoordinate: location.coordinate, distance: 1000, heading: location.course, pitch: 60 )) } } .safeAreaInset(edge: .bottom) { // Added to the safeAreaInset to keep the Apple Logo visible Button("Track") { isTracking.toggle() locationManager.requestPermission() locationManager.startNavigating() } .buttonStyle(.glassProminent) .buttonSizing(.flexible) .controlSize(.extraLarge) .padding(.horizontal) } } } @MainActor @Observable final class LocationManagerDelegate: NSObject, CLLocationManagerDelegate { var location: CLLocation? var authorizationStatus: CLAuthorizationStatus = .notDetermined let manager = CLLocationManager() private var liveUpdateTask: Task<Void, Never>? override init() { super.init() manager.delegate = self manager.desiredAccuracy = kCLLocationAccuracyBestForNavigation manager.allowsBackgroundLocationUpdates = true authorizationStatus = manager.authorizationStatus } func requestPermission() { manager.requestWhenInUseAuthorization() } func startNavigating() { liveUpdateTask = Task { do { for try await update in CLLocationUpdate.liveUpdates(.automotiveNavigation) { guard let newLocation = update.location else { continue } self.location = newLocation } } catch { print("Live updates error: \(error)") } } } func stopNavigating() { liveUpdateTask?.cancel() liveUpdateTask = nil manager.requestLocation() } func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) { location = locations.last } func locationManagerDidChangeAuthorization(_ manager: CLLocationManager) { authorizationStatus = manager.authorizationStatus } } #Preview { ContentView() }

I have an NSTableView used as a source list and, alongside it, two editors. When the user selects anything in the table view, its content is opened in the editor that has the focus. When the user Opt-clicks an item in the table, though, the content is opened in the other editor, making it easy for the user to load something in the other editor without having to change the focus first. This has worked for many years using NSTableView.selectiondDidChange / the NSTableViewDelegate as follows: func tableViewSelectionDidChange(_ notification: Notification) { if let event = tableView.window?.currentEvent, event.type == .leftMouseUp || event.type == .leftMouseDown, // (Real app does some other checks here too.) event.modifierFlags.contains(.option) { openInOtherEditor() return } openInCurrentEditor() } However, on macOS 27, it seems that things need to be done differently because of the transition to gesture recognisers for event handling. According to the WWDC video "Modernise Your AppKit App", and to Tech Note TN3212, currentEvent can no longer be relied upon to provide the event that actually triggered an action in NSControl subclasses: The transition to gesture recognizers on NSControl objects changes the timing of when AppKit delivers control action messages with respect to event processing. As a result, currentEvent no longer returns the event that triggered an action. It's unclear whether this new limitation refers only to NSControl.action or to all mouse-driven actions, but from the context and what the rest of the Tech Note has to say, I assume it's the latter. (Especially since you are no longer supposed to override mouseDown(with:), and the Console warns about gestures being disabled if you do override mouseDown(with:) in an NSTableView subclass on macOS 27.) currentEvent still seems to work fine in this situation in the first macOS 27 beta, but it sounds as though we cannot rely on this continuing to be the case. If we should no longer be using currentEvent, then, what should we use instead to determine whether a selection change was triggered by a mouse click? The Tech Note and WWDC video have nothing to say about this. They simply say that instead of overriding mouseDown(with:), you should use the selection-did-change delegate methods, which is of no help here. (By contrast, checking the modifier flags is still straightforward; the Tech Note says to use NSEvent.modifierFlags instead of currentEvent.modifierFlags.) Two solutions sprung to mind, but neither worked: Check tableView.clickedRow != -1 in the selectionDidChange delegate method/notification response. This doesn't work, however, because clickedRow has been reset to -1 by the time NSTableView.selectionDidChange is sent. Add an action to the table view and check clickedRow there. This doesn't work either, though, because although clickedRow is available in the action method, I would now have to load content in response to both an action and a selection change, and since the selection changes before the action is called, there is no way of telling my selection-did-change method not to load in the main editor if Option is held down in the action. The only solution I have found is to override selectRowIndexes(_:byExtendingSelection:), check for clickedRow != -1 there, set a didChangeSelectionWithMouse flag to true if so, and check that in the selection-did-change delegate method. That works, but it's not the most elegant of solutions. So: Am I misunderstanding the Tech Note? Can currentEvent still in fact be used safely in tableViewSelectionDidChange(_:) in macOS 27 and beyond? If not, what is the recommended way of checking that the table selection has been changed by a mouse click? Many thanks!

I'm building an app with Xcode 27. I had trouble getting the tab bar to detach the search button onto the trailing side. I found that the search behaviour now works through the new .prominent treatment on iOS 27 (with Tab(role: .search)), and the detached button now displays correctly. My remaining problem is the activation behaviour. Expected (as in the system Phone / News / App Store apps): tapping the search button morphs the tab bar — the other tabs collapse into a single leading button and the search field expands at the bottom, centered. Actual: tapping the search tab pushes the search field to the top of the screen, attached to the navigation bar, with no morph animation and no tab collapse. Setup: Xcode 27.0 beta, iOS 27.0 on a physical iPhone Air Same with the Simulator (by the way... i also have some terrible lag with my app on Simulator + my iPhone even with a release version, but not throught TestFlight... strange...) 3 standard tabs + 1 search tab Single .searchable(text:) applied directly on the TabView (not on the inner NavigationStack) No .introspect or third-party modifiers on the search NavigationStack Is the morph + tab-collapse behaviour automatic for the search tab on iPhone, or does it require an additional modifier/configuration I'm missing? Can anyone confirm whether this morph works on a stable iOS 26 build with equivalent code? I suspect a regression in the 27.0 beta SDK, since the detached button works but the activation morph does not. I'm not yet an expert... so maybe i'm doing something wrong. I'll file Feedback if this is confirmed as a beta bug. Thanks.

I have an existing app that uses NavigationSplitView with a detail view that is never changed and just updates to show changes in data. All navigation changes the sidebar only using NavigationLinks with .isDetailLink(false). Now I'm wanting to use NavigationPath with a simple router and enums. import SwiftUI @main struct NavRouterApp: App { @State private var router = Router() var body: some Scene { WindowGroup { NavigationStack(path: $router.navPath) { ContentView() .navigationDestination(for: AppRoute.self) { route in switch route { case .citizens: ContentView() .environment(router) case .citizen: EmptyView() .environment(router) case .tasform2: TASForm2View() .environment(router) case .start: StartView() .environment(router) case .editcharacteristics: EmptyView() .environment(router) case .basicdata(let citizen): BasicDataView(citizen: citizen) .environment(router) .navigationBarBackButtonHidden(true) case .characteristics: EmptyView() .environment(router) } } } .environment(router) } } } The problem is that pushing a subview now replaces the entire content instead of just the sidebar. Pushing a subview with NavigationSplitView would update the sidebar as desired but I would have to replace the detail view, which is not a good idea. I haven't been able to find any way to accomplish what I want. Suggestions?

We're using IKPictureTaker to let users pick a room avatar image. The flow worked correctly on macOS 13–15, but breaks on macOS 26 (Tahoe). Symptoms popUpRecentsMenu(for:withDelegate:didEnd:contextInfo:) — no UI appears at all, and the didEnd selector is never called runModal() — a window appears but its content is completely blank (empty gray rectangle). The app freezes until the user force-quits Minimal reproduction import Quartz let pictureTaker = IKPictureTaker.pictureTaker() pictureTaker?.setCommonValuesForKeys(allowsVideoCapture: true) // Attempt 1 — silent fail, no UI, no callback pictureTaker?.popUpRecentsMenu(for: someButton, withDelegate: self, didEnd: #selector(pictureTakerDidEnd), contextInfo: nil) // Attempt 2 — window appears but content is blank let result = pictureTaker?.runModal() // result is never returned while window is visible; app is frozen Environment macOS 26.0 (Tahoe) — reproducible by QA on multiple machines Xcode 16, Swift 5, deployment target macOS 10.14 Camera permission granted (AVAuthorizationStatus.authorized) App is sandboxed What I've ruled out Camera permission is authorized before the call The view passed to popUpRecentsMenu has a valid, visible, key window Same code works on macOS 13, 14, 15 Question Is this a known regression in macOS 26? Is IKPictureTaker expected to stop working, or is there a required entitlement / initialization step that changed? If the API is effectively unsupported, is NSOpenPanel with allowedContentTypes: [.image] the recommended migration path?

I have an NSTextView subclass that overrides mouseDown: to allow for image resizing. If a user clicks and drags on the edges of an image, I implement custom behaviour that resizes the image (and shows resizing cursors). If the user clicks anywhere else, super's implementation is called. This all works great. As of macOS 27, however, the transition to gesture recognisers instead of overriding mouseDown: means that I should probably be moving away from the above approach. NSTextView now uses the new NSTextSelectionManager to implement selection and dragging via gesture recognisers, although, according to the release notes: Existing NSTextView subclasses that override mouseDown: continue to work through a binary-compatible fallback path. (163365571) It's unclear whether this means that we therefore should still override mouseDown: for custom behaviour in NSTextView, but to me, this, along with the content of Tech Note TN3212, strongly implies that, although it will continue to work thanks to "a binary-compatible fallback", we should entirely move away from overriding mouseDown: in the future. If that is indeed the case, how do we implement custom dragging behaviour--such as for resizing images as in my example--in NSTextView? There still seems to be no way of doing it other than overriding mouseDown:. I had thought that I might be able to add an NSPanGestureRecognizer to the text view and have it fail via its delegate methods if the clicks were outside of an image's edges, but a pan gesture recogniser added to an NSTextView is entirely ignored, presumably because of the private gestures already added. Fortunately everything continues to work for now, but I would like to update my code as much as possible.