Posts Tagged ‘Xcode’
Multiple iOS Simulator Support in Xcode 9
Xcode 9 was announced at WWDC17 earlier this year. I think it is probably one of the best Xcode releases to date, with a plethora of new features including a markdown editor which I am using for writing this post and considerably less buggy than it’s predecessors! One of the features that got me very excited was the ability to run multiple iOS simulators at the same time ! Finally …Now you can simulatneously test the app on different iOS versions and devices at the same time. The only limitation to the number of simulators you can run in parallel is the (memory/CPU) resources on your Mac. You would launch the app as usual by selecting the simulator as shown below 
If you want to run the app simulatneously on another simulator, you would go about that as shown below. 
That’s it!
Xcode and Zombie Processes
The Problem…
If you have been using Xcode (the latest version as of writing this post is Xcode 4.6.2 ) for an extended period of time, testing your app on the iOS simulator, you may eventually encounter a “Resource temporarily Unavailable” build error . There are no build errors associated with your source code but the system is unable to successfully build your app and launch the simulator to run it . You would observe something like this in your build output.
So what’s going on?
The reason this occurs is because every time you launch the iOS simulator through Xcode to run your app and then quit /stop running the app, Xcode leaves behind a Zombie process. If you are not familiar with Zombie processes in Unix, essentially, it is a process that has completed execution but whose entry remains in the process table. It is the responsibility of the parent process to eventually clear these processes. The zombies don’t use any of the computer resources so you won’t observe a depletion of resources , but the problem is that in this “undead” state, they hold on the PID or Process Identifier. The implication of this is that eventually, your system will run out of PIDs to assign to new processes, thereby resulting in a failure to spawn or launch a new process.
You can confirm this behavior by running your iOS app through Xcode a few times and then running the “ps” command on the terminal window. You will observe a bunch of zombie processes listed for your app. The “Z” in the “S” (or “STAT” ) column indicates that “symbolic state” of the process is a “Zombie“.
|
1 |
Priya-Mac-01:$ ps -aelf</code> <code>UID PID PPID F CPU PRI NI SZ RSS WCHAN S ADDR TTY TIME CMD STIME</code> <code>…….</code> <code> 501 928 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) Fri11AM</code> <code> 501 1072 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) Fri11AM</code> <code> 501 9473 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) Fri05PM</code> <code> 501 11380 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) Mon09AM</code> <code> 501 11599 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) Mon09AM</code> <code> 501 11614 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) 19Jun13</code> <code> 501 11758 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) 19Jun13</code> <code> 501 12412 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) 19Jun13</code> <code> 501 12564 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) 19Jun13</code> <code> 501 13245 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) 19Jun13</code> <code> 501 13407 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) Mon11AM</code> <code> 501 13590 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) 19Jun13</code> <code> 501 13725 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) 19Jun13</code> <code> 501 14545 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) Mon12PM</code> <code> 501 14646 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) Mon12PM</code> <code> 501 14761 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) Mon12PM</code> <code> 501 14835 233 6000 0 0 0 0 0 - Z 0 ?? 0:00.00 (MyApp) Mon12PM</code> <code>-------- |
|
1 2 3 |
Priya-Mac-01:$ ps -aelf | grep "MyApp"|wc -l 272 |
In my case, there were 272 zombie processes associated with my app that Xcode didn’t reclaim. So in case of the Xcode, you will eventually notice that you are no longer able to build the app and launch the simulator to run it. In fact, you probably won’t be able to launch any new application. Yep- not a good place to be.
So what are your options?
Reboot:
The simplest and safest method is to reboot your system. This will get rid of the zombie processes
Re-initializing/Killing the Parent Process:
Generally , killing the parent process corresponding to the Zombie processes should take care of it but unfortunately, in the case of Xcode, the parent process is the system launchd process. The launchd is a core system process that handles the launching of many of the other processes. Issuing a “kill” command to the launchd process can result in undesirable results and can even make your system unresponsive. So DO NOT kill the launchd process. You could try to re-initialize the process using the kill with HUP (“Hang Up”) option but you are probably better off rebooting your Mac.
If you are curious, you can follow the steps below to determine the parent process of the Zombie Xcode process
1) You can identify the PID (“ppid”) of the parent process corresponding to the zombie process using the command
|
1 |
Priya-Mac-01:$ps -p <PID of MyApp Zombie Process> -O ppid |
This will output the ppid of the parent process corresponding to the Zombie process,
2) You can get details of the parent process using the following command
|
1 2 3 4 5 |
Priya-Mac-01:ps -p <PID of Parent Process> PID TTY TIME CMD 236 ?? 0:00.75 /sbin/launchd |
The output of the above command indicates that the launchd process is parent process.
You can find more details on Zombie processes at you can check out the details in http://en.wikipedia.org/wiki/Zombie_process.
If you are interested in developing software (apps, tweaks) for a jailbroken iOS device, then check out my presentation on Developing For Jailbroken iOS platform that I gave at a recent CocoaHeads meeting. This should be a good starting point. The presentation discusses the pros and cons of developing for a jailbroken phone, the various development tools (XCode, Theos) and frameworks (Mobile Substrate) that are available for building applications / run-time patches as well as other relevant information on jailbroken phones (SHSH blobs, jailbreak software etc).
I own an Apple Developer's License and build Apple certified apps for the App Store. I pursue this as a hobby. So hopefully the presentation will get you started.
Handling ToDo(s) and FixMe(s) in your code…
No comments
As an iOS developer (or any developer for that matter), it is not uncommon (or dare I say- its “very common”) for us to defer things while coding so as to not disrupt the current coding flow. For instance, handling of a special case or updating an algorithm with a more efficient one or just a reminder to double check a certain logic . To remind ourselves, we typically include a comment like “ToDo: Handle error code -1020” in our code.
Now, before we realize it, we have several “ToDos” and “FixMe” scattered throughout our project and unfortunately, many of them go unattended . Note that “attending” to them may be as simple as removing the comment because we have in fact handled the “To Do” but have just forgotten to remove the now obsolete comment which leads to clutter and confusing code.
So here is a neat little perl script that I found (and tweaked a wee bit for my purpose) that solves the problem. The script is executed every time my project is built. The purpose of script is simple. The script greps for keywords in all the .h and .m files in the ${SRCROOT} folder and prefixes it with a “warning” label.
Now, every time, I compile my project, the script runs and displays all statements that begin with keywords listed in the KEYWORDS reg expression show up as warnings. They are now hard to miss and I can ensure that all the “To Do”s are handled in a timely manner.
Then , cut and paste the script to the “Run Script” section
Now, when you build your app, you should see all comments that include the keywords mentioned in the script listed as warnings.