You will have to consider a tradeoff here. The point of a KDF like scrypt is that it generates keys from user-generated passphrases. If you’re going to burn the passphrase into the app, it doesn’t make sense to use a KDF at all; you might as well just burn the AES key in instead. This would make your app simpler to write (all you need to do is the AES-GCM encryption/decryption) and use (no need to enter passphrases).
However, the big problem with this approach is that anybody with access to the app binary (or a device with it installed) has everything necessary to decode all the information on the chips. The only way to avoid that is to have users input something that is never stored on the device, such as a passphrase at app startup time. If that is determined to be unacceptable for business reasons, you just need to make sure that the person making that decision understands the security impact and the fact that control over the app binary (and source) will likely become the weakest link in the security of the entire system.
If all your devices have access to a private server that could be used to distribute keys, that would be another option, but I haven’t implemented that part, so can’t say much more in terms of implementation details there.
I can’t think of how that would help. A blackhat with a copy of the app would still be able to read any chip, presuming that a whitehat with a copy of the app needs to be able to do so.
Not precisely when it comes to writing things to RFID chips, but as far as encrypted storage and transmission, yes, several times, but each system has its own set of specific requirements that determine the best shape for the system. From what I’ve heard from you so far, it seems that if you can live with the fact that the app binary needs to be secured as carefully as any key would be, then a hardcoded or server-distributed AES key used in GCM mode would be your best choice.