I'm trying to make a specific Interface Controller (on my independent Watch App) not go idle.
I've tried this, but ran into the issue that an independent Watch App cannot support UIKit. I've been trying to find a work-around, but haven't found anything yet.
Here's the code I'm trying to get to work:
UIApplication.shared.isIdleTimerDisabled = true
No watch app, independent or otherwise, can use UIKit. watchOS apps use WatchKit.
There is no direct equivalent to isIdleTimerDisabled due to the more limited battery life of watches.
If your app is a "self care" or "mindfulness" app then you can use an extended runtime session to remain as the front most app for 10 minutes or 1 hour.
If it is a fitness app then you can use an HKWorkoutSession to be the default front most app when the user raises their wrist during the workout.
Related
I haven't been doing this long, but this is the first time that I've had an app rejected. This is what was in my rejection.
PLA 3.3.1
Your app uses public APIs in an unapproved manner, which does not comply with section 3.3.1 of the Apple Developer Program License Agreement.
Specifically, your app contains a mechanism to keep a device awake. Please see attached screenshot(s) for reference.
Since there is no accurate way of predicting how an API may be modified and what effects those modifications may have, Apple does not permit unapproved uses of public APIs in App Store apps.
The screenshot that they included showed my setup screen where I give users the option to have the application keep the device awake. I tested it, and it only keeps the device awake when in the application. I did not come up with this idea all by myself. I've seen it as an option in other apps.
I am not using anything non-apple to do this. This is my code for keeping the device awake.
UIApplication.sharedApplication().idleTimerDisabled = keepDeviceAwake
where keepDeviceAwake is a Bool that is turned on or off by a user setting.
Is there something wrong with the way that I'm using this or what I'm doing with it?
To give more of an idea, this app is a counter app. I was thinking that it would be really annoying to have to keep turning on the iDevice when counting things, so I give the option to keep the device on while in the app.
The documentation note on idleTimerDisabled says:
You should set this property only if necessary and should be sure to reset it to NO when the need no longer exists. Most apps should let the system turn off the screen when the idle timer elapses. This includes audio apps. With appropriate use of Audio Session Services, playback and recording proceed uninterrupted when the screen turns off. The only apps that should disable the idle timer are mapping apps, games, or programs where the app needs to continue displaying content when user interaction is minimal
Apple probably feels that your app doesn't fall within the guidelines.
I'm developing a WatchKit app that I want to stay in focus until the user actively selects another app or goes back to the watch using the digital crown. Just like with the built-in Workout app.
I don't want the app to be visible on screen forever, just that when I look at the watch after some minutes I want to have updated information for my app without having to go back to the app manually due to automatic switch to the watch face.
I don't think you can control this in your app, at least not in WatchOS 1. The only way I think this can be done is for the user to select "Resume To: Last Used App" in Settings > Activate on Wrist Raise.
Apps such as Nike+ currently advise users to change this setting before starting a run.
WatchOS 2 allows apps to register as fitness apps, that will contribute as a workout and will resume when the watch is activated / raised.
Is there any possibility to know which apps are in the background (Those apps that appear when you double tap home button)?
For 3rd party apps, no. Not in a reliable, App Store safe, future proof way. Think of your app as siloed, unaware of what else is running, and you'll be pretty much in the mindset Apple want (and try to technically enforce).
For other apps developed by you, you can use shared containers to write load/unload data each time one of your apps opens/closes, and work out what's currently running.
This is not possible on iOS with public api. There might be private api calls that do this, even though I don't think you will have access to them while running in the sandbox. This however might be possible on jailbroken devices, but you will not be able to submit to the app store with such api usage, unless you know how to hide that from apple.
Also please note that apps shown in the app switcher are not necessarily running. The app switcher shows every app that has been running in the past which the user didn't force-quit. If the user does not force quit an app, every app that has ever been launched is shown in the app switcher. If iOS decides to terminate an app because of memory needs, the app is still shown in the app switcher. This is one of the reasons why everyone should implement state restoration, as the user does not know whether an app is currently running or not!
I'm building an activity analyzer application for iPhone and I use iOS 7. In order to do these i use CMMotionManager and I access accelerometer data.After this I write the datum to database. My application has to work also in background and I used queues, GCD, blocks and other such things in my code to do this properly. Problem is, all of these are working properly when iPhone is plugged in with Xcode but if I run the app without Xcode, app runs about 4 or 5 minutes.After, it is terminated.What is the reason for this?
iOS apps can only run in background, if they fit in one of apples defined background modes such as "App registers for location updates","App provides Voice over IP services","App plays audio","App processes Newsstand Kit downloads","App communicates using CoreBluetooth"",App shares data using CoreBluetooth" and a few more. All background modes you will find in xcode in the capabilities section auf your project(click on project name upper left->mainwindow->second tab).
if your app fits into one of these modes, you must enable this in your app.plist by setting the checkbox in the capabilities section.
if your app doesn't fit in any of these modes you can run in background only a limited amount of time and then iOS stops all activities.
For testing you could start any background mode. but when your app shall be reviewed for deploying via app store apple will reject the app if you use the background mode without legitimation.
The reason for this is that iOS 7 (actually all versions of iOS) will suspend a background task, and potentially terminate it if it's misbehaving, only certain kinds of apps can keep running. Here is the apple doc on it: https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW20
So, given your situation, you'd most likely have to "lie" about what type of app your app actually is, which will get you rejected from the app store.
If you do decide to go the route of a hack, be very careful about battery life, cpu usage, and memory usage, as there is a reason apple did this.
FYI: The "type" is set in your Info.plist file.
This is a strange one, I have a need to create an iOS app that runs in the background on an iOS device, but can not be visible on the Home screen of the device. The app may need to show up in Settings to configure a few options, but it mostly needs to run behind the scenes.
I do not need to publish this app on the app store, it is strictly an enterprise app for my company.
Does anyone know how this kind of behavior might be achieved? Configuration profiles? API's? etc?
Edit: Jailbreaking the device is not really an option for us. We have to keep the devices as they are.
Backgrounding
There are several methods to get permanent background execution:
a) Silent audio which is mentioned by JRG-Developer
b) Usage of beginBackgroundTaskWithExpirationHandler + turning location manager on/off (it will reset remaining time to 600 seconds)
Making app invisible
You can use SBAppTags in Info.plist (take a look at this: How to remove app icon programatically from jail broken iPhone app?)
It will make your icon not visible on Home screen.
I've no idea how you can tackle the not be visible on the home screen criteria, but there are certain services that are allowed to be run in the background continuously, notably:
Background Audio (even silent audio)
While this is indeed very hacky, short of jailbreaking the devices, this may be your best bet.
While it's unlikely / very difficult to get past the review process, in the event for some reason you do need to (attempt) to publish this app to the App Store, some apps are even available on the App Store which take advantage of this hack, such as PasteBot.
You should definitely read their write-up here about getting their app's Cut-and-Paste functionality to work while in the background:
http://tapbots.com/blog/pastebot/pastebot-music-in-background
Another out-of-the-box idea, why not use Android devices instead, which do support multitasking?
Two methods:
Jailbreak. A jailbroken iPhone is essentially a Mac and you can use all Mac UNIX programming tricks - spawn a daemon (you can even ask launchd to do that), or something. You can set up enteprise-wise Cydia source. Refer to saurik's website for a walkthrough and set up an experimental server using Ubuntu (which used apt too)
A non-jailbreak way may be possible, but it will depend on what your app is doing. You can try use enterprise-wise push notifications.
Given that this is impossible to do on non jailbroken phones, I'd suggest the following:
develop a directory app, or a phone list app, something that is specific to your company.
have it connect to a web service once a day to register the device ID (so you know the user has not deleted the app)
tell users they need to keep the app open at all times (and if a user's device does not register one day, send them an email asking them to launch the app).
Now you can send back whatever you want with the app. If they kill it, you'll know the next day when you have a script look at the logs.
If you think this is a terrible idea, it is, but its the best you are going to get on iOS right now.
EDIT: you could send a notification every day - say in the AM - to make sure the user opened the app if it wasn't running.
From my experince, this kind of behaviour cannot be achieved on iOS. When an app enters into background, it is active only for a small particular amount of time. After that, it goes into hybernate state. It stops working. So the behaviour you said can not be achieved without abusing iOS workflow. Thats why some call iOS's multitasking as not true multitasking. Only jailbreaking might help your case. That was for one case. The second one where the app cannot be seen on home screen is again, impossible. It has to be on springboard to run.