The company provided a COMPUTER with an Apple M1 chip to record some problems encountered during installing React Native and the solutions to Xcode compilation errors after the installation was successful.

Install React Native

1, follow the Steps of Chinese installation, Installing Boost stuck

Github.com/CocoaPods/c…

Solution: open the file open ~ /. Cocoapods/repos/master/Specs / 9/9 / d/boost / 1.59.0 / boost podspec. Json

Modifying the Download Path

"source": { "http": "< https://downloads.sourceforge.net/project/boost/boost/1.59.0/boost_1_59_0.tar.gz?r=&ts=1513105136&use_mirror=kent >"},Copy the code

 

2, Pod install error after clone project down

Because there is no node_modules,

Node_modules can be downloaded using NPM install or YARN, but it is very slow and often fails with timeout.

Install CNPM to replace NPM, npmmirror.com. Run CNPM install to resolve the problem. This method causes problems, use NPM install –legacy-peer-deps.

This tip is a special reminder of RN Chinese, need to pay attention to

An error occurs when pod install is executed. Sudo ARCH-x86_64 gem install FFi and ARCH-x86_64 pod install. There are also JSON:: parsererror-416, JSON:: parsererror-451 errors, which can be resolved according to Cocoapods github issue.

It is best to use NPM to generate node_modules files and proceed to pod Install

Ii. Xcode compilation failure process

Origin of the problem:

Until Apple released the M1 chip, it used Intel chips without any problems. After the release of M1 chip, due to the different architecture (M1 is ARM64 architecture, Intel is X86_64 architecture), resulting in a lot of software running problems. If you use Xcode to build an emulator on M1, you may encounter the following error:

building for iOS Simulator, but linking in object file built for iOS, xxxx for architecture arm64
Copy the code
ld: symbol(s) not found for architecture x86_64
Copy the code

These errors are caused by the existence of a. A or. Framework static library in the project. Previously, when we created static libraries, we would package one copy for the real machine (ARM64) and one copy for the emulator (x86_64), then merge the two copies into one package and import them into the project for use. On Intel models, the arm64 directive is used on the real machine and the x86_64 directive is used in the emulator (x86_64), so there is no problem. However, on the M1 model, the emulator runs in ARM64, and obviously running in X86_64 will cause problems.

Solution:

1. Run Xcode in Rosetta mode.
Running in 'Rosetta' mode is a solution for 'x86' software on 'M1' machines. It translates' x86 'instructions into' ARM 'instructions. This translation obviously has a performance loss of around' 20% to 30% ', and is not recommended unless it is necessary.Copy the code
2, modify,Build Settings -> Excluded ArchitecturesAdd the Any iOS Simulator SDK option and set the value to arm64.

Modifying the Excluded Architectures option has its problems. We set arm64 exclusion in the emulator to solve the problem that the emulator cannot compile ARM64.

It’s a little confusing that this works, as we know that on Intel machines, the emulator runs on x86, so excluding ARM64 makes no difference. But on the M1, the simulator runs in arm64 mode, so I can run without arm64, which puts my IQ on the ground. On the M1 model, the emulator will still run as ARM64, but the app in the emulator will run as x86. We have to disagree with apple’s operation. The illustration is as follows:

In this case, the simulator and application can communicate via XPC, although there will be no problem in theory, but the communication time is not long, lead to some problems can rely on the timer judgment logic, sliding gestures, for example, the acceleration of judgment will be out of some problems, lead to the simulator in most cases the following table can’t trigger the inertial scrolling.

Other problems

Sometimes when an “Excluded Architectures” option excludes the arm64 instructions of the emulator and still fails to compile, this is usually caused by a discrepancy between the project Settings and cocoapods Settings, which usually resolves the problem. This can be resolved by adding the following to your Podfile:

The optimal solution

From the above, we know that the problem is caused by the presence of.A or.framework in the project, which provide an incomplete instruction set. Apple also offers a solution to this problem, so let me elaborate.

Taking Xcode13 as an example, when we create the static library, the package compiled by the real machine only contains arm64 instructions, while the package compiled by the simulator contains both ARM64 and x86_64 instructions. I read some online tutorials that tell people to remove the arm64 from the emulator, but you don’t have to. Because to support M1 machines to run the simulator properly, the simulator must contain both arm64 and x86_64 instructions.

At WWDC 2019, Apple offered a new framework package format, XCFramework. Packages that were previously merged into different sets of instructions using LIPo are now merged into the XCFramework format using the new instructions.