Imagination PowerVR SDK Blog

XCode 7 & PowerVR SDK Examples (I know, it's early)....


PowerVR SDK 3.5 using XCode 7, targeting iOS 6.1 (and others).

The sample(s) build, but on execution the following happens:

InitApplication() succeeded
InitView() succeeded
2015-09-11 18:59:27.340 OGLES2Water[1863:58149] *** Assertion failure in -[UIApplication _runWithMainScene:transitionContext:completion:], /BuildRoot/Library/Caches/
2015-09-11 18:59:27.351 OGLES2Water[1863:58149] *** Terminating app due to uncaught exception ‘NSInternalInconsistencyException’, reason: ‘Application windows are expected to have a root view controller at the end of application launch’

That explains it well enough, the code in has:

[_window addSubview:_glView];

Other threads on this related error state that a call to setRootViewController is required, but I’m not sure what complies. _glView doesn’t appear to be acceptable (doesn’t compile if I change the line to

[_window setRootViewController:_glView];

The compiler says EAGLView can’t be the lvalue,

It SEEMS this just requires a simple adjustment - thought someone here might know what qualifies as the UIViewController object in the typical examples provided in PowerVR SDK 3.5 (like Water)


Update, of a kind:

It seems this may be an iOS 9 issue, not an Xcode 7 issue. Similar inquiry, but at least if we target and build for an iOS 8.x device, the software works. An iOS 9 simulator will crash, even if the build targets older (say, 6.1) versions.


At the risk of talking to myself ( :wink: ) I found AN answer, not sure if it’s really the RIGHT answer, but here’s what worked:

In AppController.h of the sample, the following objective-C interface is declared

@interface AppController : NSObject <UIAccelerometerDelegate>

So, I changed that to:

@interface AppController : UIViewController<UIAccelerometerDelegate>

Then, in, at comment “Create a full-screen window”, where it allocates the _window member, I added:

_window.rootViewController = self;

Now, it launches without complaint or incident.

The reason I think it’s not the RIGHT answer is that it is incomplete. Now, when rotating a device, the display orients in inappropriate ways, probably because it’s not controlled so as to ignore the orientation.

At least it’s a good start.


Thanks for reporting the issue. I’ll discuss it with the SDK team


Apologies for the delayed response. We’ve reproduced the issue. I’ve filed a P1 bug against the SDK (BRN57583) to make sure this is fixed in our upcoming 4.0 SDK release.