22

How can I suspend my application or send a suspend message to my application?

I want to simulate pressing the home button.

Wyetro
  • 8,439
  • 9
  • 46
  • 64
Doom
  • 1,258
  • 3
  • 15
  • 24

6 Answers6

36

There is a private instance method for UIApplication:

The following code would work, (tested in an iPhone 3GS):

UIApplication *app = [UIApplication sharedApplication];
[app performSelector:@selector(suspend)];
moligaloo
  • 1,083
  • 13
  • 27
  • Is this accepted by the app store? I know that for few cases exit(0) will be rejected. I'm not sure about suspend. Can you confirm me? – Chan Jul 10 '14 at 12:33
  • 4
    @Chan You should never call private API for an app you submit through the app store. See Brad's answer for best practice. – Rob Oct 22 '14 at 15:36
  • 1
    This is not to encourage you to use a private API but I have apps already in the app store with this. Although while submitting it on the app store it displays a warning that there is a private API used. – sole007 Sep 24 '15 at 06:23
  • If it is private you can't. Never use any private apis inside any productive apps, it could break your neck! – Alex Cio May 10 '17 at 22:29
  • Does this still work? We want to use it only in some Unit Tests (not in App Store) to test some background handling logic. Running this (using the Swift version down below) and after running it the applicationState is still active. Before I spend too much time figuring out why, I wanted to see if others have been successfully using this in 2022. – chadbag Sep 15 '22 at 17:53
21

In swift:

let application = UIApplication.shared
let suspend = #selector(URLSessionTask.suspend)
application.sendAction(suspend, to: application, from: nil, for: nil)
ChikabuZ
  • 10,031
  • 5
  • 63
  • 86
17

Quitting your application or sending it to the background programmatically is a violation of the iOS Human Interface Guidelines, which usually doesn't bode well for getting through the review process:

Don’t Quit Programmatically

Never quit an iOS application programmatically because people tend to interpret this as a crash. However, if external circumstances prevent your application from functioning as intended, you need to tell your users about the situation and explain what they can do about it. Depending on how severe the application malfunction is, you have two choices.

Display an attractive screen that describes the problem and suggests a correction. A screen provides feedback that reassures users that there’s nothing wrong with your application. It puts users in control, letting them decide whether they want to take corrective action and continue using your application or press the Home button and open a different application

If only some of your application's features are not working, display either a screen or an alert when people activate the feature. Display the alert only when people try to access the feature that isn’t functioning.

The philosophical reason for this is explained earlier in that document:

People, not applications, should initiate and control actions. Although an application can suggest a course of action or warn about dangerous consequences, it’s usually a mistake for the app to take decision-making away from the user. The best apps find the correct balance between giving people the capabilities they need while helping them avoid dangerous outcomes.

Users feel more in control of an app when behaviors and controls are familiar and predictable. And, when actions are simple and straightforward, users can easily understand and remember them.

People expect to have ample opportunity to cancel an operation before it begins, and they expect to get a chance to confirm their intention to perform a potentially destructive action. Finally, people expect to be able to gracefully stop an operation that’s underway.

There should be no reason that you need to force your application into the background during its operation. It should remain fully functional when displayed onscreen and it should be up to the user when they want to switch away from your application.

Brad Larson
  • 170,088
  • 45
  • 397
  • 571
  • will you say the right, but the application initiates a notify, and should reopen close and you know what is happening is open only to perform some instructions, thanks anyway! – Doom Mar 19 '11 at 16:48
  • @BradLarson What if you create a back/exit button that closes the app? You're still giving the user a choice to exit in that case. Also, I disagree with being discouraged from using exit() because the home button could stop working after being overused for a long time, and in that case, how would a user exit back to the home screen? – OzzyTheGiant Oct 19 '19 at 20:36
  • Is there any chance that i can suspend my iOS application to test a specific use case? I can use private API's because i will be using this in testing and development only. Any hints? – Awais Fayyaz Feb 02 '22 at 10:17
1

You can't do this.

If you want to exit your app, don't fear rejection and love false positive crash report emails from users you could call exit(0);

Matthias Bauch
  • 89,811
  • 20
  • 225
  • 247
-7

Use :

 sleep(15)

it will suspend your app for specific time

KAR
  • 3,303
  • 3
  • 27
  • 50
khaled
  • 865
  • 9
  • 24
-9

When the application is suspended, a UIApplicationWillResignActiveNotification notification is posted.

I would guess you could try to post this notification manually. Didn't try this myself though.

Stelian Iancu
  • 2,462
  • 3
  • 18
  • 28
  • The notification is raised by iOS and calling the method yourself will not suspend the app. – Pelle Stenild Coltau Jan 10 '17 at 11:11
  • Also, this notification is sent when the app is becoming "inactive", not when it is becoming "suspended". Very different things. AFAIK there is no notification whatsoever when an app becomes suspended. – Sharon Minsuk Apr 02 '19 at 01:46