icloudiosios-simulator
I am trying to test the iCloud sync functionality of my app between a (real) device and the simulator, however I can't seem to log into iCloud. When I go to Settings->iCloud and enter my account details, it just gets stuck on 'Verifying'. However if I enter incorrect details, it brings up the invalid password prompt as expected.
Has anyone got a fix for this?
status: this has been seen as recently as Mac OS 10.8 and Xcode 4.4.
tl;dr: This can occur in two contexts: when running on the device and when running on the simulator. When running on the device, disconnecting and reconnecting the device seems to fix things.
launchctl list|grep UIKitApplication|awk '{print $3}'|xargs launchctl remove
This doesn't work all the time. In fact, it's never worked for me but it clearly works in some cases. Just don't know which cases. So it's worth trying.
Otherwise, the only known way to fix this is to restart the user launchd. Rebooting will do that but there is a less drastic/faster way. You'll need to create another admin user, but you only have to do that once. When things wedge, log out as yourself, log in as that user, and kill the launchd that belongs to your main user, e.g.,
sudo kill -9 `ps aux | egrep 'user_id .*[0-9] /sbin/launchd' | awk '{print $2}'`
substituting your main user name for user_id. Logging in again as your normal user gets you back to a sane state. Kinda painful, but less so than a full reboot.
details:
This has started happening more often with Lion/Xcode 4.2. (Personally, I never saw it before that combination.)
The bug seems to be in launchd, which inherits the app process as a child when the debugger stops debugging it without killing it. This is usually signaled by the app becoming a zombie, having a process status of Z in ps.
The core issue appears to be in the bootstrap name server which is implemented in launchd. This (to the extent I understand it) maps app ids to mach ports. When the bug is triggered, the app dies but doesn't get cleaned out of the bootstrap server's name server map and as result, the bootstrap server refuses to allow another instance of the app to be registered under the same name.
It was hoped (see the comments) that forcing launchd to wait() for the zombie would fix things but it doesn't. It's not the zombie status that's the core problem (which is why some zombies are benign) but the bootstrap name server and there's no known way to clear this short of killing launchd.
It looks like the bug is triggered by something bad between Xcode, gdb, and the user launchd. I just repeated the wedge by running an app in the iphone simulator, having it stopped within gdb, and then doing a build and run to the ipad simulator. It seems to be sensitive to switching simulators (iOS 4.3/iOS 5, iPad/iPhone). It doesn't happen all the time but fairly frequently when I'm switching simulators a lot.
Killing launchd while you're logged in will screw up your session. Logging out and logging back in doesn't kill the user launchd; OS X keeps the existing process around. A reboot will fix things, but that's painful. The instructions above are faster.
I've submitted a bug to Apple, FWIW. rdar://10330930
Use a simple Faraday cage to block or limit the external RF signal level.
You can make your own with aluminum foil. The openings should be smaller than the wavelength of your data service if that's what you want to block.
This works better with an actual device than with the simulator since the Mac is hard to work on when inside the Faraday cage ;-)
Best Answer
TL;TR Log into http://www.icloud.com and agree to the terms.
It works. But there are some additional steps needed:
At work I tried with my new apple id: at work XYZ@mywork.com. At first It didn't work even though I was able to access iOS dev center. I realised that it is required to access to http://www.icloud.com with such Apple ID and agree to the terms. After a few seconds I received a 'Welcome to iCloud' email to my work address and then I went back to the simulator and I successfully logged in.
BTW, for a personal account XYZ@mac.com I have for ages and use regularly it worked from the beginning probably because I have agreed to the terms a long time ago.
So not only @icloud.com of @me.com or @mac.com accounts work. All accounts work.