As you noted in your #2, both iOS and modern Android systems allow for secure local storage. Though the details (and security) differ by platform, and with Android can differ by device. At a minimum there is storage tied to the particular app and can be tied to biometric unlock. You locally store an encrypted version of the password in normal app storage, and then you have the key to decrypt that live in the device's secure storage.
That key is made available upon biometric unlock and used to decrypt the encrypted password. Then the password is used as your existing scheme describes. The mechanisms for iOS and Android differ. On iOS you can actually have the decryption of the password done within the device's Secure Enclave. Indeed, you can have the enclave generate this key and encrypt the password for you on first setup.
A note on different key derivation for the same password
Your overall approach of having an authentication key and an encryption key derived from the same password is good. Your goal seems to be to have the service that is authenticated to never receive secrets that could be used to decrypt the user's data. That is a very good thing to aim for.
There are a couple of things to worry about and a few things that I don't understand. I should add that I helped design the system used by 1Password for this.
What is the authentication process?
I am assuming that the app authenticates to a service under your control. Are you treating the client created "authentication hash" as a password as far as the server is concerned? I am assuming that that is roughly what you are thinking, but you need to spell that out, and make it clear what gets sent to the server and what the server does with it.
The client must control which KDF process is used.
If, say, you use a different salt and different KDF parameters for the two processes, be sure that the server can't get away with sending the parameters for deriving the encryption key when it should be sending the parameters for deriving the authentication key. Presumably, when a new device is enrolled, the client app will need to get salt and parameters from the server, and so that is when a malicious server (or an attacker in the network) could send the parameters intended for deriving the encryption key to the client telling the client that these are for the authentication key. The client would then derive the encryption key and send that over the network.
The solution to this is to hard-code something into the client that makes the key derivation different for the two cases even if they are given the same salt and parameters. If you use, say, HKDF in the process, you can code in different "info strings" for the two cases. That way, even with the decryption salt and parameters, the key that is derived by the authentication KDF will never be the same as what is derived by the encryption KDF.
Make authentication zero-knowledge
As long as you are building a custom authentication scheme, you might has well use a zero knowledge one.
Instead of transmitting the derived authentication hash/key to the server for authentication use it as part of a Password Authenticated Key Exchange (PAKE). This means that an attacker who can listen into to the client/server exchange (or tamper with it) can't learn anything that could be used to replay a login attempt. It also means that the server proves its identity to the client.
Do not use SRP (as we did with 1Password). There are much better PAKEs available know (and more patents have expired). AuCPace would be my first choice for building something today, but OPAQUE is also a good choice (and there may be more libraries for it).
Use a slow/hard KDF for deriving the authentication and encryption keys from the password.
Assuming that people will use weak passwords, you need to plan for what happens if their encrypted data gets captured either from their device or your servers. So you should use something like Argon2, scrypt, bcrypt, or perhaps even PBKDF2 (again, not my first choice, but it is what was available in all of the right places when we designed the 1Password system).
Anyway, that is what occurs to me off of the top of my head late at night.