Help with Stack Navigator

I am genuinly confused… If you do want to have a header then what is the issue with the header you already have? Why do you want to remove it? The blank space at the top of the screen is the screen navigator’s header but it does not seem to have any value to show. Here is what I think: Since you are combining a screen navigator and a tab navigator, you are trying to achieve something non-standard which ends up not working anyway. Question: Why do you need a header when using a tab navigator which shows the tab you are in?

can this help?

1 Like

The header has way too much padding and takes up a third of the screen. I need a stack navigator to navigate the screens within my homepage. The stack navigator has that much spacing either way so its not something “nonstandard”, its a bug

Would it be possible to share your project link so I can take a look?

I am experiencing the same on newly created apps. The new implementation of the tab navigator seems to be broken in more ways than I can count. Try uninstalling and reinstalling the Thunkable Live app as I see that you are on iOS and there is no way (afaik) to delete the app’s cache. Deleting it on Android somehow helps but there are other things that don’t work as they should, like the SwipeEnabled option which remains enabled even if it is set to “false”. Luckily enough, I have the old implementation of the tab navigator in my older apps which I can save in a screen and then reuse but the new implementation is really really really buggy.


Ok I think I see what the problem is. Even if you disable the “ShowIcon” and “ShowLabel” options, the tab navigator will still preserve the space dedicated for those two options. This is not an expected behaviour and is not the way the previous implementation of the tab navigator behaved.

@Steven is this bug known to you and if so, are you planning to release a fix anytime soon?


No, I was not aware of this issue. I’ll add it to our list and make sure we take a look at it.


Ok I just noticed this: The top tab navigator does not reveal the “Tab Bar Visible” option for the screens it hosts. Instead the bottom tab navigator does:

Same screen in the Bottom and the Top Tab Navigator

Here is how to reproduce the bug:

  1. Create a Top Tab Navigator and a Bottom Tab Navigator. Notice that the screens under the Top Tab Navigator are missing the “Tab Bar Visible” option and that the screens under the Button Tab Navigator aren’t.
  2. Drag a screen from the Bottom Tab Navigator and drop it into the Top Tab Navigator. You will notice that the “Tab Bar Visible” option is still there. However, if you click another screen in the Top Tab Navigator and then click back the screen you moved from the Bottom Tab Navigator, you will see that the option is missing!
  3. Move the screen back to the Bottom Tab Navigator, click another screen under the Bottom Tab Navigator and then click the one you moved back again. Presto! The option is available again.

You can repeat the same process with a screen from the Top Tab Navigator and you will come to the conclusion that the bug impacts the Top Tab Navigator. When the “Tab Bar Visible” option is available and switched to “false”, there is no blank space at the bottom of the screen and in the same way, if it would be available for the Top Tab Navigator, it would (should) not have the blank space on the top of the screen either.

I will keep looking for bugs impacting the navigators. I hope the above helps.

EDIT: So it appears that my previous references to “tab bar navigator implementations” were somehow correct. Check out how different the Top and Bottom Tab Navigator options are:



Ok, so it seems like we are discussing at least a few separate issues in this thread.

  1. There is currently an issue on iOS with stack navigators where the header is taking up much more space than it should. I have a fix for this that we are currently testing so we should be able to get that released soon.

  2. There might be some issues with the tab navigator though I’m not 100% clear on what they might be. Seemingly just the SwipeEnabled property is no longer working? I tested it and it seems to be working. There is some weirdness in the UI at the moment where it defaults to showing the property as disabled/false but is actually enabled. If you toggle it in the UI it should behave as expected afterwards. So I’ll get that fixed but I think it should mostly be working as expected.

  3. You expect disabling ShowIcon and ShowLabel to indicate that the Top or Bottom Tab navigator should essentially not be shown at all if I understand correctly? I don’t believe this is the case. If you want them to be invisible you can use the property on the screen(s) to set Tab Bar Visible to false. At the moment, this isn’t possible on a Top Tab Navigator, bringing us to…

  4. Separately, you noted that the Tab Bar Visible property is not available on screens in side of the Top Tab Navigator. It seems this was an intentional choice on our end though I’m not clear on why. I’m going to look into it. We might be able to enable this but it is difficult to say for sure without knowing the original reasoning.

Anything else that we need to address?


Hi @Steven

Thank you very much for looking into this. I will start with the easy ones:

.4. If it is unclear to you, imagine how unclear it is to us! :slight_smile: . Finding out that top and bottom tab navigators behave differently raised our earlier comments related to point 3 so if the “Tab Bar Visible” switch becomes available on both bottom and top tab navigators then the issue described in point 3 is obsolete.

.3. Commented above.

.2. Since we now know that top and bottom tab navigators behave differently, I took another look at them separately and came to the same conclusion as you did. The bug exists only on the top tab navigator and can be reproduced by creating a new one and noticing that the initial value of the “Swipe Enabled” value in the GUI is “false” despite the fact that in reality, it is enabled. I now check your workaround by switching it on and off again (sic) and the switch value gets synced with the real value. A fix would be nice so we are looking forward to that.

.1. Looking forward to the fix :slight_smile:

As for whether there is anything else which needs to be addressed, there are plenty of other issues not related to the navigators so if you would like to look into them, we are more than happy to provide all feedback necessary to fix them.

EDIT: I think I experienced some performance issues with the top tab navigator, I am not sure if they are related to the “Lazy” option or not but I will keep testing and let you know.

Kind regards


Hi @Steven,

First of all many thanks for looking into this. Actually there are some issues which seems you didn’t address in your previous message:

ISSUE no. 1

  1. Create a project with multiple screens in a buttom tab navigator
  2. Add a Data list/grid viewer in one of the screens included in the buttom tab navigator
  3. Show items in the Data list/grid viewer
  4. Scroll down thorugh the items
  5. Go to any different screens than the one including the Data list/grid viewer
  6. Go back to the screen including the Data list/grid viewer
  7. You will notice that the Data list/grid viewer shows the first item in the list at the top - and not anymore the item you left earlier. Now it’s more than 2 weeks that I am getting this - it didn’t happen earlier.

ISSUE no. 2

  1. Create a project with multiple screens in a buttom tab navigator
  2. Add a Data list/grid viewer in one of the screens included in the buttom tab navigator
  3. Show items in the Data list/grid viewer
  4. Create a screen outside the buttom tab navigator
  5. Select an item in the Data list/grid viewer
  6. Pass the data (i.e images, text, etc.) in the new screen positioned outside the buttom tab navigator
  7. You will notice a glitch in the status bar (in Android)
  8. In addition, I have experienced a slower response when I go back to the previous screen (earlier this was faster)

Please also see the post below:

I have already provided to @jane a copy of my project with instructions on how to reproduce the issues.

Due to these issues I can’t publish an update of my app - now it’s more than 2 weeks that I have an update ready.


Addressing the same points from my earlier post:

  1. We are testing this change now. If everything goes well, it should be available sometime later this week or early next week.
  2. Same as above, I have a fix that is currently in testing. Assuming all looks good, will be released in the same time frame.
  3. I think this is generally a non-issue as it isn’t so much broken as it is confusing. We can maybe update our docs to clarify and/or revisit this soon. I think there might be some changes coming in the way that we display properties so it will likely get addressed at that point.
  4. I wasn’t able to find a great explanation as to why it was disabled and, as far as we can tell, it seems to work just fine if we enable it. So, basically same situation as #1 & #2 though this one might be in testing a bit longer just to verify we aren’t missing something.

@Tommaso Thanks for sharing! I’ll take a look at these as well. I’m going to just restate your problem so we can verify I understand.

  1. It seems like the Data Viewer component is simply not holding the scroll position when you navigate between screens inside of a bottom tab navigator.
  2. There is a status bar issue on Android when going from a screen inside of a bottom tab navigator to one that isn’t. There might be some link to Data Viewer/Data Sources causing the issue. Additionally, there seems to be slowness when navigating though it is unclear if the issues are related.

Obviously, I don’t yet know exactly what the issue(s) is so I don’t know when we will have a fix but I will look into these shortly so we can help get them resolved and enable you to publish your update.


Hi @Steven,

Many thanks for looking into this - I hope the fix will be soon available as I really need to publish an update for my app.

Just a few remarks on 1. above - the issue is also extended to screens outside of a buttom tab navigator. Earlier the data viewer had the scroll position even if returning from a screen outside the buttom tab navigator.

Please let us know, as I assume others in the community have the same problems. Thanks!

1 Like

Hi @Steven, any news on this? Did you manage to find the issue(s)?

I need to publish an update for my app which includes AdMob - this means I am losing money every day. Please let me know. Thanks!

I’m trying to recreate the issue. What I’m seeing doesn’t seem to match with what you’re saying. Basically in my testing it seems like everything works as expected when the DV is inside of a navigator. It retains the scroll position and does not force a refresh.

When the DV isn’t on a screen inside of a navigator there is some interesting behavior which has to do with how we handle screen navigation. Outside of a navigator, if you navigate to a screen it is pushed on top of the current screen. So, the original screen still exists but is beneath the screen you are currently on. When you navigate to the original screen, rather than going back to the existing one, it creates a new version that is pushed to the top.

I tried recording a short video to demonstrate this but there is a limit to the file size of uploads on our community. Let me know if you don’t quite understand and I’ll upload it to demonstrate further. The solution for this is to use a navigator. If you use a stack navigator, use the included header and back button to go back to the screen rather than create a new one. If you’re using a tab navigator it should work as expected. Does that make sense?

If you don’t see the same behavior as me, can you please make sure your Thunkable Live app is updated to the latest version? Or if you’re downloading your app, can you rebuild it and try again?

In either case, if your main claim is that the scroll position was not previously reset when neither screen was inside of a navigator that seems like an issue. Do you have any idea as to how long ago this changed? I’ll have to try and narrow down the cause of it.

Hi @Steven,

Many thanks for your response. The latest version I have published in the stores (Google and iOS) is dated January 5th, 2021 - this doesn’t have any of the issues I listed above.

Instead, in the version I want to update I am still facing these issues - I am using Thunkable Live v. 25801 and I tried to download and install (Android) again the updated version of my app but it still doesn’t work.

My main issues are:

  1. the scroll position is reset when:
    a) a screen with DV is inside the bottom tab navigator
    b) the other screen is either outside or inside the bottom tab navigator
  2. when going to a screen (outside a bottom tab navigator) from a screen inside the bottom tab navigator, I can see a glitch in the status bar (it becomes dark grey for 1 second)
  3. when returning from a screen (outside a bottom tab navigator) to a screen inside the bottom tab navigator (which includes a DV) the transaction is really slower than before (and the scroll position is reset - see point 1. - Perhaps this is indeed related to point 1., considering that the go back to previous screen seems to trigger the “reload listviewer” which may be the cause of the issue for slowness)

I will message you a copy of my project privately - hope this helps!

@Steven, maybe the issues are related to the fact that I worked for a while on the staging platform?


  1. @Steven I have tried to duplicate my project and tried if it worked in that way - however, I am still facing those issues. Hence, you should be able to reproduce them through the link of my project I sent you privately. Please let me know. Thanks!

  2. Regarding when I have noticed the issue for the first time, as far as I recall, it was on the meantime you implemented the UI design.

Question: @Steven actually I think that the issues could be related to the fact that it seems all screens are loaded twice - is it something possible?

Gents, why dont we set up a 30 minute troubleshooting session on Skype or whichever other platform to check the issues in real time? I don’t think that ping-pong messages help in such cases. I am located in Europe (timezone-wise).


Hi @Steven, do you have any news about this? I would appreciate your confirmation that this is a top priority. Thanks!

1 Like

Update: Hi @Steven, I have also tried to replicate those issues in an empty project in which I have included:

  1. Bottom tab navigator
  2. No. 1 screen outside the bottom tab navigator
    Please find the project copy link here: Thunkable

Procedure to replicate the issues:
a) In the DV appearing on the screen click on the item ee-26 (you will navigate to the screen outside the bottom tab navigator)
b) 𝗬𝗼𝘂 𝗰𝗮𝗻 𝗶𝗺𝗺𝗲𝗱𝗶𝗮𝘁𝗲𝗹𝘆 𝗻𝗼𝘁𝗶𝗰𝗲 𝘁𝗵𝗮𝘁 𝘁𝗵𝗲 𝘀𝘁𝗮𝘁𝘂𝘀 𝗯𝗮𝗿 𝗯𝗲𝗰𝗼𝗺𝗲𝘀 𝗴𝗿𝗲𝘆 𝗳𝗼𝗿 𝟭 𝘀𝗲𝗰𝗼𝗻𝗱 and then white (I have set the status bar color to white)
c) Click on the “Back” button and you will navigate to the previous screen (the one which includes the DV)
d) 𝗬𝗼𝘂 𝗰𝗮𝗻 𝗻𝗼𝘁𝗶𝗰𝗲 𝘁𝗵𝗮𝘁 𝘁𝗵𝗲 𝗗𝗩 𝗿𝗲𝘀𝗲𝘁𝘀 𝗶𝘁𝘀 𝗽𝗼𝘀𝗶𝘁𝗶𝗼𝗻 (starting from the first item of the list)

I think with this project I replicated the simplest way to reproduce the issues - hope this helps! We now need only the solution as soon as possible.

As already said, I can’t publish an update of my app due to these issues.

1 Like

Hi @Steven,

It has been now more than 1 week you sent your latest message on these issues. I feel like I am talking alone.

I have also sent a message yesterday to @jane asking for any updates and got no reply. I am mentioning here also @domhnallohanlon which can maybe help us to put the dots together.

It’s now more than 3 weeks that I first reported these issues. I have also been asked to publish a post in GitHub, and I did it.

Any of your feedback guys would be much appreciated. Thanks!

1 Like