Why It’s Currently Impossible to Publish a Properly Responsive Android App in Thunkable

[grant.mccallum]

Hi all,

I wanted to share some very simple but very telling test results about what’s happening with layout rendering on Android builds right now.

If you’ve been pulling your hair out wondering why your pages suddenly clip through the bottom of the screen or why scrollable pages no longer scroll to the end, congratulations, you’re not imagining it. Layouts on Android are quite seriously broken.

This isn’t speculation. It’s a confirmed regression, acknowledged by Thunkable staff back in August (see my original post here). Two months later, there’s still no fix, no date, and no explanation of what changed.

To make this as clear as possible, I built a four-page test app that anyone can open and check on their own device. Each page demonstrates a different layout configuration, with colored backgrounds and red borders so clipping is obvious.

The Test App

Each screen has navigation buttons along the top so you can switch between them easily.

1. Two stacked 50% containers, no scrolling.

2. Two stacked 43% containers, no scrolling.

3. Two stacked 500px containers, Layout set to scrollable.

4. Two stacked 500px containers, Page set to scrollable.

Top container = green.
Bottom container = yellow.
Everything outlined in a red border.

Project link so others can reproduce this.

Results on Thunkable Live App (Android)

Screen 1: Displays perfectly, the Thunkable toolbar hides the last few pixels and the bottom red border, but that’s normal.

Screen 2: Displays perfectly, covers about 86% of the screen with even white space top and bottom.

Screen 3: Scrolls beautifully. Same minor toolbar offset at the bottom, but otherwise perfect.

Screen 4: Broken. Containers shrink to less than full height, and the app lets you scroll into empty white space. Not ideal, but not a huge problem if scrollable layouts work.

Results on Exported .APK (Android Build)

Screen 1: Broken. Bottom of the page is clipped.

Screen 2: Broken. Whitespace appears at the top, and the bottom of the page is clipped.

Screen 3: Broken. Bottom 10-15% of the screen is clipped. (This is me scrolling all the way to the bottom of the screen)

Screen 4: Still broken, though amusingly this is the only test that doesn’t clip the content, it just gives you a full scroll of useless white space instead.

TLDR / Conclusion

Until this regression is fixed, it is literally impossible to create a properly responsive Android app in Thunkable.

• Using percentages? Your layout will clip.

• Using pixel heights? Your layout will clip.

• Making it scrollable to catch overflow? You’ll still lose the bottom of your page.

Thunkable has acknowledged this as a confirmed regression, but as of today there’s been no fix, no timeline, and no official communication in the release notes.

If you’re publishing production apps, be aware that what you see in Thunkable Live is not what users will see in the published Android build.

Feel free to test it on your own devices - I’d love to see your results, hear about any workarounds you have found and hopefully we can get some visibility (and pressure) on this issue.

Thanks all,
Grant

@tatiang @sketch @martint @krish05 @annaradnor70pzj4mu @22kifayatun8ne @maurizio.polverini89 @iffsydl78qiz

[mcm4ts]

Serious Responsive Layout Bug Still Unresolved – Business and Financial Damage

Hi everyone,

I’m posting this to share my experience and hopefully bring more attention to a critical issue that’s been affecting many of us building Android apps with Thunkable.

Since August 13, 2025, a major responsive layout bug has made it impossible to properly publish or update Android apps. In my case, this was confirmed by a freelance developer I hired (and paid) to help with my project — but the work could not be completed because of this regression.

The consequences have been serious:

• I had just launched my app on the Google Play Store this summer, but I’ve been forced to unpublish it because the entire responsive layout broke after this bug appeared.

• My company has suffered reputational damage, loss of partner confidence, and financial losses, while I continue to pay my Thunkable subscription every month without being able to use the platform as intended.

I’ve already submitted a formal complaint to Thunkable Support but… so far, there’s still no estimated date for a fix.

I’m sharing this here so that others affected can also make their cases heard — this situation is clearly impacting developers and businesses who trusted Thunkable for production-level apps.

If no resolution is provided soon, I’ll have no choice but to cancel my subscription, migrate my project to another platform, and consider taking further action for damages.

I truly hope Thunkable addresses this issue transparently and urgently — this bug is not just a small technical problem; it’s hurting real projects and companies.

— Javier Pareja
Thunkable user & app publisher

[grant.mccallum]

Thanks for sharing your experiences, Javier.

At this point, it’s clear that this is preventing multiple developers and companies from maintaining their apps or earning revenue which is a real shame as Thunkable is a fantastic tool for rapid mobile development when it works.

Anyone else seeing this behaviour on their Android builds, please test using the demo project linked above and add your results here.

[maurizio.polverini89]

Hello Grant,

Thank you for sharing this.

To be honest, I’ve also had my fair share of headaches with Thunkable’s layout. I can’t remember exactly when, but I definitely went through the same frustration trying to figure out what I was doing wrong.

The solution? I eventually learned how to work with it. Unfortunately, we all know the platform isn’t perfect — even though it’s fun to use and provides enough flexibility for small projects.

Real-world coded apps can be just as challenging — believe me when I say that — and they often don’t display exactly as you expect across different devices.

I hope you get the support you need soon, as I can see this is an important blocker for you. From someone who has also hit his head against the wall a few times, my suggestion is to try to find a workaround.

After all, a developer’s life is one continuous workaround.

[grant.mccallum]

Hi Maurizio,

You’re 100% right that workarounds are a huge part of any developer’s life!

That said, this particular case goes a bit beyond a typical layout quirk.

The same design worked flawlessly for years across multiple Thunkable versions, and then a recent platform update changed how Android handles height calculations, breaking previously published apps and forcing redesigns for production users.

Unfortunately, there doesn’t seem to be a viable workaround for this one, as demonstrated in my test app. Every variation still results in clipping or layout distortion on Android exports.

So while I’m all for creative problem solving, this really needs to be addressed at the platform level.
When a framework introduces a regression that invalidates existing layouts (and doesn’t document it in the release notes), it’s not a “quirk”, it’s a stability issue that affects every paying developer relying on Thunkable for commercial apps.

I’m still hopeful Thunkable will fix this properly. Perhaps foolishly.

Best,
Grant

[ioannis]

Hi @grant.mccallum @mcm4ts

We can understand that it is frustrating and appreciate you taking the time to investigate and provide more information.

A workaround to solve the bottom crop issue is to set the Layout height to 620. Could you please try it?

The white space at the top is expected when the height percentages are not 100% in total and the Layout orientation is center
Thank you, again, for your time and patience in this matter.

[grant.mccallum]

Hi Ioannis,

I will test this.

Are you using float in place or stretch for your layout type?

Thanks,
Grant

[grant.mccallum]

Hi Ioannis,

I have retested using the settings you recommended:

Test configuration:
Layout Height: 620px
Resize Mode: Stretch
Vertical Alignment: Top

Test Scenarios & Results

Test 1:
Two containers @ 50% height each
No scrolling

Result: Bottom of screen still clips.

**
**
Test 2:
Two containers @ 500px each
Layout set to scrollable

Result: Still clips at the bottom, even when fully scrolled.

Summary

Regardless of what layout size you choose, whether the screen uses percentage heights or fixed pixel heights, and whether scrolling is enabled or not, the Android build continues to clip the bottom of the page.

So unfortunately this workaround does not resolve the issue.

I appreciate you looking into this, but I do want to re-emphasize that this behavior worked correctly for years and only started after a recent Thunkable update. Since there doesn’t appear to be a functioning workaround, this remains a blocking regression for production Android apps.

Please let me know when engineering has an update or if there are any additional settings you’d like me to test.

Thanks,
Grant

[ioannis]

Hi @grant.mccallum
I am sorry that the previous workaround hasn’t worked for you.

I have found new workarounds.
So for the first issue, I believe that because the borders take some pixels, I suggest setting the height of each container to 48%.

For the second issue, a workaround is to add a third container and set its height to 100 px.

It might also help to set the Layout height to 615px.

Here is the project I tested and worked: https://x.thunkable.com/projectPage/691614a8724b92b2d14047f8