In addition to the tools available or readily available in the AppStore, my iOS development environment requires the following environment support:

  • homebrew
  • cocoapods
  • fastlane
  • Arm64 emulator for Xcode

homebrew

The original writing because don’t have access to raw.githubusercontent.com, may lead to install stuck or failure.

After a bit of potholing, I finally found this website:

brew.idayer.com/

Use the following commands to install Homebrew for arm and x86 respectively:

/bin/bash -c "$(curl -fsSL https://cdn.jsdelivr.net/gh/ineo6/homebrew-install/install.sh)"
Copy the code
arch -x86_64 /bin/bash -c "$(curl -fsSL https://cdn.jsdelivr.net/gh/ineo6/homebrew-install/install.sh)"
Copy the code

The ARM version will be installed in the /opt/homebrew/bin/brew directory and the x86 version will be installed in the /usr/local/bin/brew directory.

After the installation is successful, a message is displayed indicating that you need to manually execute a script:

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"
Copy the code

You can manually edit the. Zprofile file in the user root directory to ensure that it contains the following contents:

eval "$(/opt/homebrew/bin/brew shellenv)"
export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.ustc.edu.cn/homebrew-bottles/bottles
alias abrew='arch -arm64 /opt/homebrew/bin/brew'
alias ibrew='arch -x86_64 /usr/local/bin/brew'
Copy the code

Run source ~/.zprofile to refresh the configuration.

In this case, enter brew-v, ibrew-v, or abrew-v. The following information is displayed:

mirari@MBA ~ % brew -v
Homebrew 3.2.4
Homebrew/homebrew-core (git revision 64a2874e87; last commit 2021-07-27)
Homebrew/homebrew-cask (git revision 9d5abe6a67; last commit 2021-07-27)
mirari@MBA ~ % ibrew -v
Homebrew 3.2.5
Homebrew/homebrew-core (git revision 507807b9dc; last commit 2021-07-27)
mirari@MBA ~ % abrew -v
Homebrew 3.2.4
Homebrew/homebrew-core (git revision 64a2874e87; last commit 2021-07-27)
Homebrew/homebrew-cask (git revision 9d5abe6a67; last commit 2021-07-27)
Copy the code

The installation is normal.

Although HOMEbrew was installed successfully due to Internet reasons, most of the tools, such as Bob and Fastlane, were prompted that no tool of that name could be found.

Error: Could not resolve HEAD to a revision

Using brew-v, you can see that Homebrew-core has no HEAD.

Run the following command to rectify the fault:

git -C $(brew --repository homebrew/core) reset --hard HEAD.
Copy the code

But just to be on the safe side, I still rm-RF the directories of the two Brews and reinstall them.

fastlane

After homebrew is installed, run Brew Install Fastlane directly to install homebrew.

cocoapods

Before there is a text prompt brew on cocoapods has stopped updating, need to use gem installation, now go to see has not, brew directly run brew install Cocoapods can.

Arm64 simulator for M1 chip

This is the worst part.

Xcode, the new M1 environment, encountered a number of problems when running old projects, such as this error message:

building for iOS Simulator-x86_64 but attempting to link with file built for iOS Simulator-arm64
Copy the code

Either the corresponding Framework cannot be found, or the current Symbol is not recognized under the current ARCH.

Solution 1:

In the list of visited applications, find Xcode, right-click on Show Introduction, and select “Open with Rosetta.”

It’s rude and brainless. When you start Xcode like this, the emulator is now x86, perfect for x86 environments. Dependencies that do not compile arm64 in an emulator with the XCFramework will work fine.

However, the execution efficiency of Xcode will be affected, which I cannot accept.

By the way, the Mac version of IntelliJ IDEA, downloaded directly from the official website, is the x86 version of the Mac version, running in the M1 environment is very slow, used for a day, the whole person was sick, Power Mode II typing effect is serious frame drop, had to be turned off. Before downloading from the official website, click the right side of the download button to switch to the ARM version, which is silky smooth.

I made my own xcFramework package that includes both X86_64 and ARM64 in the emulator environment (Google does). If the M1 chip runs x86, why not throw it to the eye?

However, it is not easy to configure the project to run under arm64. After a few attempts, the solution is as follows:

Solution 2:

There are three compilation targets involved, which are:

  • Target, the third party library pod relies on, includes source code and Framework
  • Target, the native source library used to compile the Framework
  • Call the above dependencies and run the application Target on the emulator or real machine
The application Target that runs on the emulator or real machine

First make sure that the Build Settings for the application project Target itself, which calls the Framework and runs the emulator, are configured as follows:

  • Architectures is the default value$(ARCHS_STANDARD)

Under the M1 chip, the emulator default value should be ARM64, armv7

  • Build Active Architecture Only with Debug set to Yes(if emulator is running in Debug mode)

The purpose of this step is to make the simulator only compile the ARM64 code when compiling the target. Do not try to compile the arch such as x86. Because it depends on the POD and the arch of the own library will be specified as having only one ARM64, if you try to compile another ARCH you will get an error.

  • Delete the Excluded Architectures

The purpose of this step is to let the POD manage the parameter, do not set the value manually. When this value is set manually, the POD installation will receive a warning.

[!]  The `Demo [Debug]` target overrides the `EXCLUDED_ARCHS[sdk=iphonesimulator*]` build setting defined in `.. /Pods/Target Support Files/Pods-Demo/Pods-Demo.debug.xcconfig'. This can lead to problems with the CocoaPods installation - Use the `$(inherited)` flag, or - Remove the build settings from the target.Copy the code
  • Delete Valid Architectures

New xcode12 projects should have this parameter removed by default. The new Version of Xcode no longer requires this parameter to specify archs.

Target, the third-party library pod relies on

Add hooks to your Podfile

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['ONLY_ACTIVE_ARCH'] = 'NO'
    end
  end
end
Copy the code

Because it is useless to manually modify the POD project in Xcode, all changes will be restored once pod install is executed. Hooks are therefore needed to handle the configuration items for the POD installation.

The effect of this step is to have pod compile all archs, including x86 and ARM64, at compile time.

The reason for this is that the pod installation in the emulator environment will still compile the open source dependencies on x86 (I assume), Building for iOS simulator-x86_64 but attempting to link with file built for iOS simulator-ARM64 So we use this statement to make POD force all arch to compile.

Target, the native source library used to compile the Framework

For the rest of the configuration, refer to the above application Target, but the Build Active Architecture Only item needs to be changed to NO, which means that the above pod configuration is manually operated.

Finally, remember to delete the Pods directory and remove the project cache before executing the compile.

Solution 3

The other operations are similar to scenario 2, but change the Build Active Architecture Only configuration for pod and the own library to operate Excluded Architectures instead. The specific operation is:

Target, the third-party library pod relies on

Add hooks to your Podfile

post_install do |installer|
  installer.pods_project.build_configurations.each do |config|
    config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = "arm64"
  end
end
Copy the code
Target, the native source library used to compile the Framework

Build Active Architecture Only under Debug remains YES, but Excluded Architectures are set to ARM64.

The purpose of this step is to make Pod dependencies and your own library emulators compile without arm64.

Reference: stackoverflow.com/a/63955114/…

Now, you know, the ARM64 simulator should get an error, but it actually works, and I don’t know why

But while the application itself works, the own library still needs to include all of the archs when it is packaged. [Bug Mc-10875] – Arm64 is filtered in POD. If the library relies on the open source library that has the source code in POD, it will cause the ARCH of arm64 to be lost during compilation and packaging. Therefore, if the project itself is purely an application, using solution 3 to exclude ARM64 will save resources and make compilation faster. In the case of a tool library, you will have to compile all archs using scenario 2.