It is not possible, nor necessary, to take extreme measures to protect the source code. Focus your energies on what adds value to your business, rather than wasting it "treating customers as thieves and thieves as customers."
Is it possible to protect the source code?
You can not disable others from reverse engineering your program, at most you can make difficult . Code obfuscators are a good option if it is simple enough to deploy it next to your product. But that will not stop a dedicated attacker from figuring out how his software works or, more simply, simply copying his binary code himself.
In the same way that you can obscure your code, the attacker can dazzle you again and / or employ other techniques to make it appear that the copied code is different from yours. How to prove that it's the same code later? (in the case of a lawsuit, for example)
You may need to perform diagnostic actions on your program, debug parts with problems, etc. This becomes much more complicated if your code is overshadowed, increasing its cost in servicing customers. If the obfuscator itself does not introduce a bug, which would make the "de-fused" version work, but not the obfuscated one.
It is necessary to protect against ...
Whoever wants to copy your system will copy it anyway, regardless of "understand how it works" or not. Crack tools generally act on the binary itself, so there is no interest on the part of the attackers in the sources.
If the hardest part of marketing a product was to build it, then maybe that would be justified (in the case of mobile apps, it's not far from that, but I do not have enough experience to comment). But there is much more involved: marketing, support, continually improving the product from customer feedback, etc. It's already a pretty big job, and that's without having to worry about being sued at any time for copyright violations. A serious competitor will not copy your code, even if you rub it in his face.
As for "figuring out what your code does," I ask: is this really relevant? Are there trade secrets in it, or technologies not yet released to the general public, things that only you and your company know? If the answer is yes, then go ahead and protect. Otherwise, do not worry too much about it, probably your competitors already know everything they need to know about your system, what prevents them from copying it right now is the opportunity cost (ie you have arrived first, and have already won certain clientele, who comes later will have to make extra effort to steal it from you).
If your system uses " security for obscurantism ," then stop and review your design. Ideally, systems should be kept safe even if all the details about the algorithm are public, only the "key" (or equivalent) is secret. If you can not avoid this, making it harder to read the fonts will stop casual attackers (script kiddies) but not the more dedicated ones, so take that into account when weighing the risks.
Clients as thieves and thieves as clients
If your app is in an "App Store", 95% of people will simply buy it, do not try to steal it from you (lie, 20% will buy and 75% will not use your application). And the other 5% are not going to just say "oh, it's harder to copy, I think there's only one left for me to buy ..." - they will either give up once or go a little harder (remember that 1 person crack and distribute to all others). In one way or another they are not your customers , you will not get any money from them, so what difference does it make if they copied your application or not?
On the other hand, attempting to apply DRM (or any other anti-piracy measure) to a system can make it slower, buggy, complicated to install / use / debug, etc. This harms your customers indeed, those who have paid for your product and expect a quality experience.
In conclusion, take simple steps to protect your program when you can, but do not worry too much about it. Do not depend on the secrets of sources for safety. And focus on creating a better product than the competition, instead of being concerned about the competition copying your product as it is now (and not how it will be in 6 months, for example).