Test ADB install fails when done over published app

[trevix]

Hello.

I haven't been able, both on Android and iOS, to ADB test install a new version of my standalone if on the hardware device there still is a previous version, which has been published and installed from the App store or google play store.
I always have to first disinstall the app, loosing obiously all the app preferences etc..

I need this in order to check that a version update of my App smoothly replace the previous App, the one that has been published.
Obviously I can take the long way: delete the App, install the old version from LC, run it to create preferences and then install the new version from LC.
But since I am using the splash method, I fee that I may make a mistake and loose something...

How come I cannot replace the app?
Is there any way to do this?
Thanks

[SparkOut]

In the standalone settings, are you changing the version number at all? If you use a higher integer than the current installation, then it should install as an update.

[trevix]

Yes I do, but when ADB installing a new version, the old version launches if it isn't running, and nothing happens if it it is running.
Same result, on Android, even signing the test app (as I do in order to publish it).

[SparkOut]

Just to be doubly sure, where are you setting the version number and what format is it?
If you are using typical dotted format for major.minor.release numbers, this will possibly fail. Just use an integer that is higher than previous and try that.

[bamakojeff]

I *think* this is intentional. When you install an app from an app store (Apple or Google), the app store makes it impossible to install an identically named app which did not come as a legitimate update from them. So the various app stores cryptographically sign apps that you upload to them for installation through the store (in addition to your own signature). This insures that no one can (maliciously) sideload their own version of "com.myCompany.myApp" and overwrite your legitimate version of "com.myCompany.myApp".

I certainly see what you see - that if I install my app from an app store, I cannot load a new version of the same app through Android Studio or XCode. I must uninstall the version from the app store before I can load my own version. And vice-versa is also true. If I have a version of my app that I installed myself and I attempt to install the same app through the app store, the installation fails. I must uninstall the version I installed before I can install the app from an app store.

Again, I don't claim to be an expert on app store security, but that's my understanding of what's happening and why you can't mix delivery methods.

HTH

Jeff

[trevix]

@SparkOut
I don't think that this really matter. In any case the published version is already in the form of "1.3.1" with a "Version code" like 253.

@bamakojeff
I think you stand correct. It makes sense.
But my own signature shouldn't be enough to stamp the app as legitimate?

Since now it is possible (is it?) to distribute a legitimate App outside the two main stores, this store cryptographic addition shouldn't be removed?
After all, as you say, it has been thought just so that you can install apps only from them, isn't it.

So I guess there is no solution to my problem...

Trevix

[bamakojeff]

Part of the legal arguments that Apple made in their case against Epic defending their exorbitant cut of all profits from apps distributed through the App Store was that they are providing a "valuable service" to users and developers by insuring that no malicious actor could ever counterfeit an app which has been distributed through their app store. If you get an app from an outside source, they argued, then you are relying solely on the security of the developer to secure the app. If the developer doesn't keep their private key secure, then the fact that they signed their app is not a guarantee of security or legitimacy.

It's not a wholly unreasonable argument. I was an sysadmin for 20+ years, and WAY too many times people said things like "I followed the instructions to make a private and public key pair so I could do 'X', but I can't get it to work. My private and public keys are attached to this email. Can you get it working for me?" When people are emailing their private keys, is there anything "private" about them?

So I doubt the App stores will ever remove their store-level signatures. It would invalidate one of their main legal arguments for why they have every right to take half your profits for signing and distributing your app. Of course IANAL, and all this is speculation. But for all the Star Trek fans out there, there must be a Rule of Acquisition which says something like "Greed is best justified by appeals to 'Security'."