We have little detail on the security goals or the hack (to the point that the question feels detached from reality), thus this answer is not specific.
- Used key & IV which was only plain text length of 16
The key length of 16 chars (AES-256) is unlikely to be a real practical issue for a short-term attack. Even if we restrict to 32 = 25 possible values per char, that's 80-bit, which is at least hard to break. An exception is if the key was in the code (see 3), where directly using a text key (especially if it on the tune of "MyZup3rZ3cr3tK3y") helps attack.
The IV of 16 bytes is standard, and OK in practice if it does not repeat. Constant or otherwise repeating IV can be a disaster, especially with the common AES-CTR, just like a reused pad in the OTP.
- Key not hashed with SHA-256
That's not an issue, if the key is random. If it's not (e.g. derived from a password or passphrase), SHA-256 is inadequate and it's needed a purposely-slow "password-based" hash, e.g. scrypt or Argon2.
- It was an Android app (Xamarin Forms) and I did not obfuscate the app
If the key was in the app's code, it's quite possible it was extracted from there. While obfuscation helps to a degree, embedding secret or private keys in code is fragile, and bad practice. Yet it's common because the alternatives are more complex, and either hardly safer or not portable.
It's also entirely possible that a hack worked around the crypto without breaking it, e.g. that code which execution is conditioned by a cryptogram was executed without cryptogram, by bypassing the test.
When a standard API is used for the crypto, that API can be where a competent hacker watches, and that can be a disaster if confidential data transits here (this is the point of encryption). Or if the key transits here, which sometimes is unavoidable (when AES is used to communicate with another device or server, and the API does not have provision for encrypted loading/export of keys).
This app is reading information from QR Code encrypted content. An attacker is able to create a QR Code with fake information that becomes a valid QR code.
What about signing the QR code? The public key can be embedded in the app, and it becomes impossible to forge a QR code that the real app will tell genuine, no matter the reverse-engineering. For small QR codes, and if something standard is thought, ECDSA or EdDSA would be fine.