F-Droid's maintainer is against shipping builds of their app without rebranding the app id, app name and logo which is itself reasonable. However, F-Droid itself distributes builds of thousands of apps without following those same expectations for them...
matrix.f-droid.org/room/!UAdCANfo
Conversation
According to F-Droid, distributing a non-rebranded alternate build of their app undermines their brand. That's their overall approach to packaging.
matrix.f-droid.org/room/!UAdCANfo
I personally don't care if they reuse name/logo for alternate builds, but reusing app ids is very broken.
1
1
8
If a user installs the F-Droid build of an app in one profile, they get a key pinning error when they try to install the official build in another profile. Reusing app ids goes against the entire purpose behind having app ids. Each incompatible build needs to their own app id...
1
1
9
Incorrect app id reuse leads to users reporting the same key pinning errors upstream over and over.
F-Droid also places a substantial burden on upstream developers by distributing their own builds of apps with undocumented downstream changes and significantly delayed updates...
2
1
10
The app id reuse also causes significant usability issues beyond the key pinning errors users encounter across profiles. Users run into similar issues with updates. F-Droid will think it can provide updates to an app installed from elsewhere and vice versa for Play Store, etc.
1
1
6
Some developers create these issues on their own by not using separate app ids for different variants of their apps, but many are handling this properly and most don't have incompatible variants available. F-Droid is the elephant in the room making this a common real world issue.
Replying to
I want to temper this: a nice side effect is that it pushes app developers to do data export/import in their app in order to let users migrate from differently signed apks. Ideally this data management should have been provided by the OS UI though…