We have encountered a problem on iOS 26. When switching to dark mode, the color of all subviews (font color, background color, etc.) of the Sidebar (Primary View) of UISplitViewController will not change. For example, if it is set to the color of UIColor.label, it will always be black and will not be white in dark mode. On Xcode, just create a UISplitViewController in Storyboard without changing any settings, and run it directly to see the following: The title of the Navigation Bar defaults to the label color, and it is still black after switching to dark mode. There is no such problem in the Secondary View or other places. This problem has occurred since iOS 26 beta 3, and iOS 26 beta 4 is now the same. But beta 1 and beta 2 have no problem. I'm not sure if this is a bug, or if there is something that needs to be changed to adapt to iOS 26?

We're seeing a sharp uptick in BaseBoard/FrontBoardServices crashes since we migrated from UIApplicationDelegate to UIWindowSceneDelegate. Having exhausted everything on my end short of reverse engineering BaseBoard or making changes without being able to know if they work, I need help. I think all I need to get unstuck is an answer to these questions, if possible: What does -[BSSettings initWithSettings:] enumerate over? If I know what's being enumerated, I'll know what to look for in our app. What triggers FrontBoardServices to do this update? If I can reproduce the crash--or at least better understand when it may happen--I will be better able to fix it Here's two similar stack traces: App_(iOS)-crashreport-07-30-2025_1040-0600-redacted.crash App_(iOS)-crashreport-07-30-2025_1045-0600-redacted.crash Since these are private trameworks, there is no documentation or information on their behavior that I can find. There are other forum posts regarding this crash, on here and on other sites. However, I did not find any that shed any insight on the cause or conditions of the crash. Additionally, this is on iPhone, not macOS, and not iPad. This post is different, because I'm asking specific questions that can be answered by someone with familiarity on how these internal frameworks work. I'm not asking for help debugging my application, though I'd gladly take any suggestions/tips! Here's the long version, in case anyone finds it useful: In our application, we have seen a sharp rise in crashes in BaseBoard and FrontBoardServices, which are internal iOS frameworks, since we migrated our app to use UIWindowSceneDelegate. We were using exclusively UIApplicationDelegate before. The stack traces haven't proven very useful yet, because we haven't been able to reproduce the crashes ourselves. Upon searching online, we have learned that Baseboard/Frontsoardservices are probably copying scene settings upon something in the scene changing. Based on our crash reports, we know that most of our users are on an iPhone, not an iPad or macOS, so we can rule out split screen or window resizing. Our app is locked to portrait as well, so we can also rule out orientation changes. And considering the stack trace is in the middle of an objc_retain_x2 call, which is itself inside of a collection enumeration, we are assuming that whatever is being enumerated probably was changed or deallocated during enumeration. Sometimes it's objc_retain_x2, and sometimes it's a release call. And sometimes it's a completely different stack trace, but still within BaseBoard/FrontBoardServices. I suspect these all share the same cause. Because it's thread 0 that crashed, we know that BaseBoard/FrontBoardServices were running on the main thread, which means that for this crash to occur, something might be changing on a background thread. This is what leads me to suspect a race condition. There are many places in our app where we accidentally update the UI from a background thread. We've fixed many of them, but I'm sure there are more. Our app is large. Because of this, I think background UI are the most likely cause. However, since I can't reproduce the crash, and because none of our stack traces clearly show UI updates happening on another thread at the same time, I am not certain. And here's the stack trace inline, in case the attachments expire or search engines can't read them: Thread 0 name: Thread 0 Crashed: objc_retain_x2 (libobjc.A.dylib) BSIntegerMapEnumerateWithBlock (BaseBoard) -[BSSettings initWithSettings:] (BaseBoard) -[BSKeyedSettings initWithSettings:] (BaseBoard) -[FBSSettings _settings:] (FrontBoardServices) -[FBSSettings _settings] (FrontBoardServices) -[FBSSettingsDiff applyToMutableSettings:] (FrontBoardServices) -[FBSSettingsDiff settingsByApplyingToMutableCopyOfSettings:] (FrontBoardServices) -[FBSSceneSettingsDiff settingsByApplyingToMutableCopyOfSettings:] (FrontBoardServices) -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 (FrontBoardServices) -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke.cold.1 (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke (FrontBoardServices) _dispatch_client_callout (libdispatch.dylib) _dispatch_block_invoke_direct (libdispatch.dylib) __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ (FrontBoardServices) -[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] (FrontBoardServices) -[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] (FrontBoardServices) __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (CoreFoundation) __CFRunLoopDoSource0 (CoreFoundation) __CFRunLoopDoSources0 (CoreFoundation) __CFRunLoopRun (CoreFoundation) CFRunLoopRunSpecific (CoreFoundation) GSEventRunModal (GraphicsServices) -[UIApplication _run] (UIKitCore) UIApplicationMain (UIKitCore) (null) (UIKitCore) main (AppDelegate.swift:0) 0x1ab8cbf08 + 0

I'm running into a persistent problem with the iOS 18.5 simulator in Xcode 26 beta 2. I have built a very simple test app with a storyboard that includes only a toolbar added to the ViewController scene in the storyboard. The test app runs fine in iOS 26 simulators.When I try to run it in the iOS 18.5 simulator for iPhone Pro or iPad (16), it fails while unarchiving the storyboard (as far as I can tell) with this error message in the Xcode console: *** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView because no class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target)' terminating due to uncaught exception of type NSException CoreSimulator 1043 - Device: iPad (A16) (3E70E25F-8434-4541-960D-1B58EB4037F3) - Runtime: iOS 18.5 (22F77) - DeviceType: iPad (A16) I'd love a simple workaround for this.

It looks like we're encountering a similar hitTest issue to what we had with iOS Xcode 16 + iOS 18. When running Xcode 26 + iOS 26, rootViewController?.view.subviews is returning an empty array, even though the views are clearly present in the hierarchy. Last year, we "fixed" this issue using the code attached, but it doesn't seem to work anymore with iOS 26. Any suggestions would be greatly appreciated! private class PassthroughWindow: UIWindow { override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? { guard let hitView = super.hitTest(point, with: event), let rootView = rootViewController?.view else { return nil } if #available(iOS 18, *) { for subview in rootView.subviews.reversed() { let convertedPoint = subview.convert(point, from: rootView) if subview.hitTest(convertedPoint, with: event) != nil { return hitView } } return nil } else { return hitView == rootView ? nil : hitView } } }

Hi everyone, I've come across an issue on iOS that seems to affect many apps. Here's what happens: A user logs in with correct credentials and proceeds to the OTP verification screen as part of multi factor authentication. iOS presents the system password save prompt ("Would you like to save this password?"). Without selecting an option on this prompt, the user backgrounds the app (e.g., to check their email for the OTP). Upon returning to the app, the keyboard becomes completely inaccessible on the OTP screen or any other screen. From my testing, this behavior appears to be an OS-level bug, as it occurs consistently across various apps. Has anyone else encountered this? Any known workarounds or updates from Apple on this behavior would be greatly appreciated! Thanks!

I noticed that trying to access safeAreaInsets from the active window causes an infinite run loop. This issue appeared after updating to Beta 3. Here’s an example of the code: extension UIDevice { var safeAreaInsets: UIEdgeInsets { guard let windowScene = UIApplication.shared.connectedScenes.first as? UIWindowScene, let window = windowScene.windows.first(where: { $0.isKeyWindow }) else { return .zero } return window.safeAreaInsets } } The return doesn’t happen because it ends up in some kind of recursion.

In iOS26, when using a standalone UITabBar without UITabBarController, the liquid glass blur effect is not applied when scrollable content moves behind the tab bar. However, the blur effect appears correctly when using UITabBarController. Sample Screenshots: When using UITababr When using UITababrController Sample Code: class SimpleTabBarController: UIViewController, UITabBarDelegate { let tabBar = UITabBar() let redItem = UITabBarItem(title: "Red", image: .add, tag: 0) let blueItem = UITabBarItem(title: "Blue", image: .checkmark, tag: 1) override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .white tabBar.items = [redItem, blueItem] tabBar.selectedItem = redItem tabBar.delegate = self tabBar.translatesAutoresizingMaskIntoConstraints = false let tableContainerView = TableContainerView() view.addSubview(tableContainerView) tableContainerView.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ tableContainerView.topAnchor.constraint(equalTo: view.topAnchor), tableContainerView.leadingAnchor.constraint(equalTo: view.leadingAnchor), tableContainerView.trailingAnchor.constraint(equalTo: view.trailingAnchor), tableContainerView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) view.addSubview(tabBar) NSLayoutConstraint.activate([ tabBar.leadingAnchor.constraint(equalTo: view.leadingAnchor), tabBar.trailingAnchor.constraint(equalTo: view.trailingAnchor), tabBar.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) }

When you touch down on a button in a scroll view, you can cancel the tap by scrolling. In SwiftUI, this works correctly when the scroll view is not inside a dismissible sheet. However, if the scroll view is inside a sheet that can be dismissed with a drag gesture, scrolling does not cancel the button touch, and after scrolling, the button tap is activated. This happens whether the modal is presented from SwiftUI using the sheet modifier, or wrapped in a UIHostingController and presented from UIKit. This is a huge usability issue for modals with scrollable content that have buttons inside of them. Video of behavior: https://youtube.com/shorts/w6eqsmTrYiU Easily reproducible with this code: import SwiftUI struct ContentView: View { @State private var isPresentingSheet = false var body: some View { ScrollView { LazyVStack { ForEach(0..<100, id: \.self) { index in Button { isPresentingSheet = true } label: { Text("Button \(index)") .padding(.horizontal) .padding(.vertical, 5) .frame(maxWidth: .infinity, alignment: .leading) } } } .padding() } .sheet(isPresented: $isPresentingSheet) { ContentView() } } }

I made an account on this site for the sole reason to post this. I can not stand the IOS 18 photo app, to put it bluntly its sucks, it's made the app unusable. I was nice, I'd thought I'd give it a month or two but no, it still sucks. I wish I could uninstall IOS 18 solely cause of it. I hate the UI, its utterly unintuitive.

Overview I have an iOS project where I have a list with sections. Each cell in the section can be swiped to have some action What needs to be done When swipe button is pressed the cell needs to move from one section to the other without a UI glitch. Problem When I press the swipe action button, there is a UI glitch and some warnings are thrown. UICollectionView internal inconsistency: unexpected removal of the current swipe occurrence's mask view. Please file a bug against UICollectionView. Reusable view: <SwiftUI.ListCollectionViewCell: 0x10700c200; baseClass = UICollectionViewListCell; frame = (16 40.3333; 370 52); hidden = YES; layer = <CALayer: 0x600000c12fa0>>; Collection view: <SwiftUI.UpdateCoalescingCollectionView: 0x106820800; baseClass = UICollectionView; frame = (0 0; 402 874); clipsToBounds = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x600000c13330>; backgroundColor = <UIDynamicSystemColor: 0x60000173a9c0; name = systemGroupedBackgroundColor>; layer = <CALayer: 0x600000c3a070>; contentOffset: {0, -62}; contentSize: {402, 229}; adjustedContentInset: {62, 0, 34, 0}; layout: <UICollectionViewCompositionalLayout: 0x10590edb0>; dataSource: <_TtGC7SwiftUI31UICollectionViewListCoordinatorGVS_28CollectionViewListDataSourceOs5Never_GOS_19SelectionManagerBoxS2___: 0x106822a00>>; Swipe occurrence: <UISwipeOccurrence: 0x103c161f0; indexPath: <NSIndexPath: 0xab1f048608f3828b> {length = 2, path = 0 - 0}, state: .triggered, direction: left, offset: 0> Test environment: Xcode 26.0.1 (17A400) iOS 26 Simulator (iPhone 17 Pro) Feedback filed: FB20890361 Code I have pasted below the minimum reproducible code ContentView import SwiftUI struct ContentView: View { @State private var dataStore = DataStore() var body: some View { List { ToDoSection(status: .notStarted, toDos: notStartedToDos) ToDoSection(status: .inProgress, toDos: inProgressToDos) ToDoSection(status: .completed, toDos: completedTodos) } } var notStartedToDos: [Binding<ToDoItem>] { $dataStore.todos.filter { $0.wrappedValue.status == .notStarted } } var inProgressToDos: [Binding<ToDoItem>] { $dataStore.todos.filter { $0.wrappedValue.status == .inProgress } } var completedTodos: [Binding<ToDoItem>] { $dataStore.todos.filter { $0.wrappedValue.status == .completed } } } ToDoSection import SwiftUI struct ToDoSection: View { let status: ToDoItem.Status let toDos: [Binding<ToDoItem>] var body: some View { if !toDos.isEmpty { Section(status.title) { ForEach(toDos) { toDo in Text(toDo.wrappedValue.title) .swipeActions(edge: .trailing) { if status == .notStarted { Button("Start") { toDo.wrappedValue.status = .inProgress } } if status != .completed { Button("Complete") { toDo.wrappedValue.status = .completed } Button("Move back") { toDo.wrappedValue.status = .notStarted } } } } } } } } ToDoItem import Foundation struct ToDoItem: Identifiable { let id: UUID let title: String var status: Status } extension ToDoItem { enum Status: Equatable { case notStarted case inProgress case completed var title: String { switch self { case .notStarted: "Not Started" case .inProgress: "In Progress" case .completed: "Completed" } } } } DataStore import Foundation @Observable class DataStore { var todos: [ToDoItem] init() { todos = [ ToDoItem(id: UUID(), title: "aaa", status: .notStarted), ToDoItem(id: UUID(), title: "bbb", status: .notStarted), ToDoItem(id: UUID(), title: "ccc", status: .notStarted) ] } }

I opened a feedback ticket (FB16508762) but maybe someone in the community already found a workaround while the feedback reaches the maintainers. When I put a Button inside a ScrollView, the tap animation stops working reliably and works only when the user taps and holds the button for a short time. The reasons, I believe is related to the fact that isPressed of configuration does not change and the default button styles use it to animate the tap. import SwiftUI struct DebuggingButtonStyle: ButtonStyle { func makeBody(configuration: Configuration) -> some View { configuration.label .onChange(of: configuration.isPressed, { oldValue, newValue in print("Is pressed: \(oldValue) -> \(newValue)") }) } } struct ContentView: View { var body: some View { VStack { Text("Buttons inside scroll view respond to taps as expected, however isPessed value of the configuration do not change unless the user press and hold it. Try to press the promiment button quickly or use the debug button and observe the console log.") ScrollView { VStack { Button("Button Inside ScrollView") { print("Button tapped") } .buttonStyle(.borderedProminent) Button("Button Inside ScrollView (printing isPressed)") { print("Button tapped") } .buttonStyle(DebuggingButtonStyle()) } } .border(FillShapeStyle(), width: 2) Spacer() Text("For reference, here is a button outside of a ScrollView. Tap the promiment button to observe how the button is expected to animate in respnse to a press.") VStack { Button("Button Outside ScrollView") { print("Button tapped") } .buttonStyle(.borderedProminent) Button("Button Outside ScrollView (printing isPressed)") { print("Button tapped") } .buttonStyle(DebuggingButtonStyle()) } } .padding() } }

I'm building an iPad app targeting iPadOS 26 using SwiftUI. Previously, I added a custom button by overlaying it in the top-left corner: content .overlay(alignment: .topLeading) { Button("Action") { // ... } This worked until iPadOS 26 introduced new window controls (minimize/close) in that corner, which now overlap my button. In the WWDC Session Video https://developer.apple.com/videos/play/wwdc2025/208/?time=298, they show adapting via .toolbar, but using .toolbar forces me to embed my view in a NavigationStack, which I don’t want. I really only want to add this single button, without converting the whole view structure. Constraints: No use of .toolbar (as it compels a NavigationStack). Keep existing layout—just one overlayed button. Support automatic adjustment for the new window controls across all window positions and split-screen configurations. What I’m looking for: A way to detect or read the system′s new window control safe area or layout region dynamically on iPadOS 26. Use that to offset my custom button—without adopting .toolbar. Preferably SwiftUI-only, no heavy view hierarchy changes. Is there a recommended API or SwiftUI technique to obtain the new control’s safe area (similar to a custom safeAreaInset for window controls) so I can reposition my overlayed button accordingly—without converting to NavigationStack or using .toolbar?

We have some rather old code that worked for many years, but recently started to crash sporadically here: The crash looks like this: or Our code is called from many threads concurrently, but as said it worked without any issues until recently. I've found the apparently same crash on iOS at this Reddit post: https://www.reddit.com/r/iOSProgramming/comments/1kle4h4/ios_185_doesnt_fix_cicontext_rendering_crash/ Recap: we believe it started on macOS 18.4 and is still on macOS 18.5. But maybe it was already on macOS 18.3. This matches the observation in the Reddit post well. Should we create a feedback with sysdiagnose? Thanks! :)

My app uses the SwiftUI Map control to display annotations. When annotations contain buttons AND the map has an .onTapGesture modifier, annotation button taps aren’t always recognized. Given the following ContentView, run it on an iOS device or simulator. Tap the buttons. Since iOS 18.0, some of the buttons won't respond to tap. I've also tried using the onTapGesture instead of a button, and that shows the same issue. This was not a problem under iOS 17.x: it has only shown up for my users since updating to iOS 18. Additionally, this issue does not occur when running on either macOS 15.0 or visionOS 2.0 when running in "designed for iPad" mode. Note that there was previously a tap issue on VisionOS 1.x (designed for iPad), where no tap gestures were received by annotations. I'm curious if this issue could be related. I have filed a report in Feedback Assistant (FB15273909). struct ContentView: View { private let center = CLLocationCoordinate2D(latitude: 37.77925, longitude: -122.41924) @State private var label: String = "tap a button" @State private var locations: [Location] = [] var body: some View { Map { ForEach(locations) { location in Annotation(location.name, coordinate: location.coordinate) { Button(location.name) { print("\(location.name) tapped") label = "\(location.name) tapped" } .buttonStyle(.borderedProminent) } .annotationTitles(.hidden) } } .onTapGesture { point in print("Map tapped") label = "map tapped" } .safeAreaInset(edge: .top) { Text(label) .padding() .background(.thinMaterial) .clipShape(.rect(cornerRadius: 10)) } .navigationTitle("Test Page") .navigationBarTitleDisplayMode(.inline) .task { for index in 1...16 { locations.append(Location(name: "location \(index)", coordinate: CLLocationCoordinate2D(latitude: center.latitude + Double.random(in: -0.02...0.02), longitude: center.longitude + Double.random(in: -0.02...0.02)))) } } } private struct Location: Identifiable { let id: UUID = UUID() let name: String let coordinate: CLLocationCoordinate2D } } #Preview { ContentView() }

Hi, I'm seeing an issue in iOS 26 beta related to UINavigationBar rendering in landscape. When a background color is set for the navigation bar and the device is rotated to landscape, an unexpected gap appears above the navigation bar. This also happens in the official sample project provided in Apple’s documentation: https://developer.apple.com/documentation/uikit/customizing-your-app-s-navigation-bar Is this a bug in the beta, or is there a workaround to avoid this behavior? Thanks in advance!

Using desaturated mode on an image in a widget will break any links or buttons that use the image as their 'label'. Using the following will just open the app as if there was no link at all - therefore just using the fallback userActivity handler, or any .widgetURL() urls provided. Link(destination: URL(string: "bug://never-works")!) { Image("puppy") .widgetAccentedRenderingMode(.desaturated) } The same goes for buttons: Button(intent: MyDemoIntent()) { Image("puppy") .widgetAccentedRenderingMode(.desaturated) } I've tried hacky solutions like putting the link behind the image using a ZStack, and disabling hit testing on the image, but they don't work. Anything else to try? Logged as Feedback #15152620.

We're building a UGC AR app and are leveraging App Clips to distribute AR experiences without app download. Since earlier this week, many of our users are reporting sharing experiences as App Clip doesn't work anymore. They are getting the message "AppClip unavailable" on a little card. We attached a QR code to try it yourself and a link to a different experience. We tried with multiple experiences and on multiple devices already. https://scenery.app/experience/1C925FDE-E49A-489B-BA14-58A4E532E645 Interestingly, we can't pinpoint the issue to an exact device or OS. We tested on many devices and on most, the AppClip is being displayed as unavailable, stating "App Clip unavailable", whereas it works on a few. It all worked fine last week (before September 12th). iPhone 13 Pro Max, iOS26: works iPhone SE, iOS 17: works iPhone 16 Pro, iOS 26: doesn't work iPhone 12 Pro Max, iOS 26: doesn't work iPhone 12 mini, iOS 18: does not work iPad 9th gen, iOS 26: doesn't work Please help. Our users are very dissatisfied as they expect this to work and it's a crucial feature. We already filed a radar via Feedback assistant: FB20303890

Basically when showing a view using the .fullScreenCover modifier, it has no background anymore, any other UI elements are still shown but the view under it is also still shown.

Using an App Clip link encoded into a QR Code shows an error when scanning the encoded QR Code on an iPhone or iPad. After being scanned, the App Clip's banner is visible, but a message says: "App Clip Unavailable". Accessing the same App Clip URL via Safari works as expected. I've filed a feedback with more details and screenshots of the issue here: FB17891015 Thanks!

Xcode 14.1 Running on iPhone 14 Pro max simulator 16.1 Code... import SwiftUI struct ContentView: View { @State var loggedIn: Bool = false var body: some View { switch loggedIn { case false: Button("Login") { loggedIn = true } .onAppear { print("🍏 Login on appear") } .onDisappear { print("🍎 Login on disappear") } case true: TabView { NavigationView { Text("Home") .navigationBarTitle("Home") .onAppear { print("🍏 Home on appear") } .onDisappear { print("🍎 Home on disappear") } .toolbar { ToolbarItem(placement: .navigationBarTrailing) { Button("Logout") { loggedIn = false } } } } .tabItem { Image(systemName: "house") Text("Home") } NavigationView { Text("Savings") .navigationBarTitle("Savings") .onAppear { print("🍏 Savings on appear") } .onDisappear { print("🍎 Savings on disappear") } .toolbar { ToolbarItem(placement: .navigationBarTrailing) { Button("Logout") { loggedIn = false } } } } .tabItem { Image(systemName: "dollarsign.circle") Text("Savings") } NavigationView { Text("Profile") .navigationBarTitle("Profile") .onAppear { print("🍏 Profile on appear") } .onDisappear { print("🍎 Profile on disappear") } .toolbar { ToolbarItem(placement: .navigationBarTrailing) { Button("Logout") { loggedIn = false } } } } .tabItem { Image(systemName: "person") Text("Profile") } } .onAppear { print("🍏 Tabview on appear") } .onDisappear { print("🍎 Tabview on disappear") } } } } Video of bug... https://youtu.be/oLKjRGL2lX0 Example steps... Launch app Tap Login Tap Savings tab Tap Home tab Tap Logout Expected Logs... 🍏 Login on appear 🍏 Tabview on appear 🍏 Home on appear 🍎 Login on disappear 🍏 Savings on appear 🍎 Home on disappear 🍏 Home on appear 🍎 Savings on disappear 🍏 Login on appear 🍎 Home on disappear 🍎 Tabview on disappear Actual logs... 🍏 Login on appear 🍏 Tabview on appear 🍏 Home on appear 🍎 Login on disappear 🍏 Savings on appear 🍎 Home on disappear 🍏 Home on appear 🍎 Savings on disappear 🍏 Login on appear 🍏 Savings on appear 🍎 Home on disappear 🍎 Savings on disappear 🍎 Tabview on disappear Error... 10 and 12 in the actual logs should not be there at all. For each tab that you have visited (that is not the current tab) it will call onAppear and onDisappear for it when the tab view is removed.