Running multiple instances of iOS Simulator and debugging them.

Running multiple instances…

Running multiple instances of “iOS Simulator” is usually very helpful for testing your applications with different user credentials. By default, it is not allowed to run a second (or more) instance from XCode. However, as you can easily find on the net, it is possible to do it using Terminal. You can simply change directory into package and run simulator with “open” command. Here is an example from stackoverflow

There are couple of tricks. First of all, you need to install your application into simulator by running it from XCode and you should do it for every iOS version and platform separately. Also you can not run multiple simulator instances for same hardware type. So, right after seeing the error message “Unable to boot device in current state: Booted”, change device hardware type from

This is good enough for many of the cases. We can test the app on different simulator instances like two different users. But what if we want to debug the application if we see a problem.


We can use XCode’s “Debug” menu to attach debugger to running simulator application processes.

Let’s launch the XCode and open your development project. For each simulator hardware type; you should have run your app inside XCode at least for once. Otherwise you wouldn’t see your app inside your simulator.

I ran same application on two different iOS Simulator instances (iPhone5 and iPhone6) for this example. Here is what you will( or should) see when you go to “XCode->Debug->Attach to Process” menu, as the applications were running simultaneously. XCode is somehow (probably using process names) creating a new group under menu which is named “Likely Targets”. As you can see we have two running instance of our applications with different process id’s.

Screen Shot 2015-04-17 at 10.55.41 PM

We can connect to these instances by selecting them on the menu. You will find that all XCode debugging functionality(breakpoints, thread view, memory info, cpu info, lldb commands etc.) will be working without any problem. Again, you can connect to all of the running instances at the same time. XCode will beautiful display them under “Debugger navigator”

The only problem is that finding correct process id of your app for being sure to debug correct instance. The window title of the simulator is not helpful at this time and we don’t have any clue about the running instances under XCode “Debug” menu.

I can recommend couple of things to identify your process at this point.

Let’s say you have two running simulators with iPhone 5 and iPhone 6 respectively and you want to debug iPhone 5. Add a breakpoint at somewhere in your code that you can easily test (like viewDidLoad event for a known view controller). If your simulator stops when you launch this screen then it means you are debugging correct process. Otherwise, alternate other instances until you find it.

The other method would be trying to find the process id. To do that, go to your simulator window, that you want to debug, and activate it. Kill the iOS application if it is already running. Turn back to XCode and check “XCode->Debug->Attach to Process” menu. Run the application in the simulator that you want to debug and re-check “XCode->Debug->Attach to Process” menu. The newcomer item under “Likely Targets” is your application.

Hope it helps!


Discovering Gimbal using Core Location Services.


Gimbal bluetooth low energy devices by default configured with Series 10 Recommended configuration and in that mode, they are not discoverable with Core Location Services Framework functionality. Fortunately Gimbal proximity configuration allows you to change behaviour of the Gimbal device and makes it suitable to work with CL framework.

Add new configuration for your devices
To do that; first of all you need to create an account for Gimbal ( When you create your account login to manager system and select “Proximity” on left side menu. At top of the page, press “Manage Configurations” button to create a new configuration. Give a name to your configuration and select “iBeacon” from the Beacon type combo box. When you change the beacon type you will see new extra fields for defining configuration.

“Proximity UUID” will be your key to search this iBeacon device. You can generate a UUID using different tools. Enter this value and define “Major”-“Minor” numbers for the device. Please note that, this values can be use to distinguish iBeacons, which share same UUID, from each other. Save your configuration.

Activate your Gimbal device.
Gently open the Gimbal device. Right up to the battery, you will see a small sticker (For Series 10 Devices) which contains device factory id.

Screen Shot 2014-05-16 at 4.58.59 PM

Now you can go to “Beacons” page on the menu and activate your Gimbal. Enter name, factory id and other required information. At this step you can’t change Gimbal configuration but you can change it after activating the device. Activate your beacon using “Activate Beacon” action. On the list page, find little pen icon to edit your device’s definitions. Now you should be able to see “Assigned Configuration” combo box which contains your configurations.

Screen Shot 2014-05-16 at 5.05.06 PM


Update your device and now you are done on configuration side.

Create a new Xcode project
Create a new Xcode project and add CoreLocation services framework “Linked Binary Library”. In your code implementation;

Now, by implementing CLLocationManagerDelegate, you can listen beacon region enter/exit events.