0

This may be of little use to anyone, but it's possible to return from UIApplicationMain by nesting the call in a try{}catch(NSException* e){} block. I'm currently doing this for testing my setup process, in order to run some logic after the application exits. I'd like to take this a step further and actually write separate UIApplication sub classes and run them in serial but UIApplicationMain doesn't want to play nice, it's a singleton and it must remember what it once was (the first UIApplication to be instantiated). Here's the error I get when I attempt to create a second UIApplication after returning from the first call to UIApplicationMain...

2010-12-28 16:01:36.890 SomeFakeAppName[26993:207] *** Assertion failure in UIApplicationInstantiateSingleton(), /SourceCache/UIKit_Sim/UIKit-1447.6.4/UIApplication.m:1263

So, two questions:

I understand that I'm probably 'Doing It Wrong' but how might I go about clearing UIApplication's memory so that it thinks each successive UIApplication instantiation is its first?

If this is a dead end I may try replacing UIApplicationMain by manually setting up the main event loop and instantiating the UIApplication, has anyone done this?

schellsan
  • 2,164
  • 1
  • 22
  • 32
  • 2
    Why would you **ever** want to do this? – Jacob Relkin Dec 29 '10 at 01:18
  • Here is a use case - you have an indefinite number of UIApplications that must all conform to the same unit tests. Instead of integrating the unit tests into each application target, building and running each manually, you can use this method to run the tests on each UIApplication with one build and run. – schellsan Dec 29 '10 at 16:37
  • @schellsan The problem is that `UIApplication` isn't really an object representing the application. The application is still kept alive by the lower OS. `UIApplication` just makes it convenient to access those lower features. You could perfectly create an application without `UIApplication`. (There is one big problem: many of Apple's classes depend on `UIApplication`.) Anyway, good luck breaking in. We're interested in what you find. (BTW, I know this post is old :-p) – Constantino Tsarouhas Jun 10 '12 at 14:43

1 Answers1

2

Pretty sure you can't. UIApplication's are managed on the OS level and Apple doesn't really give you the keys to drive how all that works.

If it's possible at all, you would be diving into private APIs (which shouldn't be a problem cause we are talking about non-released test suite setup right?). Look up the UIApplication.h decompiled header files that are in a few various places. Look for private methods that sounds like what you want and try it out.

But in all likelihood, this path leads leads to pain and suffering.

Alex Wayne
  • 178,991
  • 47
  • 309
  • 337
  • Yes, since this is just for testing (and the pursuit of knowledge [and the lulz]), using private apis is totally acceptable. I've used class-dump to find these possibly useful functions: - (void)_purgeSharedInstances; - (void)_setActivated:(BOOL)arg1; - (void)_setSuspended:(BOOL)arg1; - (void)quitTopApplication:(struct __GSEvent *)arg1; - (void)_terminateWithStatus:(int)arg1; - (void)terminateWithSuccess; - (BOOL)launchApplicationWithIdentifier:(id)arg1 suspended:(BOOL)arg2; – schellsan Dec 29 '10 at 18:26