Signing changed?

[IzzySoft]

It looks like you've changed your certificate: today's release was signed with a different one than before, and thus blocked as update to my repo. I've checked the releases tab, but found no explanation. Can you please elaborate? And, if it was intentional (which I have good reason to believe), add a hint at the corresponding release – as "updates" are not possible if the signing key was changed?

[sahej-dev]

Thanks a ton for pointing this out.

It seems while prepping the app for publishing to the play store I had changed the signing config for my app. I failed to forsee any trouble regarding publishing of the app on your repo due to not fully understanding the concept of app signing.

However having read up on that. Now I'll be maintaining a separate branch to build the app for play store, and reverting the main branch (on which all releases are/will be made) to use the original signing config.

Do I need to delete the release with the wrong signing key, or would just publishing a new release with the original signing key work?

[IzzySoft]

May I mention another approach? In the past, you've used a debug key, which is not recommended for distribution. So maybe just add a hint to the release notes stating the key change and its reason (switching from debug key to a proper one is a good reason on its own) plus the fact it needs a one-time "fresh install" (export settings/data, uninstall, re-install, import settings/data), add a second APK (the one signed with the previous key) to prove it's legit, then moving on with the new signing key?

That way, your app is properly signed with a release key pointing to you, folks can verify its legitimacy by updating once to the debug-key-signed APK and then move on with the "real one", I can validate the same and switch to the new one in my repo – and you don't need two separate builds.

If you choose that path, it would also help to have per-release changelogs set up with your Fastlane structure to deliver the very same hint – or at least have a line in the app description stating something like "if you're running a version prior to 1.3.2, you will have to uninstall the old version and install the new version, as the signing key changed (see {link}). Apologies for the inconvenience!"

What do you think?

[sahej-dev]

This approach looks like the better way to go. Thank you for helping me navigate this.

I plan on doing the following:

• v1.3.3 will be the release after v1.3.0 (it breaks conventions of semver a bit but I think that should not be an issue)
• Release v.1.3.2 is deleted
• v1.3.3 changelog will contain the hint for signature change
• Same hint is permanently added to the fastlane full description (and will be present in at least 10 future changelogs)
• v1.3.3 release will contain APKs for all ABIs with the previous signature too including snow-arm64-v8a.apk and snow-arm64-v8a-old_signature.apk

Does that sound good? Will two APKs passing the /arm64-v8a/i Regex check to find the update APK cause any issues?

[IzzySoft]

Sounds good! Please let me know once that release is ready, because…

Will two APKs passing the /arm64-v8a/i Regex check to find the update APK cause any issues?

The updater will pick the first one it encounters, so "yes and no". But this will be for one release only. I need to verify anyway, and will adjust here accordingly when the check passes. That release with the "doubled APKs" won't be considered again by my updater, and future releases will no longer have the doubling. So this little hick-up is the price we'll have to pay – but I'd say it's worth it.

[sahej-dev]

The release is ready and available at https://github.com/sahej-dev/Snow/releases/tag/v1.3.3.

[IzzySoft]

My updater reported to already have picked it up, without complaints – so it probably got the one with the old key (so it already solved the part of "proving the one making that release is the one holding the original key" 😉). Let me check then…

OK, APK replaced, index is building built, syncing now. Temporarily, both keys are allowed, until 1.3.0 aged out.Then I'll remove the allowance for the debug key.

Thanks a lot! And if you want a little more background on those signing stuff, see How to keep your key safe and what measures to take for the event of loss? (or read the entire article; it's not too techy as it was written by me 😉) That said: you were well prepared, having kept the original key. Kudos – I had more cases where this was different than cases where it worked out that smoothly!

[sahej-dev]

Thank you for guiding me through this. I would have been lost on my own. I'll give that article a read soon.