Muse AI docs
 v2.0.0
Live demoConsole demo Get help
● Ship · For buyers of the previous version

Upgrading from 1.x to 2.0.0.
A new codebase: what to keep, what to set up again.

Version 2.0.0 replaces the 1.x app of this item with a product written from scratch: a Flutter app, a Firebase backend and an operator console. No 1.x file is reused, so you cannot copy 2.0.0 over your old project. You can still publish 2.0.0 as an update of the app you already have in the stores, so your users get it as a normal update. This page shows how, in plain steps.

Keep your app idKeep your signing keyCreate the store productsRevoke old in-app keysChats are not imported

01In short

Google Play and the App Store accept a new build as an update of your existing app only when two things stay the same: the app's id (Android application id, iOS bundle id) and, on Android, the signing key. Everything else (code, backend, settings) is new. So you take the 2.0.0 folders, put your old id and key into them, set up the new backend and console, and upload.

02What is different

  • New code. The 2.0.0 app, backend and console are new. Start from the 2.0.0 folders, not from your 1.x project.
  • Keys live on the server. 2.0.0 keeps every AI key in your Firebase backend (config/private), entered in the console. The app contains no key.
  • New name. The product name no longer uses a third-party AI trademark. Your own app keeps whatever name you give it.
  • Configuration. Nothing from a 1.x configuration is read. Models, limits, texts, plans, ads and purchases are set in the 2.0.0 console.
  • More features. Discover, voice mode with natural voices, the video studio and image tools are new; they ship switched off.

This page does not describe 1.x itself; use your 1.x project only to look up the ids and keys named below.

03Step by step

  1. Write down what you keepFrom your 1.x project: the Android applicationId (in the app's Android Gradle file), the iOS bundle identifier (in Xcode), your Android upload keystore file with its alias and passwords, your Apple team, your AdMob app ids and unit ids (if you showed ads), and your store product ids (if you sold anything).
  2. Put your id into 2.0.0In the 2.0.0 app/: replace com.mikodes.museai with your existing id (Release → ids to replace), raise version in pubspec.yaml above the version of your last store release (for example 2.0.0+<a higher build number>), and put your AdMob app ids in AndroidManifest.xml and Info.plist.
  3. Sign with your existing keyCopy your existing upload keystore into app/android/app/ and point android/key.properties at it (Android signing); choose your existing team in Xcode. With a different key Google Play refuses the update.
  4. Set up the backendFollow Installation steps 1 and 2: a new Firebase project, or your existing one on the Blaze plan, then deploy firebase/.
  5. Connect the appRun flutterfire configure in app/, with your existing id.
  6. Start the console and enter your settingsInstallation steps 3 and 4: AI keys, models, legal URLs, limits. Then the optional modules you want.
  7. Store productsIf you sold subscriptions or one-time items in 1.x, decide which plan each old product id belongs to and enter those ids on Console → Plans (subscriptions, lifetime) and Store & purchases (Remove ads, credit packs), or create new products with the 2.0.0 ids (Plans and paywall). Set up verification (In-app purchases). Do this before you release, so that Restore purchases finds a plan for existing subscribers.
  8. AdsEnter your ad unit ids in the console (Ads).
  9. Revoke the old keysRemove any API key your 1.x build carried inside the app and revoke it at the provider (delete it in the provider's API keys page). A key that was compiled into a published app can be extracted from it; 2.0.0 does not need it, and anyone holding it could keep spending on your account. Revoking it stops the AI features of copies of the old version that are still installed, so revoke it once the update is live.
  10. Test, then releaseTest on a device with a release build, run tool/check_ad_ids.sh --release, then upload as a new version of your existing store listing. Update the store texts, screenshots, age rating and privacy answers to what 2.0.0 does.

04Users' data

  • Chats saved by a 1.x app are not imported. 2.0.0 stores conversations in its own format on the device. Tell your users in the release notes that the new version starts with an empty history.
  • Purchases: entitlements are rebuilt from the stores. With verification set up, a user taps Restore purchases and the backend verifies their subscription or one-time purchase again, if it uses a product id that 2.0.0 knows (the ids you entered in the console). Consumed credits of 1.x are not carried over.
  • Accounts: 2.0.0 creates an anonymous Firebase account per install; users can sign in with Google, Apple or e-mail.

05Checklist

  • Same application id and bundle id as the published app.
  • Same Android upload key; same Apple team.
  • Version and build number higher than the last store release.
  • Backend deployed, console set up, Status without blockers.
  • Old product ids entered on Plans / Store & purchases, or new products created; verification set up.
  • Old in-app API keys revoked at the provider.
  • Release notes mention the new app and that chat history starts empty.

06Future updates of 2.x

For updates after 2.0.0, read the Changelog entry, back up the console's data/ and ADMIN_SECRET_KEY, replace the code folders while keeping your own changes (ids, icons, signing files, .env), redeploy the backend with firebase deploy, restart the console, and build the app again.