We would like to be able to remotely control an app on an iOS device so that the app can be automatically brought to the foreground WITHOUT the user having to do anything, for example when the app receives a remote push notification. My understanding is that normally there is no way to bring an app to the foreground in iOS unless the user presses a button, because Apple has decided that it knows best, and that it is better for app developers and users not to have this possibility, because it could be abused.
We are working on a security-related app where we believe that there would be strong justification for this type of functionality (in a case where the user is not able to take any actions).
Two questions:
Is there any way to do this in iOS coding that others on similar posts have overlooked?
Does anyone have experience with whether Apple ever grants exceptions to this kind of rule if there is a good justification?
The answer is simple: NO, and there is no chance that Apple will agree to allow you to implement such functionality. The only app that does this is the Phone.app because that is its purpose.
Related
Assuming you created an app that users have downloaded that is just awful and you neither want to fix it nor have anyone continue to use it so that it won't tarnish your brand, is there a way to end its life on user's iOS devices?
Curious if there is some store setting to force it to work with earlier versions of iOS and invalidates the current app, or code that would force an update that says the app is no longer available.
As many have confirmed, there is no way to remove an application from someone's device. For these cases though, many companies have servers that the application sends a request to on launch, that returns either a need to update the app, a message, or to tell the user the app has been discontinued and that the app cannot be used anymore, stopping them from using the app from there on.
The last use case might be useful to you, but of course this is a proactive solution, not a reactive one.
I've been developing iOS apps for enterprise use for several years now. It was an adjustment from having spent many (!) years developing desktop apps. One of the first things I learned very early on was that it is frowned upon for an app to kill itself. The posters in the Apple dev forum were downright hostile about it, which is a reason I never go there anymore.
Now I have an app that has very critical functions, and it requires that the user accept the terms and conditions before using the app, and that the app will not function if the terms have not been accepted. The choice is there to accept or to decline, but it seems like the best thing to do when the user actively declines is to kill the app entirely.
My question is, under those circumstances, would there be anything wrong with that? Will I be damned to developers hell for eternity?
You can change the interaction here.
Instead of accept (and use the app) or decline (and never be able to use the app) change it to accept (and use the app) or nothing.
If the user does not accept then they cannot use the app. They do not have to decline anything. Absence of acceptance is all you need.
If they don't accept then don't do anything. They can always come back later and accept and start using the app.
Why kill an app on a declying? I would rather just leave a user at the same screen with no actions before he puts acceptance checkbox, disabling all buttons
If you make the app kill itself, Apple won't let you post it on the App Store.
You should adjust your User Experience to the case of the user declining the terms and conditions.
For example, show a screen saying that the app can't be used unless terms are accepted, with a button saying "Take me back" that takes the user back to the terms screen.
I am working on an app that I feel would enhance the user experience if it provided an option for users to quit the app. This option would only be available from one of its screens.
I have researched this idea and I am fully aware of the following:
Technical Q&A QA1561
Quit iOS Application Programmatically with UIAlertView
Is it possible to quit iOS app after we do some checks
However, what I am proposing is a situation where one of the screens provides users with a range of options via a number of buttons. Each button has an icon and is clearly labelled.
Since the Quit App option would allow users to manually quit the app, the user will not then think the app has crashed. And, because the function of the button is to quit the app, then this isn't a case where the app was unable to provide its intended function. In fact, it's the exact opposite as the intended function is to quit the app.
My question is:
If this is a user-selectable option that is clearly labelled in terms of what it does, will Apple still reject it? If so, would it make any difference if the app provided a 'confirmation alert' after the user selects the option?
I am hoping that someone can either:
share their experience of having tried the same approach
refer me to an existing app that does this (as an example that it would be approved)
Actually about this Apple provide detailed answer in this link.
Kindly follow it.
Basic Snapshot :
In iOS, the user presses the Home button to close applications. Should
your application have conditions in which it cannot provide its
intended function, the recommended approach is to display an alert for
the user that indicates the nature of the problem and possible actions
the user could take — turning on WiFi, enabling Location Services,
etc. Allow the user to terminate the application at their own
discretion.
Apple is says gave the Warning to developer to do not call exit methods forcefully.
Warning: Do not call the exit function. Applications calling exit will
appear to the user to have crashed, rather than performing a graceful
termination and animating back to the Home screen.
If during development or testing it is necessary to terminate your application, the abort function, or assert macro is recommended.
Hope this will help you.
Is there a way to open an app from the lock screen without putting in the password? Like the phone app can be called when a missed call notification is present. Is this possible?
I have dabbled with various ideas to make the main functionality of my app work. Through my research I cannot find an answer to my dilemma.
I want the user to be able to use the app without unlocking the phone or once in the app not being able to quit the app without a password essentially locking the phone from other uses except the main functionality of the app.
I know there are private frameworks that would allow it but is there a way to do it with Apple's approval?
No. This would be a security issue as you could send an APN and potentially allow someone to get into a locked device without the user's approval.
I am creating an app, which needs to do something when the user presses the power button 5 times.
I figured out that it's difficult to implement in iOS, but I think it's not impossible. How do I listen for power key events, even when the app is running in the background?
Can anyone help me to find solution?
you can tap a power key once and also you cannot detect the event from your application, this is not possible in iOS as far now, better try a different way to send alert with in your app, set some conditions with in your app and then send a alert based on those conditions if satisfied, I think this would be better,
Somehow ,If you try to override the existing functionality of the power key, apple will reject your app I think so,
You can't directly get the power button events. But there are notifications which you can count like UIApplicationProtectedDataWillBecomeUnavailable or UIApplicationWillResignActiveNotification. Or just register for all low level notifications with CFNotificationCenter and see if you find something fitting like com.apple.springboard.lockstate.
I don't think you can override system level actions like holding the power button, pressing the home button, overriding the mute sound switch within your own app. iOS system doesn't exactly behave like an normal computer OS, it's to much more limited.
Apple is not allowing you to use hardware components completely. They have added some restrictions. They provided the method in the app delegate i.e. applicationDidEnterBackground can catch the home button press .Also they has provided the the API's to access the camera,bluetooth etc .At least this much of API's I know which provided by apple publicly to access the hardware. You cannot access the other hardware elements in your application which not provided publicly by apple .If you are able to do this by any way then also your application will not approved by apple .