Is there a way for an app which does this (and requires no UI) to be accepted by Apple's App Review process?
I know that simply putting exit(0) in applicationDidFinishLaunching:withOptions: will be rejected, but what if the exit(0) is called only upon completing a TCP transaction? Does Apple reject any attempt to exit your app?
Here's what I'm looking for. I make a file in some iOS app (a picture for instance) and I open it up in my app with "Open In...". I'd like for my app to perform a function which requires no user input (i.e., sending it to a preconfigured network location). Then I would like for my app to quit, returning to the app from which I used the "Open In..." feature.
I take it that if I am completely forbidden from exiting, then the most optimal possible workflow is probably the 4-finger swipe back to the calling app. It is also not very clear what my app would do when opened regularly (from the home screen), but that's not really a big problem.
What you want to do can't be done plus there is no point. Apple will never approve such an app. All apps must have a useful purpose in their own right. If the only use of your app is to send files from other apps to some server, it is of no use by itself. Apple expects each app to have a fully functional and useful user interface.
But all of that aside, here is why this can't be done - You are given no way to relaunch the calling app. When your app is launched, ultimately the UIApplicationDelegate method application:openURL:sourceApplication:annotation: will be called. This tells you what file to process and it gives you the bundle id of the requesting app. But there is no information that allows you to launch the app that launched yours. There is no API that let's you return to the previous app.
The only possibility is if the calling app explicitly launches your app and provides a return URL. But this eliminates and general use. Any app that would work with your app would need specific code in place to support your app. Obviously this is far from a general purpose solution.
BTW - having your app simply exit is of no benefit as that doesn't return the user to the previous app.
Assuming you own both apps, you don't have to exit your app at all. In fact, doing so wouldn't bring the other app back to the foreground anyway.
Just use the standard linking technique in both directions.
Related
Before App Clips, our app (if installed) could be launched by scanning a QR code. In such a case, AppDelegate would call NSUserActivity with the payload and we would extract QR code data for parsing and actioning.
After App Clip launched, the same behavior continued until recently (assuming before 14.4). Now, if the user has the app installed and they scan the QR code, they get the App Clip card to open the app. If the user taps on 'Open', the full app is launched. However, now the initial view controller launches before AppDelegate is able to receive and parse NSUserActivity data. This creates, I assume, some kind of a race condition where majority of the times initial root controller has malformed or no data.
My understanding is that NSUserActivity is the best way to handle application launches so I am not sure how to properly address this problem versus writing some hacky workarounds.
In our testing, we have noticed interesting situations where iOS would sometimes launch the full app without showing the app clip card (less frequently) and the full app would work fine. But majority of the times, it will show the app clip card and it would break our full app if it is installed.
Our full app and app clip use the same domains (universal applinks) and we do the decision making based on URL params within the app. Basically, our applink is configured to be example.com and within both apps (i.e. full and app clip), we extract business_name=FOO and item_id=BAR within AppDelegate (where full URL might be: example.com/buiness_name=FOO&item_id=BAR.
I am hoping someone can offer advice on how to solve/fix this problem.
Apple rejected our app with the following response:
We noticed an issue in your app that contributes to a lower quality user experience than Apple users expect:
- Upon launching the app, a web page in mobile Safari opens first, then returns to the app. The user should be able to use the app immediately upon launch.
Next Steps
To resolve this issue, please revise your app to address all instances of this type of issue.
The app we're developing is a keyboard extension. The use-cases do not require a user to actually open the app and use it. As a result, in the app itself (should you launch it from home/springboard), we redirect the user to our website, which informs the user how to use the product (there's no registration or immediate tutorial required, but we certainly cant have the app do absolutely nothing). From Apple's response, this clearly isn't the right way. My questions:
If a user were to be redirected to Messages, could this solve the problem? The reason I ask this instead of just trying it is so that I dont waste time and end up getting rejected again.
Part of the problem seems that opening the app through springboard is misleading since it doesnt do anything. But my understanding is that we cannot have apps without icons (Create iOS app without menu icon). Do keyboard apps need to be published differently so that we dont have an icon in springboard? If so, please direct me to some documentation/Xcode configuration/resources to achieve this.
This is my first attempt at mobile development
The answer provided by #particleman was the right one. Just loading a WebView within the app was enough for Apple to accept the app.
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.
In my app, Can I check that which app is being used by a user right now, while my app is running in background?
If so, Is there any API available to get that info?
thanks in advance!
No. There's no public API that lets you a background app find out about the foreground app, or get a list of running apps, or anything like that.
The only mechanism for finding out about other apps on the device is +[UIApplication canOpenURL:], which you can use in some cases to find out whether a specific custom URL scheme can be handled. From that you can often guess that a particular app is installed, although the method really only tells you that some app that can handle the given scheme is installed. However, you still can't find out if that app is the foreground app, or even if it's running at all.
I know Apple frowns upon closing the app because the user might think it crashed.
So how do I make it quit intentionally with an exception that doesn't get caught when the user goes back to the home screen? Also, would this be rejected by the App Store?
I wrote this answer to another question. It an extract from the Apple Human interface guidelines and should help you understand why you shouldn't quit programatically.
You shouldn't force close an app as the standard way to terminate an application is to press the home button (or use the multitasking bar)
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.
Source
Apple will most likely reject it as a violation of the human interface guidelines, so it really doesn't matter how to do it.
So how do I make it quit intentionally with an exception that doesn't
get caught when the user goes back to the home screen?
You don't. If your app is "done," just go back to the initial state. Reset all your variables, release your view controllers, whatever. Pretend that the app actually did terminate, and that the user started it up again. You'll be happy, your users will be happy, and Apple will be happy.
An alternative, if your app truly can't continue for some reason, is to display a message that explains the situation to the user and tells them how to resolve the problem. Leave that message visible until the user leaves the app by pressing the Home button. This can be the only reasonable way to deal with situations where some resource such as network access is missing.
Also, would this be rejected by the App Store?
Nobody can say that for certain other than Apple, but I think the probability of rejection is high.
Please see the answer to this question:
Forcing a background application to terminate in iOS simulator
It will tell you how to setup your application to terminate instead of backgrounding when the user hits the home button.
If you don't want to do that, I recommend you should instead release resources when your delegate's applicationDidEnterBackground fires. I think that is your safest bet. More than one of us say what you're wanting to do is not ideal.