ios Xcode6：运行模拟器的两个实例

Xcode6: Run two instances of the simulator

提问by vintagexav

I have two different targets for my iOS app. Is it possible to run simultaneously the two apps on two different instances of the simulator? It's ok if it would require not to benefit of the Xcode's debugger. So far the only solution I found was to install two versions of XCode, but that's a very heavy/space-consuming solution.

我的 iOS 应用程序有两个不同的目标。是否可以在模拟器的两个不同实例上同时运行这两个应用程序？如果它不需要从 Xcode 的调试器中受益，那也没关系。到目前为止，我找到的唯一解决方案是安装两个版本的 XCode，但这是一个非常笨重/占用空间的解决方案。

回答by i40west

You can run two instances of the iOS simulator from the command line. They won't be attached to Xcode debugging—indeed, it seems only to work if you do it without Xcode running at all.

您可以从命令行运行 iOS 模拟器的两个实例。它们不会附加到 Xcode 调试中——事实上，它似乎只有在你完全没有运行 Xcode 的情况下才能工作。

First, you need to run the app in the simulator from Xcode, in order to get it installed in the simulator. Make sure you're running the same simulators you'll ultimately be using

首先，您需要从 Xcode 在模拟器中运行该应用程序，以便将其安装在模拟器中。确保您运行的模拟器与您最终将使用的模拟器相同

Now open a Terminal window, and do this.

现在打开一个终端窗口，然后执行此操作。

cd /Applications/Xcode.app/Contents/Developer/Applications
open -n iOS\ Simulator.app
open -n iOS\ Simulator.app

Update for Xcode 7:With Xcode 7 the application name of the simulator has changed, so it's this instead:

Xcode 7 更新：在 Xcode 7 中，模拟器的应用程序名称已更改，因此改为：

cd /Applications/Xcode.app/Contents/Developer/Applications
open -n Simulator.app
open -n Simulator.app

When the second one launches you'll get an error alert. Just dismiss it and select a different devicefrom “Hardware” ? “Device”. Now you have two simulators running, and whatever apps you already installed in them from Xcode will be there.

当第二个启动时，您将收到错误警报。只需关闭它并从“硬件”中选择一个不同的设备？“设备”。现在你有两个模拟器在运行，你已经从 Xcode 安装在其中的任何应用程序都将在那里。

回答by Guy Daher

Xcode 9+

Xcode 9+

Xcode 9 now supports launching multiple simulators. This was announced in WWDC 2017.

Xcode 9 现在支持启动多个模拟器。这是在 WWDC 2017 中宣布的。

Just go and change the simulator in Xcode, Cmd + Rand you will see a new simulator popping up.

只需在 Xcode 中更改模拟器，Cmd + R，您就会看到一个新的模拟器弹出。

回答by Patrick D

Successfully tested that i40west's solution works to manually launch simulator but seems silly that in this day and age, an iOS simulator requires different Xcode versions AND different device types when running concurrent tests from command line (slightly different use case but related to original question at top).

成功测试了 i40west 的解决方案可以手动启动模拟器，但似乎很愚蠢，在这个时代，从命令行运行并发测试时，iOS 模拟器需要不同的 Xcode 版本和不同的设备类型（用例略有不同，但与顶部的原始问题相关） ）。

Refer to the Apple article here which is most relevant for command line builds and tests: https://developer.apple.com/library/ios/technotes/tn2339/_index.html

请参阅此处与命令行构建和测试最相关的 Apple 文章：https: //developer.apple.com/library/ios/technotes/tn2339/_index.html

Multiple concurrent tests has worked fine for us if passing correct --args -- to 'iOS simulator.app' before running the 'xcodebuild test' command with correct '-destination' value matching simultator launch with value of UUID from output of 'xcrun simctl list', and setting DEVELOPER_DIR environment variable to select different XCode version binaries (i.e. base path to Xcode 6.1 and 6.4)

如果在运行带有正确的“-destination”值匹配模拟器启动的“xcodebuild test”命令之前将正确的--args--传递给“iOS模拟器.app”，那么多个并发测试对我们来说效果很好，来自“xcrun的输出” simctl list'，并设置 DEVELOPER_DIR 环境变量以选择不同的 XCode 版本二进制文件（即 Xcode 6.1 和 6.4 的基本路径）

Reason for needing concurrent unit tests on same physical machine and same iOS simulator device such as iPad or iPhone and same Xcode version is primarily to support CI (continuous integration) of any iOS project whereby the same build system can run more than 1 build of multiple apps (our company has 30 apps or so) at a time upon check-in on feature branches are automatically scanned and built by Bamboo agent without needing to wait for other running Builds to complete -- Bamboo supports this type of auto build on auto-discovered feature branches if enabled.

需要在同一台物理机和同一 iOS 模拟器设备（例如 iPad 或 iPhone）和同一 Xcode 版本上进行并发单元测试的原因主要是为了支持任何 iOS 项目的 CI（持续集成），从而同一构建系统可以运行多个一次签入功能分支的应用程序（我们公司有 30 个左右的应用程序）由 Bamboo 代理自动扫描和构建，无需等待其他正在运行的构建完成 -- Bamboo 支持这种类型的自动构建如果启用，发现功能分支。

As for what happens when running multiple concurrent tests, we run multiple 'xcodebuild test' commands twice in succession in different Terminal.app windows, the result is only one simulator window appears and tests fail in the simplest test.

至于运行多个并发测试时会发生什么，我们在不同的 Terminal.app 窗口中连续运行了多个 'xcodebuild test' 命令，结果是只出现一个模拟器窗口，并且在最简单的测试中测试失败。

When we complicate the entry criteria for our test launch, different Xcode versions for each sim and test launch, when using DEVELOPER_DIR as per man pages (xcodebuild test) we are specifying a different device which open in two separate windows, but the result is that any running tests in first window are interrupted by second iOS simulator window.

当我们将测试启动的进入标准复杂化时，每个 sim 和测试启动的不同 Xcode 版本，当按照手册页（xcodebuild 测试）使用 DEVELOPER_DIR 时，我们指定了在两个单独的窗口中打开的不同设备，但结果是第一个窗口中的任何运行测试都会被第二个 iOS 模拟器窗口中断。

There seems to be a common shared resource under the hood that is getting in the way, not sure it is intended or just a new feature that requires more than a few days of serious thought in how to better implement concurrent test runs wihout adverse impacts.

引擎盖下似乎有一个共同的共享资源正在妨碍它，不确定它的意图或只是一个新功能，需要几天以上的认真思考如何更好地实现并发测试运行而不会产生不利影响。

We don't want to use VMs to work around the sim restrictions as our experience and of others in general is that iOS build performance on VMs with large number of small files is slower than physical hardware. VMs generally will slow the build down by a lot due to I/O issues in the combination of VMware software and Apple hardware and/or firmware. Sorry virtuallyghetto but for us VMs don't perform well -- the virtuallyghetto site has provided us instructions on how to install ESXi 5.5 on Mac Mini's for our build farm.

我们不想使用 VM 来解决 sim 限制，因为我们的经验和其他人的经验是，iOS 在具有大量小文件的 VM 上构建性能比物理硬件慢。由于 VMware 软件和 Apple 硬件和/或固件组合中的 I/O 问题，VM 通常会大大减慢构建速度。抱歉，virtualghetto 但对我们来说，VM 性能不佳——virtualghetto 站点为我们提供了有关如何在 Mac Mini 上为我们的构建场安装 ESXi 5.5 的说明。

We have experienced the build performance issue with ESXi 5.5 on Mac Mini being slower than bare metal even with SSD by a factor of 2 or more (i.e. a 10 minute baremetal build takes 20 on VM). Refer to squareup article below on why.

我们遇到过 Mac Mini 上的 ESXi 5.5 的构建性能问题，即使使用 SSD 也比裸机慢 2 倍或更多（即，10 分钟的裸机构建在 VM 上需要 20 倍）。有关原因，请参阅下面的 squareup 文章。

https://corner.squareup.com/2015/07/ios-build-infrastructure.html

https://corner.squareup.com/2015/07/ios-build-infrastructure.html

The restriction of 1 sim device at a time for xcodebuild unit tests severely reduces productivity and exponentially adds significant costs to Apple and the ecosystem.

xcodebuild 单元测试一次只能使用 1 个 sim 设备的限制严重降低了生产力，并成倍地增加了 Apple 和生态系统的成本。

The cost to Apple of not supporting concurrency to justify more hardware purchases should be thought of carefully, weighing risks of losing developer velocity against other competitors who have less restrictions in terms of sims and EULA.

应该仔细考虑 Apple 不支持并发以证明更多硬件购买合理的成本，权衡失去开发人员速度的风险与其他在 SIM 和 EULA 方面限制较少的竞争对手。

The advantage of concurrent tests in same user login (how most ci systems work) is that quality of Apple branded app store apps which in turn is in part what makes people buy the iOS devices in the first place. Poor software quality makes the whole brand a bit more slugish and concurrency support in iOS simulators definitely seems like the smart way to go to support the ecosystem. A bit of a corollary to the issue at hand are recent improvements such as Apple's Xcode server for CI, Xcode's automated UI tests functionality in Xcode 7.

在同一用户登录中进行并发测试（大多数 ci 系统如何工作）的优势在于 Apple 品牌应用商店应用程序的质量，这反过来又是促使人们首先购买 iOS 设备的部分原因。糟糕的软件质量使整个品牌变得更加迟钝，而 iOS 模拟器中的并发支持似乎是支持生态系统的明智之举。手头问题的一个推论是最近的改进，例如 Apple 用于 CI 的 Xcode 服务器、Xcode 7 中的 Xcode 自动化 UI 测试功能。

Encouraging needless overheads to make people buy mass quantities of hardware, setup, configuration, not to mention numerous people required to support all the machines, network and power points, etc, will potentially harm Apple's profits in the end as not everyone is like Apple and able to afford racks of MacPro's or Mac Mini's just to support concurrent tests on simulators. The whole point of a simulator is to avoid using the hardware and also speeding up the tests.

鼓励不必要的开销让人们购买大量的硬件、设置、配置，更不用说支持所有机器、网络和电源点等所需的大量人员，最终可能会损害苹果的利润，因为不是每个人都像苹果一样，能够负担得起 MacPro 或 Mac Mini 的机架，只是为了支持模拟器上的并发测试。模拟器的全部意义在于避免使用硬件并加快测试速度。

Plus the EULA limitations on VMs makes the case for VMs on Mac Pro's quite weak. This hardware type would be attractive if multiple sims could run but since concurrent unit tests isn't supported (except in above two conditions - different XCode version and different simulator device) we will likely stick with Mac Mini's for build infrastructure.

加上 EULA 对 VM 的限制使得 Mac Pro 上的 VM 的情况相当薄弱。如果多个 sim 可以运行，这种硬件类型会很有吸引力，但由于不支持并发单元测试（除了上述两种情况 - 不同的 XCode 版本和不同的模拟器设备）我们可能会坚持使用 Mac Mini 来构建基础设施。

These sim and EULA limitations from Apple not only make the build pipeline slower but also add unnecessary complexity and cost. It may not be so concerning for small apps but as the apps grow in size and complexity, the build can take upwards of an hour (I heard that Facebook iOS builds can take that long). Nobody wants to wait an hour to know if a build passed.

Apple 的这些 sim 和 EULA 限制不仅使构建管道变慢，而且增加了不必要的复杂性和成本。对于小型应用程序来说可能不是那么重要，但是随着应用程序的大小和复杂性的增长，构建可能需要一个多小时（我听说 Facebook iOS 构建可能需要那么长时间）。没有人愿意等待一个小时才能知道构建是否通过。

We know of hack solutions like running ESXI VMs on Mac Minis which don't play well performance wise with OS X and xcodebuild on large projects with builds that take more than 10 minutes on a modern Mac Book Pro or Mac Mini, or different login accounts on bare metal machine to the environment just to be able to run concurrent tests on same Xcode version and same simulator device.

我们知道一些黑客解决方案，例如在 Mac Minis 上运行 ESXI VM，这些解决方案与 OS X 和 xcodebuild 在大型项目上的性能表现不佳，在现代 Mac Book Pro 或 Mac Mini 上构建需要超过 10 分钟，或不同的登录帐户在裸机到环境只是为了能够在相同的 Xcode 版本和相同的模拟器设备上运行并发测试。

ESXi is not officially supported although it works pretty well. One of the reasons VMware might not support Mac Mini hardware yet is lack of ECC memory, although Mac Pro is supported as it does have ECC memory, it likely has same issues as the Mac Mini's in terms of iOS builds slow down compared to bare metal tests on same hardware and software config (only change is VM versus bare metal running OS X). MacPro has not been tested by us at this time. In our experience VMware Fusion is quite slow in terms of performance as well.

尽管 ESXi 运行良好，但并未得到官方支持。VMware 可能不支持 Mac Mini 硬件但缺少 ECC 内存的原因之一，虽然支持 Mac Pro 因为它确实有 ECC 内存，但它可能与 Mac Mini 在 iOS 构建方面与裸机相比存在相同的问题在相同的硬件和软件配置上进行测试（唯一的变化是 VM 与运行 OS X 的裸机）。MacPro 目前尚未经过我们的测试。根据我们的经验，VMware Fusion 在性能方面也很慢。

More importantly developers will need to wait longer when aforementioned issues are compounded together unless the pool of machines is large enough to support pipleline of changes (one CI build for every 2 devs, very high ratio of machines to developer). CI build machines should be able to run more concurrent Builds and more concurrent tests than 1.

更重要的是，当上述问题复合在一起时，开发人员将需要等待更长时间，除非机器池足够大以支持更改流水线（每 2 个开发人员构建一个 CI，机器与开发人员的比率非常高）。CI 构建机器应该能够运行比 1 多的并发构建和更多的并发测试。

One of the other observations about the iOS simulators is that they seem to be a work in progress and completely unfinished even after 7 major versions. The 'xcrun simctl' subcommand has a --set option which may allow some flexibility of some kind but not sure of what possible value is valid, and same with --noxpc. Nobody should need to guess appropriate values and furthermore, there should be a man page that covers this option and and perhaps example. What are some use cases for these 2 interesting options?

关于 iOS 模拟器的其他观察结果之一是，即使在 7 个主要版本之后，它们似乎仍在进行中并且完全未完成。'xcrun simctl' 子命令有一个 --set 选项，它可能允许某种灵活性，但不确定什么可能的值是有效的，与 --noxpc 相同。没有人应该需要猜测适当的值，此外，应该有一个手册页涵盖此选项，也许还有示例。这两个有趣的选项有哪些用例？

You may say, well no app should be designed to have a large footprint that warrants concurrent test to run, and making use of better architecture based on XPC, as monolithic apps are the issue. This may very well be correct, it is not as pragmatic solution as we could hope for, and the issue remains if you have 20+ apps to build on same infrastructure.

您可能会说，任何应用程序都不应该被设计为具有保证并发测试运行的大占用空间，并且不应该使用基于 XPC 的更好的架构，因为单体应用程序是问题所在。这很可能是正确的，它不像我们希望的那样务实，如果您有 20 多个应用程序要在同一基础架构上构建，问题仍然存在。

Making a machine configuration and processes as generic and scalable as possible for higher throughput will require some work on the simulator (app + core devs). It also requires a high level of collaboration between all Apple simulator developers and the simulator product owner(s) needs to order the product backlog correctly for this issue to get any attention :-)

使机器配置和流程尽可能通用和可扩展以实现更高的吞吐量将需要在模拟器（应用程序 + 核心开发人员）上进行一些工作。它还需要所有 Apple 模拟器开发人员之间的高度协作，并且模拟器产品所有者需要正确订购产品积压以便此问题引起任何注意:-)

回答by user2067021

FBSimulatorControl from Facebook provides a programmatic way to do this. It's available at https://github.com/facebook/FBSimulatorControl.

Facebook 的 FBSimulatorControl 提供了一种编程方式来做到这一点。它可在https://github.com/facebook/FBSimulatorControl 获得。

The method testLaunchesMultipleSimulatorsConcurrentlyin FBSimulatorControlSimulatorLaunchTests.mhas sample code illustrating how to launch multiple simulators.

该方法testLaunchesMultipleSimulatorsConcurrently在FBSimulatorControlSimulatorLaunchTests.m有示出如何启动多个模拟器的示例代码。

回答by O. Boujaouane

here a little script in .sh to list UDID of simulators on your computer and run it. Copy the code below in a file with extension ".sh" and run it in terminal.

这里是 .sh 中的一个小脚本，用于列出计算机上模拟器的 UDID 并运行它。将以下代码复制到扩展名为“.sh”的文件中并在终端中运行。

How to:

如何：

Step 1. List devices with option 1 and copy the UDID wanted

步骤 1. 使用选项 1 列出设备并复制所需的 UDID

Step 2. Run option 2 and paste the UDID then press enter key

步骤 2. 运行选项 2 并粘贴 UDID，然后按 Enter 键

Be careful: verify that the path which contains your simulators is ok (if not replace by your path)

小心：验证包含您的模拟器的路径是否正常（如果没有替换为您的路径）

#!/bin/sh
PS3='Type the number of your choice (1, 2 or 3) and press Enter: '
options=("List Devices" "Run Simulator" "Quit")
select opt in "${options[@]}"
do
    case $opt in
        "List Devices")
            xcrun simctl list devices
            echo "3[1m\n\nCopy the UDID in parentheses of the device which you want run and launch option 2 (Run Simulator)3[0m"
            ;;
        "Run Simulator")
            read -p 'Type device UDID which you want launch: ' currentDeviceUDID
            open -n /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app/ --args -CurrentDeviceUDID $currentDeviceUDID
            ;;
        "Quit")
            break
            ;;
        *) echo invalid option;;
    esac
done

Thank you,

谢谢，

回答by Oguz Demir

You can run multiple instances of simulator for different hardware profiles and debug them. First, you need to run your app from XCode for each hardware type (iPhone 6, iPad etc.) to install it into simulator instances. Then run simulator instances and your app as it is explained above. To debug it, you can attach debugger to running processes from "XCode->Debug->Attach to Process" menu. You can check this blog entry for an example :http://oguzdemir.dualware.com/?p=43

您可以针对不同的硬件配置文件运行多个模拟器实例并对其进行调试。首先，您需要针对每种硬件类型（iPhone 6、iPad 等）从 XCode 运行您的应用程序，以将其安装到模拟器实例中。然后按照上面的说明运行模拟器实例和您的应用程序。要调试它，您可以从“XCode->Debug->Attach to Process”菜单将调试器附加到正在运行的进程。您可以查看此博客条目以获取示例：http: //oguzdemir.dualware.com/?p=43

回答by vvolkov

This is 2020, xCode 11.4: File -> Open Device -> iOs 13.4 -> and choose iPhone version which was not running first and you will get second emulator running.

这是 2020 年，xCode 11.4：文件 -> 打开设备 -> iOs 13.4 -> 并选择未首先运行的 iPhone 版本，您将运行第二个模拟器。