Once your app is live, most of what you change reaches your users the moment you deploy your Rails app. A new build is the exception, and this page covers when you need one.
The app loads your site, so your views, routes, and copy update with your next Rails deploy. So does the native config in config/ruby_native.yml, which the app fetches on every launch: tabs, the navbar, colors, and the rest of the native polish all change without a build or a review.
Deploy a new build when you change something baked into the app itself:
Push notifications and in-app purchases are not on this list, because every build includes them. An app built before that change needs one more build on each store to pick them up.
Apple closes a version once it goes live, so the next build needs a new number. Ruby Native moves to the next patch on its own: after 1.0 goes live, the next deploy builds 1.0.1.
To pick a different version, set it in your app's settings, or name it when you deploy:
bundle exec ruby_native deploy --version=1.1
Apple requires a few lines on what changed with every version after the first, and shows them on your product page. Write them on the App Store listing before you submit. Google Play shows the same text as the release notes.
Google Play has no version train. Every deploy gets a new build number and lands on internal testing, and you promote it to production in Google Play Console when you are ready.