Missing Root View Controller with iT2D 1.4.1 builds against iOS-5

#1 Has anyone made any headway into this issue?

#2 @Brian

Does the app run? If not, what happens?

That warning shows up in every project build with both iOS 5 SDK and iTorque 1.5, but the supplied projects eventually run; here's the warning from the Aquarium sample

Quote:
iTorque2DGame[5895:707] Applications are expected to have a root view controller at the end of application launch
wait_fences: failed to receive reply: 10004003

I tried iTorque 1.4.1 and iOS 5 and the only warning is

Quote:
wait_fences: failed to receive reply: 10004003

Note that there is a bug with iTorque 1.5 when running in portrait mode (a black screen shows up), but a fix is supplied here

www.garagegames.com/community/forums/viewthread/128170

#3 Hi Pedro;

The app does run. I'm just concerned that this will eventually lead to a non-approval action by Apple reviewers when one of our apps is submitted.

During the early phases of my recovery efforts, I did also get the wait_fences warning with 1.4.1. However, after applying my fixes to the engine, that went away.

Still, the "root view controller" warning sticks its head out now that my project has been updated to conform with iOS5.

I interpret the warning as Apple saying it is no longer (never was) OK for you to assume your nib is your root view controller and that it now must be explicitly declared.

I just cannot seem to find the "correct" way yo implement a root view controller to satisfy Apple's requirement without breaking something else (with the way iT2D was built).

Your post now lets me know that this issue also resides within 1.5.

I hope this is not a disqualifying warning for Apple.

Has anyone submitted (and received approval for) an app which does receive this "root view controller" warning?



Thank you

#4 I am also getting this message.

My app runs. But I noticed before it shows this message (at start up) my app has a lil hiccup. I didn't really think of it as anything bad at first...

I recently submitted my app to itunes. Couple of days later I get an rejection... could it be this message? I am not sure.

According to apple my app crashes on start up on iOS 5.0.1 ... i've tested my app on 4.2 - 5.0 iphones and they ran fine. I'm not sure what's causing this crash!

So now I am paying attention to this message:

"Applications are expected to have a root view controller at the end of application launch
wait_fences: failed to receive reply: 10004003"

#5 It's 4am; and I've been at this for hours... but I think that I've figured out a dead-simple partial solution.

In TGBAppDelegate.mm
In applicationDidFinishLaunching

add

window.rootViewController = [[[UIViewController alloc] initWithNibName:nil bundle:nil] autorelease];
[window.rootViewController setView:window];

All this does is get rid of the error message; and should not be considered a permanent fix. Apple is correct in insisting that every app have an actual rootViewController nib (now that I've done a little research on the subject).

I compiled a simple app a dozen or so times and never got:
Applications are expected to have a root view controller at the end of application launch
Once, I got:
wait_fences: failed to receive reply: 10004003
All other times, there was no error message of any kind!

I'll leave it up to those of you good folks with a bit more coding experience to figure this whole thing out.

I tried the instructions on:
http://cupsofcocoa.com/2011/09/24/the-jungle-part-1/
where I added the actual nib, class, etc., but failed miserably!

I will scream if the app I submitted two days ago is rejected because of this issue. A year and a half of work might be in danger of significant delay.

I hope that somebody will be able to come up with a permanent solution.

#6 @Don - Please post in this thread or e-mail me (michaelp@garagegames.com) immediately if your app is rejected due to this specific issue.

#7 Hi Michael,

I certainly will!

Any notion about how to solve the (apparently separate) issues of the missing rootViewController and the occasional wait_fence error that pops up simply because the window tries to open?

#8 A quick update about my game reviewal process...

My app was rejected.

They did not mention the missing rootViewController issue. They simply said that it took too long for the game to load. Their testing protocol must have simply popped it out for rejection before it was even seen; since it runs flawlessly.

I changed the source from applicationDidFinishLaunching to applicationDidFinishLaunchingWithOptions (which is what Apple recommends). I also added the rootViewController stuff seen above.

I also changed my execs so that only enough will load to show the splash screens; and then everything else gets loaded between the splash screens and the main menu loading.

I continue, as always, to get:
wait_fences: failed to receive reply: 10004003
as the only error presented by the app.
[Apparently, this is a CoreAnimation issue on IOS devices; when the device is either expecting an image that hasn't yet been loaded, or is trying to load an image before the app is ready for it.]

My new and improved game has been uploaded and is waiting for review.

I'll let you all know what happens.

#9 Hi Don;

Thank you for pitching in to the validity of the potential seriousness of this thread. At first, I found it odd that not many people were jumping in with "me too" posts but I guess they were just ignoring the warnings in the log.

Now that we've had two rejections from Apple (even though they do not explicitly state the "missing rootViewController" as the cause), I think this "warning" really needs to be addressed.

I too tried to implement that solution provided at Cups of Cocoa, which ended in more issues than when I had nothing at all. Your addition of the applicationDidFinishLaunchingWithOptions fix seems like a logical place to start.

I will apply your simple fix for now and get back to other recovery tasks.

Thanks again for your efforts.

#10 While the rootViewController is certainly an issue to be dealt with, I think that this raises an even more important question: Is the time it takes for the iT2D game engine to load too long for Apple?

I have optimized the loading of my game as much as is possible. If it is rejected for taking too long to load, then I have no options.

If my game is accepted (and I can stop panicking!); then I intend to attempt to create a new Torque. It would be based on a UIViewController, have animated splash screens using CoreAnimation, and then (and only then) would I load the game engine.

I'm far from an ace programmer, but it should be possible to accomplish this goal.

[While the solution sounds elegant, I have little doubt that the implementation would take far longer than I imagine! After all, if it were simple, GG would have already done it!]

If my app is accepted...

Until then, imagine me sitting in the corner of a cold panic-filled room, mumbling to myself; a lone tear streaking down my cheek...

#11 How long is your app taking to launch (in seconds)? I think there may have been a "suggestion" in one of Apple's guidelines as to the maximum amount of time an app should take to load. I'm just not sure, now, where that was.

Anyway, it presently takes my app about 3.5-4 seconds to load to the main menu from the point of app icon click (when not launching through XCode or one of the Analyzers. The load time likely comes down to how many assets you are trying to load into memory from the onset of app launch.

Your idea of reworking the launch sequence of iT2D is not a bad solution at all. Just make sure that the launch sequence gets to a usable menu screen as quickly as possible. If it takes 30 seconds to load a level after clicking "Play" or "New Game" (assuming your app is a game), Apple doesn't care. All they want to know is that your app launches quickly.

Quote:
After all, if it were simple, GG would have already done it!

Oh boy...watch out for the trolls now. As the classic saying goes, "Never assume anything. It makes an ass out of u and me." ;)

GG has been struggling with this engine since its inception. While the engine is growing in usability, the vast majority of the things you would expect as already being part of the engine were, in fact, community developed:

• The up to 200% frame rate increase
• Universal support
• Retina display
• Multi-touch
• Full rotation support
• Correct library pathing
• Correct target and Base SDK setup

All of this "basic" stuff is afforded to you as a result of the efforts of this community.

By applying the restructuring that you suggest, you will in fact have joined the ranks of those of us whom have been improving the engine since day one. Heck, even your rootViewController fix is one we can (and should all) use.

Please do keep us informed as to the status of your approval.


Thanks

#12 Thank you for your comments Brian.

My comment about GG wasn't meant to be, in any way, troll-like. I simply meant that getting the engine to load quickly is hard! I apologize if my comment was misconstrued.

I've already stripped down the initial loading so that only the splash stuff loads. Then I load enough to show the main menu. I've customized the level resource loading so that resources are only loaded if they need to be; for quick level switching.

My game is fast and efficient. I was able to hold down the size of the app to 40Mb - for 60 levels!

After my second submission, which was rejected, Apple sent me crash logs; which tell me nothing. If anybody wants to see them, just email me (dwschaper@gmail.com) and I'll be happy to send them.

---

I should clearly stated that other than the addition of the rootViewController code and changing the audio gain in SoundEngine, I have made no alterations to the iT2D source.

The game crashes for Apple with or without the rootViewController code and the alteration of a simple variable declaration can not possibly be the cause of this problem.

---

In an effort to get a copy of my app that crashes, I created an ad-hoc distribution (using all release configurations) for myself. I put it on my iPad, gleeful that all that work would result in some non-debug thing I could test as it crashed.

It worked perfectly. Sigh...

#13 Here's an interesting tidbit I learned about crash logs and why my app is NOT crashing for Apple...

If an app is rejected due to their watchdog timeout, the associated crash log will always contain:
exception code 0x8badf00d

Bad food (badf00d) gives one indigestion. That is so funny!

So... My app was not rejected because Apple thinks that it takes too long to load.

Now I just have to figure out why the game is crashing for Apple (and not me) with:

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000060

#14 Just wanted to chime in on something Brian said. Because a forum post cannot convey tone, let me say ahead of time that I am not taking offense or intending to be defensive.

Quote:
GG has been struggling with this engine since its inception. While the engine is growing in usability, the vast majority of the things you would expect as already being part of the engine were, in fact, community developed:

So the full story is not being stated in that post. Have we pulled from the community? Yes and I'm very proud to be able to say that. Why? I just had a conversation with Tom Spilman about what attracted the two of us to the GarageGames community. Unlike a lot of developer sites at the time, previous Torque engine developers fostered community development. They (nor do I) did not take offense to anyone pointing out limitations and trying to fix them.

I can make a blanket statement in saying that the Torque products are where they are today because of the community. Bug reports, resources, criticism, code contributions, etc. People have been hired from the community to work directly with the technology because of this practice. Not a bad thing in any way.

As for the features you listed, let's look at the list again:

Quote:

* The up to 200% frame rate increase
* Universal support
* Retina display
* Multi-touch
* Full rotation support
* Correct library pathing
* Correct target and Base SDK setup

Universal support: The majority of this system was written in-house. The object loading based on platform, the save system, the editor support, all in-house.

200% frame rate increase: Yes, it was a direct port of the underlying line of code. It would have been stupid not to just bring that in. However, we took it a step further by exposing the functionality to the editor. We made it easy for a developer to easily toggle the change, so as to not break previous or existing projects.

Retina display: The base code was brought in, but it was quickly modified to accommodate the rest of the universal app support system.

Multi-touch: Edward's base code is the foundation of this. However, we wrote the implementation to fully expose multi-touch to the ActionMap system. The limitation of having three statically named global functions was removed, which allows a developer to have different multi=-touch schemes.

Full rotation support: We brought in some bug fixes, but the new script interface was written by us.

Correct library pathing + target and Base SDK setup: Not sure what you mean by this. I remember fixing this on my own. We had to rely on a community fix during the shutdown and start up period, but the final implementation was my own effort.

What's better to point out was that all of the above features were community DRIVEN. Even if everything was 100% written from scratch, we would have still targeted those features because we listened to what the users wanted.

#15 Well said, Michael...

As I've been studying the source lately, I've come to realize how truly monumental Torque is. It's such a wonderful thing to be able to concentrate on art and music, with only a few thousand lines of script thrown in; to end up with an incredible game.

You cannot begin to imagine how much I appreciate the hard work you and the others have put in over the years.

#16 On Dec 16th, I have a very interesting conversation with someone from Apple Developer Support.

[The talk was very funny. It started out with my being called to be told that I needed to stop submitting an app that crashed on launch; and ended with the guy holding his iPad in his hands with my game running on it. Force of Attraction was put up on the app store that day!]

Pertinent to this thread... I had the opportunity to ask two questions.

Root view controller... This will be a requirement in the near future; and the solution I added to my project (see above) satisfied said requirement. They will be checking for that error message and begin rejecting apps "soon". He did add one caveat, saying that Game Center integration might require a nib-based root UIViewController. He also pointed out that gesture integration is much easier with a root UIViewController.

I asked about wait_fences... It was clear that my five minutes was about up and he was ready to move on. His only response was that memory leakage, which is the typical cause of this error, will be "a higher priority moving forward." [I wish I could figure out why Torque has such a large memory leak spike when it loads scripts.]

Finally, I asked if all of this 'soon' meant IOS 5.1. His response, "We do not comment on such things, but IOS 5.1 is soon."

I think that it is clear that Apple is quite serious about requiring a root UIViewController. It makes sense, since so many apps nowadays use multiple views. Old-style window-based apps that use a UIWindow as root appear to be going by the wayside.

Has anybody had any success at trying to create a new Xcode project, based on a root UIViewController, and then throwing Torque onto it? It shouldn't be that hard (or I just think that because I don't know enough!).

#17 @Don - This has been an invaluable post. Thank you for taking the time to relay the information you gathered. This makes the scope and goal of the next iTorque 2D patch very clear. I'll talk to Eric about it, but I think it's safe to say we will continue our past pattern.

v1.5 - Feature push
v1.5.1 - Bug and compatibility pass

Quote:Has anybody had any success at trying to create a new Xcode project, based on a root UIViewController, and then throwing Torque onto it? It shouldn't be that hard (or I just think that because I don't know enough!).

I'm going to take a crack at it during my holiday flights and downtime. It's been crawling up the priority list for a while and I think it will be the cleanest way to start with a fully compatible project and address the root UIViewController issue (which I'm not really pleased about, but oh well).

#18 @Don Congratulations on getting you app up! ...and thanks for sharing your experience!

Did you get any details on why they were saying your app was crashing at launch?

Did you get any advice for 'next time' if you have the same issue?

#19 Michael... I also think that it's silly to require a root UIView nib (and UIViewController in code) or UIViewController nib for a single-window app. However, as I've been trolling around the internet, I've noticed that a lot of people are having problems implementing multiple views and then keeping track of them (sloppy coding, mostly); leading me to think that Apple has decided to nudge people into (what they consider) better practices.

Ray... It's embarrassing to say this, but I spent more than a week tearing my hair out trying to figure out the problem; only to discover that I had Icon72.png instead of Icon-72.png. This led to instant rejection with no explanation (and extremely unhelpful crash logs). I know that this was the issue because the last build I submitted had only this one change in it!

#20 I'm unsure if this requirement is about 'better practices' and not simply about 'needs to be there to simply fire it over to apple TVs and similar offerings in 2012'. Without a view controller there is no resize magic that can simply take part, manually sized views would totally fuck up on new resolutions (as they did in the past)

The whole iPhone -> 2x ipad mode is a good example of this.