Ios Simulator Without Xcode

Run Ios Simulator Without Xcode
Ios Simulator Without Xcode Key

Xcode provides a fully-featured, scriptable UI Testing framework. A key to using the framework is understanding its architecture and how to best leverage its capabilities.

When you create a new project in Xcode, the new project wizard asks if you’d like to Include Unit Tests, and whether you’d like to Include UI Tests.

Now with new Xcode if the icon of the Xcode is on dock you can just right click it and form the menu you can select Open Developer Tool and in the sub menu you can select the iOS Simulator to open the simulator without opening the Xcode.! In this article, I collected several options on how to launch the simulator from the Terminal, folder, search, and Xcode. Choose which option you like more and use. The basic way to open a list of. After you create a project, you can build and run your app on a simulated or real device without needing to lay out the user interface or write code. You may connect a real device to your Mac using a cable, or for iOS or tvOS apps, connect it over WiFi after you pair it with Xcode. The simulator is not only for the apps themselves, it’s also for testing how your app is preforming on an iOS device. But, I can think up use cases where it’d be handy for it to just run without the simulator as well. Which is why I’m curious. How to Run iOS app in Real iPhone/iPad without a Developer Account. If you get any error please check your iPhone/iPad settings following Xcode Error Message.

One might wonder — is a UI Test not a Unit test? If not, then what is it?

Actually, these checkboxes and their outcomes are primarily there to inform Xcode which targets to create within your project. Each checkbox, when checked, generates a different type of test target in your project.

The fundamental differences between an Xcode Unit Test and an Xcode UI Test:

Unit Tests are used to test that source code generates expected results. For example: ensuring that a function, when passed a specific parameter, generates some expected result.
UI Tests test that a user interface behaves in an expected way. For example: a UI Test might programmatically tap on a button which should segue to a new screen, and then programmatically inspect whether the expected screen did load, and contains the expected content.

Both Unit Tests and UI Tests support full automation, and enable regression testing of applications over their lifecycle.

Generally speaking, an Xcode Unit Test exercises and evaluates your Swift code, but does not inspect the impact is has on the User Interface, while an Xcode UI Test evaluates the UI behavior in response to actions, but does notinspect your code.

As always, these are generalized statements that have exceptions. It is certainly possible to get some insight into the UI from a (code) Unit Test, and to get some insight into the state of your code objects from a UI Test. But the tools are designed to be used according to this generalized statement.

Before examining the architecture and implementation of UI Test, let’s take a look at a finished test in operation. The user story for this test is as follows:

On the first screen, the user can select a cell within a table view, which opens a second form showing the selected value in a label. The user can then key in a new value, in a text box beneath the original label. When the user subsequently returns to the first form, the new value will be shown in the Table View.

If a QA tester were to manually check this process they would do the following sequence:

Launch the app
Tap on a row
Observe the table view row text is on the second form when it loads
Type in a new value in the text field
Press the back button
Observe the value they typed has replaced the original text in the table view

The manual testing process would look as follows (this is an animated .gif — if using the Medium app, you may need to open this page in a browser to view the animation).

Wouldn’t it be nice if we could automate this process so our QA tester didn’t have to repeat this process manually before every release? That’s exactly what UI Testing is for — and we’ll walk through how to automate this test process!

Before digging into the code, it’s important to understand how the Xcode UI Test framework operates. By understanding how the UI Tests access and manipulates your UI components, you’ll be able to make your UI easy to build tests for.

As with Unit Tests (the ones that exercise your source code), XCode uses XCTest to run your UI Tests. But how does the XCTest code know how to inspect and manipulate the UI that you designed in Storyboards and/or Swift code?

To gain access to your UI at runtime, XCTest uses metadata exposed by iOS Accessibility. This is the same technology used to enable iOS to read your screen to blind and low vision users, for example. At runtime, XCTest iterates over your UI controls, looking for Accessibility properties such as accessibilityIdentifier and accessibilityLabel to find the UI components you’d like XCTest to tap on, change or inspect as part of your UI Test.

While it’s possible to design UI Tests without doing any preparation of Accessibility metadata in your app — and you’ll find many examples on the Internet that do this — you can maintain better control and predictability in UI Tests by planning for UI Tests in advance, and preparing Accessibility metadata in the UI. Similarly, if you’re retrofitting UI Tests to an existing application, you should consider retrofitting Accessibility metadata as part of the process.

Xcode’s UI Test suite provides an easy way to get started implementing a UI Test: the Record UI Test button.

To begin recording a UI Test:

Create a new UI Test function in the UI Test target source .swift file (assuming you created a UI Test target when you created your project — or added it later)
Place the editing cursor within the empty test function
Press the Record UI Test button below the source code editing pane

Xcode will compile and run the application using the debug device (i.e. simulator). Then, just walk through the test sequence on the simulator (or other debug device). When you’re finished, stop the debug session. Xcode will have created a set of commands to re-create the UI experience during the recording. In the case of the test sequence outlined above, the following code would be generated:

Great! Xcode has generated all the command needed to re-run the same UI Test process we did by hand. This is a boon to our test design productivity, and gives us a great start. But it’s not perfect, and not a production ready test yet. There are some deficiencies:

There are some messy aspects, such as the line let app2 = app. We wouldn’t have written the code this way ourselves — the app object created at line 1 obviously can be used throughout the test function.
The reference to staticTexts[“Fourth Row”] in line 2 of the function assumes that the contents of the UITableView cells will always be the same. What if it won’t? This is a case where preparing the Accessibility metadata can help make a more robust test. I’ll cover this shortly.
The auto-generated code causes the test to operate, but nothing here is evaluating whether the outcomes of the test were successful or not. Xcode can’t create this part of the test — we have to do this ourselves.

In Line 2 of the auto-generated code, Xcode inserted this line:

In english, this command means:

Within the array ofUITableView objects within the current UIView, find a UITable with the key MyTable. Then, search all the UILabel controls within that UITable and find a UILabel having a text value “Fourth Row”. Then tap on that UILabel.

There are two key references XCTest uses to find UI elements here:

The “Fourth Row”UILabel — the UILabel text value displayed on the 4th UITableViewCell in the UITable
The UITableView with a key of “MyTable” — huh? Where did that key come from?

Let’s consider the second item. In this case, I had previously assigned the text “MyTable” as the accessibilityIdentifier for the UITable on the first UIView. This was done in the viewDidLoad() function of that UIView’sUIViewController, like so:

Every UIView can have an accessibilityIdentifier, as well as other Accessibility properties. For the purposes of UI Testing, you’ll be most interested in accessibilityIdentifier and accessibiltyLabel.

When a UIView has either an accessibilityIdentifier or an accessibilityLabel, it can be queried within a UI Test by using that string as a key. For example, this table could be accessed within a UI Test in either of these ways:

By using Accessibility metadata in this way, you can create a more robust UI Test — one not dependent on the content of the text in controls. Instead, the controls can be accessed by dictionary key values you define and control. But you do need to make the effort to assign keys in order to use them!

Note: while UIView objects can be queried using either accessibilityIdentifier or accessibilityLabel, it’s usually better to use accessibiltyIdentifier. accessibilityLabel is the property iOS Accessibility uses to access the text to be read to a blind or low vision user, and could change at runtime for controls that have updatable text properties.

Setting the accessibilityIdentifier for a UIView-based object can be done in several ways. The most common are as follows:

Using the Interface Builder Identity Inspector

Some UI elements support setting of Accessibility properties within IB Identity Inspector. For example, the UILabel on the first form of our test solution has its accessibilityIdentifier set to “labelIdentifier” directly within the predefined IB field.

Using a User-Defined Runtime Attribute

For UI elements that wouldn’t normally be read to a blind or low vision end-user, Interface Builder won’t have predefined Accessibility property fields. But you can still add them at Interface Builder design time using the User Defined Runtime Attributes dictionary editor on the Identity Inspector.

In this case, I’ve moved the UITableView’s accessibilityIdentifier from the UIViewController’s viewDidLoad() method into the Interface Builder storyboard editor. The resulting UI Test works exactly the same way — but with less code to maintain.

Using Code

As mentioned earlier, every UIView-based class has accessibility properties, and those properties can be set at runtime.

All three of these methods have the same effect . Which is best depends on best practices within your team. Some prefer to reduce code by configuring UI in Interface Builder, others prefer to do all UI design in code. UI Testing supports both scenarios equally well.

Recall earlier that I recorded the steps for the test — but I didn’t actually test for anything! Let’s wrap this job up by adding the actual tests, and use accessibilityIdentifier properties where possible.

Searching for UIView elements

Recall that Xcode wrote the following statement to find the UITableView using its accessibilityIdentifier.

This is the most concise shorthand method, but I want to point out there’s more than one right answer to finding the tableView in the view hierarchy.

Another method is to explicitly search for the accessibilityIdentifier:

If we hadn’t assigned an accessibilityIdentifier, we could use this code to get the first UITableView within the top-level UIView.

This isn’t as good, because if we should ever add a second UITableView to the screen, the UI Test may break if a new UITableView happens to be retrieved as the first UITableView! This is the reason I suggest using accessibilityIdentifiers when designing your UI Tests.

If we knew there were one and only one UITableView on the screen, we could shorten the previous technique even more:

Again, this has the risk of breaking the UI Test if a second UITableView is added. This would be a more serious break, since the tables property would return a collection rather than a single table as it does when only one UITableView is in the view hierarchy.

We’ve covered the fundamentals of creating tests, accessing elements, and manipulating values (which Xcode showed us during the test recording), so we’re ready to wrap this up.

I’ve pasted below the final test function, and then annotated it below.

In lines 2–4, we find the UITableView with the accessibilityIdentifier“MyTable”, and then check that the number of rows is five (5). Remember that whenever an XCTAssert fails, the entire test fails.
On line 6, we search the UITableView for a UITableViewCell with an accessibilityIdentifier equal to “3”. This value was set in the cellForRowAt method in the UITableViewDataSource delegate (review the code from GitHub for details)
On line 7, we get the first UILabel within the cell (this cell has only one label).
One line 8, the UILabel text property is checked against an expected value (this is not really a requirement for this test, but I added it as a further example).
Line 10 sends a tap event to the UILabel within the cell. The effect of this is to generate a tap event on the cell, which then triggers a segue to the detail form (see source on GitHub for details)
Line 14 finds the UILabel with accessibilityIdentifier“labelIdentifier” (we set this in Interface Builder earlier. When the form is loaded, it should have set the UILabel text to the value tapped in the UITableView. This XCAssetEqual check to make sure this was done.
Lines 16–20 tap on the UITextField, and type in new text.
Line 22 taps the Back button at the top-left of the detail form, which pops the view controller off the stack, returning to the first form.
Lines 26–30 again retrieve the value in the 4th cell, and compare the new value to the value that was typed on the detail form.

Note: when creating tests that type into fields using an iOS simulator, be sure to disconnect the hardware keyboard in the simulator. The typeText method will fail when a hardware keyboard is attached to the simulator.

With this, we’ve completed a completed, robust UI Test for this part of the application!

Since we used accessibilityIdentifier properties wherever possible, we’ve created a test that won’t easily break when the UI is enhanced with new controls, and the test is repeatable, automate-able, and easy to use for regression testing.

But this test can be improved even more:

We still have a few static data values in the test, e.g. “Fourth Row”. By refactoring all static value assumptions out of this test, we could set it up to work with dynamic data (for example, against a web service call)
This test is still bound to a developer or QA Engineer using Xcode at their desk. But with some additional work, we could incorporate this type of test into a fully automated test suite run by a daemon instead.

Important:The information in this document is deprecated in Xcode 9. For Xcode 9 and later, see Simulator Help by choosing Help > Simulator Help in Simulator.

Simulator app, available within Xcode, presents the iPhone, iPad, or Apple Watch user interface in a window on your Mac computer. You interact with Simulator by using the keyboard and the mouse to emulate taps, device rotation, and other user actions.

The chapter presents the basics of using Simulator. You can perform these steps using your own iOS app or, if you do not have an app to use, with the HelloWorld sample code. For more detailed information on interacting with Simulator and using it to test and debug your apps, refer to the later chapters in this guide.

Access Simulator from Xcode

There are two different ways to access Simulator through Xcode. The first way is to run your app in Simulator, and the second way is to launch Simulator without running an app.

Running Your iOS App

When testing an app in Simulator, it is easiest to launch and run your app in Simulator directly from your Xcode project. To run your app in Simulator, choose an iOS simulator—for example, iPhone 6 Plus, iPad Air, or iPhone 6 + Apple Watch - 38mm—from the Xcode scheme pop-up menu, and click Run. Xcode builds your project and then launches the most recent version of your app running in Simulator on your Mac screen, as shown in Figure 1-1.

Note: If you are testing an app with a deployment target of iPad, you can test only on a simulated iPad. If you are testing an app with a deployment target of iPhone or universal, you can test on either a simulated iPhone or a simulated iPad.

Running Your watchOS App

To run your WatckKit app, choose a combination of an iOS device and watchOS device from the Xcode scheme pop-up menu. For example, to run the watch app in a 38mm watch paired with an iPhone 6, choose 'iPhone 6 + Apple Watch - 38mm' from the scheme pop-up menu.

Running the WatchKit target launches two simulators, one for the iOS device and one for the watchOS device. Figure 1-2 shows an iPhone 6 and a 42mm watch running in two different simulators.

Running Your tvOS App

To run your tvOS App, choose a tvOS device from the Xcode scheme pop-up menu. Running the tvOS target launches the most recent version of your app in a simulated new Apple TV device, as shown in Figure 1-3.

Launching Simulator Without Running an App

At times, you may want to launch Simulator without running an app. This approach is helpful if you want to test how your app launches from the Home screen of a device or if you want to test a web app in Safari on a simulated iOS device.

To launch a Simulator without running an app

Launch Xcode.
Do one of the following:
- Choose Xcode > Open Developer Tool > Simulator.
- Control-click the Xcode icon in the Dock, and from the shortcut menu, choose Open Developer Tool > Simulator.

To launch a watchOS Simulator without running an app

Launch Xcode.
Do one of the following:
- Choose Xcode > Open Developer Tool > Simulator (watchOS).
- Control-click the Xcode icon in the Dock, and from the shortcut menu, choose Open Developer Tool > Simulator (watchOS).

Simulator opens and displays the Home screen of whichever simulated device was last used.

View the Installed Apps

From the Home screen, you have access to all of the apps that are installed in the simulation environment. There are two ways to access the Home screen in Simulator from your app:

Press Command-Shift-H.
Choose Hardware > Home.

Use the installed apps to test your app’s interaction with them. For example, if you are testing a game, you can use Simulator to ensure that the game is using Game Center correctly.

iOS Device Home Screen

Much like the Home screen on an iOS device, the simulator’s iOS Home screen has multiple pages. After clicking the Home button (or accessing the Home screen through the Hardware menu), you arrive at the second page of the Home screen. To get to the first page, where all of the preinstalled apps are found, swipe to the first Home screen by dragging to the right on the simulator screen.

On the Home screen, you see that all of the apps that have been preloaded into Simulator. See iOS Device Home Screen.

The apps that you see on the Home screen are specific to the iOS device simulation environment. Because Passbook and the Health app are available only for the iPhone, these apps don’t appear if you are simulating a legacy device or an unsupported device type.

watchOS Device Home Screen

The Home screen for a simulated watchOS device behaves the same as it would on an actual device. You can click and drag to simulate the finger dragging around the screen and launch an app by clicking on it. Figure 1-4 shows the home screen of a 42mm watch with a developer app, the Lister sample code.

Use Safari to Test Web Apps

From the Home screen, you can access Safari within Simulator. Use Safari to test your iOS web apps directly on your Mac.

From the Home screen, click Safari.
In the address field in Safari, type the URL of your web app and press the Return key.

If your Mac is connected to the Internet, it displays the mobile version of the URL you specified. For example, type apple.com into the address field and press Return. Safari displays the Apple website. See Figure 1-6.

Use Maps to Simulate Location Awareness

Simulator provides tools to assist you in debugging your apps. One of the many features you can debug in Simulator is location awareness within your app. Set a location by choosing Debug > Location > location of choice. The menu has items to simulate a static location or following a route.

A simulated watchOS device with the location set to None checks the paired iPhone device for the location.

You can specify your own location, which can be seen in the Maps app.

From the Home screen, click Maps.
Choose Debug > Location > Custom Location.
In the window that appears, type the number 40.75 in the latitude field and the number -73.75 in the longitude field.
Click OK.
Click the Current Location button in the bottom-left corner of the simulated device screen.

After completing this task, notice that the blue dot representing your location is in New York, NY, near the Long Island Expressway, as shown in Figure 1-7.

Change the Simulated Device and OS Version

Simulator provides the ability to simulate many different combinations of device type and OS version. A device type is a model of iPhone, iPad, or Apple TV. Some iPhone devices can also have a paired Apple Watch. Each device-OS combination has its own simulation environment with its own settings and apps. Simulator provides simulators for common device-iOS, device-watchOS-iOS device, and device-tvOS combinations. You can also add simulators for a specific combination you want to test. However, not all device type and OS version combinations are available.

Note: To test apps for the iPad mini, use a simulated iPad with the same pixel resolution as the iPad mini.

You can switch between different device-OS combinations. Switching closes the window for the existing device and then opens a new window with the selected device. The existing device goes through a normal OS shutdown sequence, though the timeout might be longer than the one on a real device. The new device goes through a normal OS startup sequence.

To change the simulated device

Choose a Hardware > Device > device of choice.
Simulator closes the active device window and opens a new window with the selected device.

If the device type and OS version combination you want to use is not in the Device submenu, create a simulator for it.

To add a simulator

Choose Hardware > Device > Manage Devices.
Xcode opens the Devices window.
At the bottom of the left column, click the Add button (+).
In the dialog that appears, enter a name in the Simulator Name text field and choose the device from the Device Type pop-up menu.
Choose the OS version from the iOS Version pop-up menu.
Alternatively, if the iOS version you want to use isn’t in the iOS Version pop-up menu, choose “Download more simulators” and follow the steps to download a simulator.
Click Create.

If the OS version you want to use is not installed, download it and follow the steps to add a simulator again.

To download a simulator

In Xcode, choose Xcode > Preferences.
In the Preferences window, click Downloads.
In Components, find the legacy simulator version you want to add, and click the Install button.

You can also delete and rename simulators in the Devices window.

To delete a simulator

In Simulator, choose Hardware > Device > Manage Devices, or in Xcode, choose Window > Devices.
Xcode opens the Devices window.
In the left column, select the simulator.
At the bottom of the left column, click the Action button (the gear next to the Add button).
Choose Delete from the Action menu.
In the dialog that appears, click Delete.

To rename a simulator, choose Rename from the Action menu and enter a new name.

For how to manage real devices that appear in the Devices window, read Devices Window Help.

Alter the Settings of the Simulated Device

You can alter the settings within Simulator to help test your app.

On a simulated device, use the Settings app. To open the Settings app, go to the Home screen and click or on tvOS, choose Settings. In Figure 1-8 you see the Settings app as it appears when launched in the iOS simulation environment.

The Simulator settings differ from the settings found on a hardware device. Simulator is designed for testing your apps, whereas a hardware device is designed for use. Because Simulator is designed for testing apps, its settings are naturally focused on testing, too. For example, in a simulated iOS device the Accessibility menu provides the ability to turn on the Accessibility Inspector, and the Accessibility menu on a device allows you to turn on and off different accessibility features.

Through the settings, you can test both accessibility and localization of your app. See Testing and Debugging in iOS Simulator for information on how to manipulate your settings for the various types of testing you are interested in.

Remember: Changes made in the Settings app of simulated device affect only the simulation environment that is currently running.

Rotate iOS Devices

You can use Simulator to manipulate the simulated device much as you do a physical device.

To rotate your simulated device, choose Hardware > Rotate Left. When you rotate your simulated device, Settings rotates (see Figure 1-9), just as it would on a hardware device.

Test in Simulator and on a Device

Simulator is designed to assist you in designing, rapidly prototyping, and testing your app, but it should never serve as your sole platform for testing. One reason is that not all apps are available in the simulator. For example, the Camera app is available only on hardware devices and cannot be replicated in the simulator.

In addition, not all bugs and performance problems can be caught through testing in Simulator alone. You’ll learn more about performance differences in Testing and Debugging in iOS Simulator. You can also find more information on testing your app on a device in Launching Your App on Devices in App Distribution Guide.

Quit Simulator

Simulator continues running until you quit it. Quitting Xcode will not close Simulator because they are separate applications. Similarly quitting simulator will not close Xcode.

To quit Simulator, choose Simulator > Quit Simulator. The device is shut down, terminating any running apps.

Note: Both Simulator and watchOS Simulator can be open at the same time.