Struggling with iPhone - How to debug on device


I know specific issues should be posted on SO but:

  • I did already (it did not help unfortunately)
  • rather than addressing my specific issue, I am hoping people will shed some light on how they use Ember with Mobile Safari

Our app is running well on desktops (from IE8 onwards), but it crashes on iPhone when we do the following sequence:

  • kill Safari
  • launch it and point to URL
  • all goes fine until the first transitionTo is called
  • stops (not sure where, but it seems the views are not rendered)

If you reload the page without killing Safari, everything goes fine.

What is killing us is as soon as we connect the iPhone to a Mac to debug, it becomes impossible to reproduce the bug (I have no idea why)! The bug does not happen when we use the Simulator either. So we are totally in the dark.

We have done the “obvious” stuff like splitting our assets to avoid big gz files. No luck.

  1. Has anyone been confronted to something like this on iOS?
  2. Any tips to debug Ember apps on this platform?

I apologise this is a bit “open”, but we have spent hours and hours on this and we don’t seem to be going anywhere…


@stefan or @krisselden may be able to provide some insight. They’ve both done a lot of mobile work with Yapp.


I haven’t had a bug that went away when I’ve plugged in the phone, but certainly had bugs that didn’t appear in the simulator and before there was USB debugging. We used weinre before we had USB debugging, a server is hosted at

You can also instrument things to the console and plug in the phone to look at the console log after the fact.


Here is the link to the weinre docs


Thanks a lot @krisselden. This and Ember.onerror is helping a lot.

I am starting to feel we are hitting a memory issue or something. The bug we are getting does not make any sense to me: in controllerFor, this.router is undefined! Hence the crash.

Have you guys had to do anything special to get everything to load properly?


Is this a Cordova wrapped ember app? because if so, you need to App.deferReadiness() for the Cordova ready event.


No, it is a standard web page. The same one we use for desktops (minus CSS changes).

I just discovered that it only happens with Safari. Chrome (on iPhone as well) is just fine. So it might not be a memory issue (the page is not that big actually), rather a bug with Safari itself. Somehow a context is not setup properly or something like that. It does not make sense that a route does not know about its router I think…


I’m having a similar issue with iPhone Safari. If I hit a particular route, navigate away from it, and come back, the entire browser locks up. When I enable remote debugging, I can’t reproduce the issue. @thingista, did you ever find a solution to your problem? If this is not the appropriate venue, can you point me toward your stackoverflow entry? Thanks!


@bwilhelm Sorry for the late answer - I was away. I never found the root cause and a proper solution. I ended up assuming it was a bug on the iPhone side. I sorted it with a “dirty” hack (definitely dirty but it has worked fine so far).

In the activate hook for the route of my first page, I just store a ref to the router:

if (IS_MOBILE) Ember.set('App.CurrentRouter', this.get('router'));

In the problematic route, I added the following routine for mobile:

if (typeof this.get('router') === "undefined"){			
    if (typeof Ember.get('App.CurrentRouter') !== "undefined") {
	this.set('router', Ember.get('App.CurrentRouter'));


Again: I do know it is dirty… but I had to ship and it has proven robust so far.


Interesting. Maybe my problem was unrelated to yours, but but it turned out to be an issue with the .isValid() method in moment.js. I was populating a select box with the days of a given month, counting up from 1 and using moment.isValid() to know when to stop. I wasn’t enforcing strict date parsing in moment (see docs here and scroll down to “Moment’s parser is very forgiving…”) and it seems that in iPhone Safari .isValid() would never return false, so my loop would run forever. Simply passing true as the third argument to moment() forces strict date parsing and fixed the issue for me.

eg: moment('2013-09-15', 'YYYY-MM-DD', true).isValid()

Since moment is recommended in the Getting Started screencast at, it seems likely that other users could encounter this problem.