02/03/2015 | Digital Experience and Mobile
The iOS Simulator is a tool to help developers rapidly prototype and test an app by simulating several versions of the iOS operating system simultaneously on multiple iOS devices. It’s part of the Xcode tools and can be used prior to actually testing an app on a desired device.
So if you are at least familiar with installing and using Xcode, here are a few pointers for how to more effectively use the iOS Simulator tool:
Toggle In-Call Status Bar
It’s useful to know how an app’s user interface will look when it’s launched during a call. Select the Hardware menu, then select Toggle In-Call Status Bar. This toggles the status bar between its normal state and when a phone call or FaceTime call is in progress. The status bar will look taller during a call.
Toggle Slow Animations
Want to know if there are any animation glitches in your app? For example, what if you notice something strange when you rotate the device? Select the Debug menu, then select Toggle Slow Animations. This slows down the UI so that you can more easily observe UI animations and determine whether or not there is a problem.
QuickTime Player
Yes, you can use QuickTime to record iOS Simulator interactions. This is especially useful when used in conjunction with Slow Animations. The easiest way to record the simulator is to launch QuickTime Player, select File, then New Screen Recording. Once the recorder is visible, click the red Record button, then select the section of screen you want to record and click Start Recording. Once done, attach it to a bug.
Location
In iOS 5 and above. the simulator supports location simulation. Simply choose the Debug menu, then Location, then Custom Location. The easiest way to find a desired location is to use http://maps.google.com and search for a place (such as Fresno, CA) in your browser. When the map pin is displayed, right-click the map pin and choose What’s Here? You’ll notice that the search text changes from “Fresno, CA” to “36.758141,-119.771576.” Copy/paste the latitude/longitude into the Custom Location latitude/longitude.
Simulate Memory Warnings
Before outlining how to simulate low-memory warnings, let’s discuss how iOS memory management works.
Each object a user sees, such as a button, needs memory. Objects that aren’t seen need memory as well, such as a list of items in a table. Each iOS app is responsible for allocating and releasing the memory it uses when it is no longer needed. It’s easy for developers to forget to release memory, but there are some easy ways to expose problems.
If a user has a lot of applications open on a phone or if an app is using a lot of memory, iOS intervenes. It tells the open applications to voluntarily give up memory. To the app, this is a memory warning, which can be seen in the debugger. The app is supposed to respond to the memory warning by giving up whatever memory it can and still remain functional.
If an app doesn’t give up enough memory OR an app uses too much memory too fast, iOS will kill the app without warning. Sometimes during testing, this is why the app will quit and yet nothing appears in the debugger.
On an iOS device, each screen of information is a “view” and each view is responsible for managing its own memory. If an app uses a Navigation Controller (the area at the top with a title and a back button), each view that the user navigates to is “pushed” onto the navigation controller stack. So, in a shopping app, if a user searches for “socks” and a list of socks is displayed, that’s +1 view controllers. Tap a sock icon and, if it details view displays, that’s +2 view controllers. And if the details view has a list of related products and one of those is selected, that’s now +3 view controllers, etc.
The time to test whether the app handles memory warnings properly is when you’re several views deep into a navigation controller stack. Select the Hardware menu, then select Simulate Memory Warning. The application should now release some memory from the current and previous view controllers using the navigation controller. If the app’s memory management is properly configured, the current view should not appear differently to the user and, if you go back (“pop”) to the previous view controllers in the navigation controller stack, each of those views should load properly. The app should not crash.
It’s also necessary to run this test on a device. Since almost every app uses a common custom framework generating a memory warning when it runs in debug mode, just shake the device until a memory warning is received.
Using the Static Analyzer
A static analyzer examines code syntax for bugs and determines whether or not objects are properly allocated and released. To run the static analyzer, select the project you want to analyze in the project navigator and then choose Product > Analyze. When the analyzer finishes, the issue navigator automatically opens with a list of problems found. Then click an issue in the issue navigator to open the file in question. The problem is labeled in a blue rectangle marked with an arrow. Click the blue rectangle to see the faulty logic flow.
You can open the analysis pop-up menu () on the left to see all found issues, or cycle through them by clicking the arrows at the right end of the analysis results bar. You can open an issues pop-up menu showing the various files in which problems were found by clicking the issues button at the right end of the jump bar, or cycle through the issues by clicking the arrows that bracket the issues button.
These are just a few possibilities. There are many other tips and tricks for using the iOS Simulator, and good reasons for using it earlier rather than later.
