I read the papers - it can't, they just seem to have novel ways of controlling the zones available. I supposed the smaller the miniLED array the more control you can have over the zones and the better it works. But there doesn't seem to be anything that really solves the bleeding issue.
It is definitely a challenge, but as prev EM / hiring manager of many iOS / Android devs it certainly isn't impossible. Not sure about large and expensive. Surprisingly most of my best devs were all inbound, not via recruiters. Felt recruiters usually wasted our time and small teams of native devs can get a lot more done than web teams (at least so it seems based on my subjective exp).
My previous company had probably well over a dozen web engineers and then for our mobile side we had a total of 3, myself included. We also often had to adapt designs ourselves and work with product to fix flows for native. But we still managed to keep up with web.
edit: and not "keep up with web" in the we are working 80 hour weeks type thing, very normal working hours, 9-5. Possibly more normal than the web team.
I agree with Expo being pretty painless. Anytime people are really set on using RN I tell them, just use Expo. Now a day, you can integrate external libs and such quite easy.
Eh. Not sure I agree, unless you mean taking a non-native already made react bit and try to turn it into RN.. that is far harder and does require lots of money.
too many people don't realize just how non-portable react code can be.
I don't agree, and I have worked with this significantly as a consultant and core contributor to react-native. What typically happens is people convince themselves what you are saying is true then there ends up being huge delays to spin up all the infra app side... THEN eventually, they kinda are okay. until the next react-native release.
edit: would like to clarify that of course I would recommend better ways... but... clients do as clients do.
Cloud + a probably similar method, but, the process the author used is not efficient in figuring out the private frameworks work. You could do a few things I think that would allow you to debug the framework calls & iMessage itself to understand what is actually going on / how it’s used.
lambda can run up to 30m I think (idk about lambda@edge). CF Workers fail when trying to use something like node-unfluff, because the CPU time takes too long.
This seems to me, like a more controllable lambda@edge.
I am working on PO-33, doing EMFI.