Short answers about building, shipping and pushing.
No. You give the builder a URL, a name and a package id, pick a shell, and it queues a GitHub Actions workflow that returns a signed APK and AAB. Nothing asks for Java or Gradle.
An APK (for testing and sideloading) and an AAB (for Google Play). Both stay attached to the app page, and the download list shows every build with its version and version code.
Right now this install allows 5 build(s) and 1 notification(s) a day on Free, 50 / 10 on Pro and 999999 / 999999 on Agency. Those are settings, not constants - the site owner can change them, and the upgrade page always shows the current values.
Content changes are instant, because the app renders your site. Changes to the shell - icon, name, colours, splash, offline screen - need a new build, because they are compiled into the APK.
Yes: the app page has an Edit form for name, URL, package id, colour, icon and shell choices. Changing the package id makes it a different app inside Play, so do that only on purpose.
The app shows the offline screen you picked in the theme library instead of a browser error page.
It is your website inside a WebView, so whatever your site does with cookies and sessions is what the app does. Nothing is proxied through us.
A Firebase project: upload its google-services.json and the service-account JSON, then send from the app page. You can target everyone, a topic, or one device token.
It is encrypted at rest with AES-256-GCM using your ENCRYPTION_KEY and is only decrypted when a send is actually performed or a build payload is fetched. Rotating that key makes previously stored accounts unreadable, so set it once.
No. Without a Firebase project there is no channel to the device; choose the "no Firebase" option and the notification screen stays disabled for that app.
Yes - Settings has a delete-account form that asks for your password and a typed confirmation, then removes your apps, builds, notifications and device tokens in one transaction.
Your user row and profile go away. Payment records are kept without your email attached, because receipts have to be retained for accounting.
In your own GitHub Actions workflow, using your keystore. The runner fetches what it needs from a single-use HMAC URL that expires with the build, so no account credentials travel to the runner.