The ability to save and revert back to previous versions of your app’s design. Your Collections and user data will not be changed when you restore previous designs, only your screens, actions, components, etc.
This one is huge, but on top of it I’d like to see a Staging and Production version system - which is likely more important than just being able to Roll back - so we can develop and test without affecting production.
Tony Dehnke: Yup i totally agree with tony we want this & it’s a imp one too
Any update on this? This is something which will really help me in managing my work.
If it is not happening soon, is there a workaround? Basically I want to keep a stable state where I can easily revert to.
yes please!
I think the main thing is the ability to make changes in draft mode without it affecting the live apps
Elementor has a pretty nice setup for this (Wordpress plugin) if you are looking for inspiration Ben Haefele
Amazing!!!
Ben Haefele thanks for creating this feature, I think it would be a must to not edit in the live version but to edit in staging. Do you think this will be possible in this feature? Or any ideas for a workaround?
please prioritise, this is desperately needed to be able to work properly. Especially with webapps.
We are already able to save copies of our different app versions and revert back to them.
CTRL or COMMAND + Z works (a bit) - but what would be very useful to consider is a publish button. When I develop changes they are immediately live. That’s a true mess. Now I create a duplicate op my app and do changes there, but that doesn’t work smooth all the time.
We’re doing research and early scoping right now on a versioning system. More specifically, a way to easily save the state of your current screen designs in the editor and easily revert to older versions. Our current thinking is that the first release of this would not touch your collections or data and would be focused on screens, components, actions, styles, etc.
Josh Johnson: Just in case you’re soliciting feedback… This would be useful from a purely design perspective - being able to undo levels of edits and have an edit history.
But what would be much, much more useful and important would be production/live and dev/test versions where one version is in production (published) while the other one is used for dev and doesn’t affect live. When ready the dev version could be pushed to prod (published). IMO this would be MUCH more useful than simple versioning. This would allow testing on live (or test) collections before publishing.
Versioning and live/dev environments both seem to be mentioned in this thread, so I think it’s appropropirate to raise this here. Perhaps see what the community prefers (if planning is early enough)?
We’re looking into this for later this year as well. I’d like to understand your use case a bit more. Is your use case for web apps specifically (since native apps have builds that sort of serve this purpose)? Also, you specifically mention collections. When you say you want a “dev version” do you mean of your app’s design and screens or do you mean that you want a dev database with only your test data in it? I’m sure the answer is both but if you had to prioritize, which is more important to you and why? Thanks! This helps.
Josh Johnson Paul H: this could force users to update the app before any usage can be done upon making the dev published to prod. Kind of like how the Amazon flex app forced its drivers to update the app when an update is published before they’re allowed to make deliveries or access the app in any way.
It would be beneficial
Josh Johnson: (Sorry I didn’t see this until now)… So for web-apps, the use case is obvious, but for native apps, it would be useful to have in-production stable code, so that we can continue development on new features in the dev environment, but if there are any bugs in production code, they can be fixed separately and we don’t have to worry about other changes interfering (for example). Also I think it’s good practice to have prod code separate from dev code (using the word code to mean Adalo here :)).
Seperately have a production and test database is useful, but I think it’s easier to manage seperate test and real data in a database (you can identify and account for test data, at least in the apps I’m building). So if I had to prioritize it would be two code states before database.
Hope that helps!
Paul H: Yes that helps a bunch. Your prioritization makes perfect sense to me and is how I think about it too. Thanks!
Josh Johnson: just a bit more why I think this is so important…
I’m integrating with Stripe (my own Custom Actions) and need to be able to have live and test API calls. Once my app is live, I can’t easily use test APIs (otherwise I need to start maintaining API keys and URLs on a customer basis), so having the ability to use different API keys/calls in production and test would be a lifesaver.
It hit me over the weekend how important this is. Once I publish a production app, then publishing new TestFlight apps means that my production app is going to end up wildly different to whatever the current Editor version is, making it very hard to track differences (again for testing customer feedback, bug fixes, etc). I think it goes without saying that having a nocode equivalent of something like Github would be great in this respect.
Hey folks! We’ve got something for you to try out if you’re interested. We’re calling it Design Versions and we’d love for you to help us test it. If you’re interested, this form will tell you all about the feature and allow you to sign up for the beta. Note that you’ll need to be on a paid plan to test Design Versions. Thanks! Explore Typeform | Create your own surveys, quizzes, forms