iOS apps already build on x86 CPUs every time you run them in the simulator. Both the ARM CPUs and the Intel CPUs are both little endian and the the APIs are largely the same on Intel and ARM versions of MacOS (except for some Metal APIs).
Until recently I used to support an 25 year old C++ codebase on Solaris for both Sparc and x86. Like the Power PC, Sparc is a big endian architecture so I did have to make some changes but that was a one time effort. It was harder to support the code on both Solaris and Linux.
I think it was harder to support both 32bit and 64bit ARM during the iOS 64bit transition (something we didn't even attempt with the Solaris C++ code base).
There are of course edge cases. These are the ones listed by Apple for apps moving to ARM
- Interacts with third-party libraries you don’t own.
- Interacts with the kernel or hardware.
- Relies on specific GPU behaviors.
- Contains assembly instructions.
- Manages threads or optimizes your app’s multithreaded behavior.
- Contains hardware-specific assumptions or performance optimizations.
The third party library issue is probably the most serious potential issue. That can be a difficult problem to solve. However, the termination of 32bit support in Catalina has probably already flushed a lot of those problems out. Assembly language and hardware level access can be a problem but I doubt that will be a common problem. Personally, the last time I wrote assembler was about 30 years ago.
However (aside from GPU issues) most of these problems are much more likely moving existing x86 Mac Apps to ARM.