feat: make appId available from config

[riderx]

In app coming from old age of Cordova, some have different app id in IOS and Android. Sometimes we need to know the Capacitor config to know the common name. Example in Capacitor-updater for statistic purpose it's better to have the same appId and just a breakdown on the platform.

For that i use deprecated methods to get them, on android like that: https://github.com/Cap-go/capacitor-updater/blob/ccace58e615ef21c775db89bacc6296b2cf03d3f/android/src/main/java/ee/forgr/capacitor_updater/CapacitorUpdaterPlugin.java#L40 And IOS like that: https://github.com/Cap-go/capacitor-updater/blob/ccace58e615ef21c775db89bacc6296b2cf03d3f/ios/Plugin/CapacitorUpdaterPlugin.swift#L18

So this PR adds the missing appId i need and remove the legacy code usage. i think allow the full config can be good for some usage, but it's better to start little like that

[jcesarmobile]

appId is only used on npx cap add command, users could change it after that in the config file and the native value that was set on add would not be reflected with the change, so I don't think the appId should be accessible from the config.

If you need the actual native value that is set based on appId value (applicationId on Android and PRODUCT_BUNDLE_IDENTIFIER on iOS) you can get the native values BuildConfig.APPLICATION_ID for applicationId and Bundle.main.bundleIdentifier for the PRODUCT_BUNDLE_IDENTIFIER

[riderx]

@jcesarmobile on capacitor side it's use only when doing the add, agree.

When people come from Cordova, they can have 2 different appId for platform, that happen. So they change the native one after add to don't loose they app in the store.

But most of them want to identify the app as the same for IOS and Android. And that exactly the case in Capgo. people manage only on app to auto-update.

Then the only trustable value for that become the appId from the config. The native is not what is need because it can be different for both app.

As example my app Captime, have appId ios ee.forgr.captain-time and android ee.forgr.captime because android have been created later and - is not allowed in android

[lincolnthree]

It sounds from this discussion like the only trustable ID is a user-defined UUID or projectId that they put in the source code themselves. That way it doesn't matter what Capacitor or Cordova or any outside system calls the project.

If Capacitor maintained the appId as a separate configuration entity, I would support using it in this way, but it sounds like it's only for initial setup/build process.

I would argue it probably could expose the appId from the configuration file at runtime so devs could use it, but... that's mostly speculative, and sounds like it would be a solution looking for a problem.

IMO: There are a million ways one could do this themselves if necessary. None of which seems any simpler than just creating an ID and putting it in the code.

I think being declarative about Hot/OTA updates is probably better than "Magic", in this case anyway.

[jcesarmobile]

Closing for the reasons explained in my first comment.

Apps should not rely on the config file appId value on native as that could not match. If CapGo needs a common appId that could be different from the real appId, then that should be a configuration option in CapGo, not in Capacitor.