So ... naturally, third parties cannot reproduce bit for bit of an Android executable APK file as it contains the signature which third parties cannot generate. This is why when testing APKs for nostr:npub1j9kttlc86w63emmldd4h74rekyqpksqup6p9trhp5gjsf374qlyszvuswx we have to take a bit more efforts and thus have to make more assumptions than when there is no signature.
You compared the sha256sum hashes. If those match, the files match or whoever knows how to generate hash collisions could get filthy rich mining Bitcoin.
The APK is a zip file. You can literally rename it to app.zip and unzip it. Inside you will find the signature in a folder called META-INF. Content in that folder is not covered by the signature, so you could put some "malicious" files there, zip it again, rename it .apk and Android would load it as a good, signed by the provider app. Android should not load or do anything really with your "malicious" file but ... that's the assumption. Maybe some payload could be planted that could confuse Android to still do something shady.
Anyway, the app's sha256 fingerprint depends on not only the compressed content that could vary in the META-INF folder but also on the compression itself. I don't know why but I did observe different hashes for same versions of the same app even with both obtained from Google.
All that said, to diff two APKs, use unzip and recursive diff or use diffoscope. If you find diffs only in META-INF, you should be good. In your case you should not find diffs in META-INF neither as you expect the same signature.
