I assume this is because of the white bar area at the bottom of the screen. The same amount of vertical space in the browser has to be squished to fit a smaller amount of vertical space above the white bar. Okay, that makes some sense.
But when downloaded on an iPhone 11, it still gets stretched:
Shouldn’t the final version of my app display a circle when I created a circle? What’s the fix for this? I really don’t want to adjust the height and width to unequal values to make the shape appear as a circle.
Is there a way to set the dimensions of the screen to better match my device?
I’m excited to mention our layouts component that should be released sometime in the near future hopefully!
That will bring back the flex environment to drag and drop. We’re brining back rows and columns yall! It’s just not ready to go live yet. I’ve done some testing and it’s dope, it’s just not 100% ready yet!
If we do user beta testing, i’ll be sure to ping you for that!
This should not make a visually rounded button unless you use a square device’s screen.
According to the documentation, Thunkable uses the screen size of 375x669 to import Figma files so if you use the same ratio you should get a nearly circle button. You are right because you can never know who will use your app and in what screen dimensions.
So for every 100px of width you should have about 88px of height.
This will be updated in future iterations of the platform coming soon hopefully. The updates that I preview today will absolutely remove the confusion! I’m not sure when we’re going to release it yet but just know that we see you too and we’re going to get rid of that confusion.
I think that there’s really valid use cases for both so I asked one of our engineers their input on why we would use either or and why we’ve defaulted to what we have and the following was the response which I think is pretty good
Use case 1. Expecting a component at the edge of the screen
If users wanted a component that was at the edge of the screen, it essentially wouldn't be possible with float in place.
Use case 2. Expecting an image to fill the screen.
If a user has an image that is completely fills the width of the screen in the designer, it should fill the width of the screen on the users' device. Float in place would put spaces on either side
In theory, we don't want to encourage building tablet/responsive apps on the phone designer. Users should use the tablet builder for tablet/large screen apps. In the context of building apps for phones, given how little the widths don't change that much on phones, stretch should generally be appropriate to maintain user expectations for the two points above.
For now, if a user really wanted float in place to be the default, they can create a group that covers the full screen and set it to float in place. It's an easy workaround.