So, is there any creative way to build it so it can't be reverse engineered when private keys are stored locally and without forcing users to have very long passwords?
No. This fails Kerckhoffs's principle - you must assume that an attacker can know everything about your system, and therefore only a secret entered by the user can offer any security.
If not, then is it correct to assume that no local software wallets are secure and the ability to gain access to the private keys is just a matter of skill of the attacker?
Local software wallets that have a passphrase are potentially secure. Local software wallets that do not have a passphrase are not secure, even if they use something like the Windows Data Protection API (DPAPI), because an attacker who gains code execution on the system under the same context as the user (e.g. by the user running malware) can just called the DPAPI functions and decrypt the wallet.
I'm creating a mobile software crypto wallet. I'm not an expert
Please do not use this for anything but fun. You should not store any funds in there that you do not intend to be stolen. Implementing secure cryptographic storage of data is a non-trivial task, and doing so in the context of a mobile app introduces additional security challenges (e.g. insecure intents/segues).
On a personal note, I think anyone who stores significant amounts of uninsured funds in a digital wallet on a general purpose computing device (PC, laptop, phone, etc.) for the purposes of opening and using that wallet on that device, regardless of whether it is password protected or not, is utterly insane. It's a gamble that the app you're using is legitimate and not backdoored, that it was engineered correctly (cryptocurrency people are hilariously bad at secure development in my experience - see the BitFi debacle for just one example), that the other software on that device is secure, that the OS itself is secure, that the device has full-disk encryption and that the FDE can't be violated in any way, that the device's hardware architecture is hardened against evil maid attacks (e.g. using an IOMMU... properly), that the device is doing proper chain-of-trust boot verification to prevent bootloader modification, and that the preboot environment (e.g. UEFI) is correctly signed and verified. If any of that fails - and it is absolutely bound to at some point - then your entire set of funds is at significant risk. Single-purpose devices with verifiable software are the way to go, but so far I haven't seen any that have a good security posture and reasonable attitude towards security research.