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.
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.
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 need to crate app, one of it is features to check if user is using Facebook or whats App during driving is it doable.
For privacy matters, Apple does not allow iOS apps to access other application's data, such as when the user enters them and other "sensitive" data of that sort. So, the simple answer is that you cannot do that. Another App's usage is undeterminable as of now on iOS.
Either way. Even if iOS apps are allowed to fetch data from other apps, you have to make sure your app is running on background and checking. iOS manage memory itself and kills app in background automatically. So the app is not practical. Plus if you constantly check the speed in background, the battery life will decrease.
But again on the first hand as other answers, your app does not allowed to access data. So this is not doable.
It is not possible , as apple does not allow iOS Apps fetching or accessing other apps data. Thanks
I have two apps with same UISupportedExternalAccessoryProtocols. These are communicating with the MFI certified device. How I can know that the session is already created with other app on the same device. So I can alert to the user that you can't create multiple sessions with the same accessory at a time.
Please help to fix this.
Thanks in advance.
I personally consider AyBayBay's answer invalid, since you tagged your question with the "iOS tag" and NSDistributedNotificationCenter is not supported on this platform. (There is a low level api to do this, but I think it's in a private framework)
If you are pretending to target your app to iOS8+, the simplest way to do it is using iOS8's AppExtensions feature. I made some tests creating a session within my app, and sending info to the device from another app using extensions the way below.
some app -> app extension -> my app connected with ext.device -> ext.device
so I'm pretty sure you can check if the session is opened or not and return this info to the caller app.
FYI: To pass info to another app you can also use URLSchemes or UIPasteboard too, but both behaviours in a different way than AppExtensions and I think it not fits on your case. Maybe it helps someone else...
Well when one app connects and establishes a session with your MFI device, you can post a notification to NSDistributedNotificationCenter. Your other app can subscribe and listen for this message, upon recieving it and processing it in its runLoop (when it comes back into the foreground) you can have code that blocks it off from creating a session at the same time. You will have to experiment with this a bit but it can be done.
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.