I am working on a VOIP app and need it to auto-start when the iPhone starts up. Everything works 80% of the time. But 20% of the time the app fails to startup. One test scenario is the following:
Open app and type something and save
Reboot phone
Check if app is running by double-tapping the home button but DO NOT open the app.
If app is running, reboot phone again and see if the app comes up again in the background process.
This scenarios works most of the time but not always. Other scenarios also fail at times. Can someone clarify if there is a fool-proof way to start a VOIP iOS app every time the phone boots up?
Thanks.
No, it can't be done. If a user force quits an app, it stays force quit. That's how apple want it, and that's how it's going to be. You can't circumvent the users wishes with multitasking. Also, it's worth knowing that what you see in the fast switcher is not necessarily everything that is running, it's what ios thinks the user should expect to be running ie it may shut something down in the background of its own accord in order to free up resources, but because the user did not initiate it this app will appear to still be open in the switcher, despite that it is not.
Sorry, you can't open an app on startup. You should include a reminder on the app's first start up for the user to keep that app open in the background.
Related
No code to show, but merely a question on something that I'm sure has irked other developers/users.
When a user has revoked/denied permission to their Photos for a given app and then later changes to "Read and Write", the app resets/refreshes when opening it back up. Is there a way to not have the app reset/refresh when navigating back to the app? This is a concern because when the user is prompted to change their Photos permission, the user is deep within the app and now loses any progress made on that page after the permission is changed.
I am currently using Xamarin Essentials with Xamarin Forms, if that helps any.
It is designed by iOS system and your app is forced to restart when you change the privacy settings. I think there is no way to get around it.
You can try to save the state in the method applicationDidEnterBackground and restore it when user come back again after changing the setting.
Refer:
Having app restart itself when it detects change to privacy settings
App crashes in background while changing permission
There are some situations where your app gets killed and restarted: when it is swiped out, when your device is running out of power are turned off by the user, when the app is moved to the background and there isn’t enough memory for all apps, and as you noticed, when certain settings change.
The reason for the restart on settings change is that your app might be doing things that get disallowed, or it might never notice things that are suddenly allowed; many apps check these things once when the app starts, so restarting it is guaranteed to make it work correctly.
You should have code that saves the application state when the app goes in the background, and restores the state when the app is launched. That fixes not just your problem with permission changes, but will also restore the app after being swiped out or killed while in the background.
I have a Timer which plays AVAudio at a specific time while the screen is locked (app in foreground when locked and plist setting 'Application does not run in background' set to YES).
When I run my code while my iPhone is connected to Xcode it works as desired, playing audio while locked even when the iPhone has been locked for hours.
Now if I disconnect my iPhone and just open the app by tapping the icon the audio won't be played if it's set for more than a minute.
Is there a difference that causes this problem? If I would publish my App to the AppStore which behaviour would my users get?
That 'Application does not run in background' flag is a very old flag that means your app does not support multitasking and should be terminated when the user presses the home button. There's no good reason I can think of to set that flag on a newly developed application. Unless you understand exactly what it's for and are positive that setting it to yes is the correct thing to do, don't do that.
(That flag was added when iOS 4 was released, to allow apps that could not handle multi-tasking to request the old terminate-on-home-button behavior from iOS 3. Given that we're now 6 major iOS releases from iOS 4, it seems outdated.)
So remove that flag. It probably doesn't have any impact on your question, but remove it or set it to no in any case.
If you want to run a timer while the phone is locked and play sounds at designated times then you will probably need to set your app up as a background sound player, and ask for more background time when you get a message that you are going to the background.
That being said it's likely that Apple will reject your app. Running a timer from the background means that the processor on the phone has to run at full speed all the time, which will DRAMATICALLY reduce battery life.
Apple only allows a very small subset of apps to run in the background, and then only under specific circumstances (like a background sound playing app when the user is actively listening to music, or a navigation app that is actively tracking the user's location and notifying them when it's time to make a turn to follow directions.)
Should be no different. If you'd like to feel what do your users' feel then you can publish it to TestFlight which is the best app beta test environment. Find some testers or try it yourself.
The directions should be to verify the playing logic and the sound file relationship which link to the connection.
My app is an emergency app. It will be used by people in emergency and disasters.
It's possible that they got stuck in situations where they just don't have the time to enter or draw their password on the lock screen, launch the app and push a button. Is it possible that my app can ask the OS to launch the app if user throw their iPhone up in the air or shake it vigorously or something else.
What I wish to achieve by this ?
I want that OS launches my app in background if the user say shake his/her iPhone vigorously. Once launched my app will make a network request and keep running in background for short time.
PS:I think it's possible with the accelerometer.
Accelerometer will not work because Apple doesn't allow background processes opening apps. In your case, user must be opening the app by himself/herself manually. (PS. As far as I know, it's possible in Android)
iOS background tasking problems aside:
Apple don't allow apps that encourage the user to do things that might damage their iOS device. So your 'throw in the air' idea is out.
As for shaking the device -- this just isn't practical. What if the device gets shaken by accident? You've then got false alarms to deal with.
The crux of the issue is that something that triggers an emergency response should be a deliberate action which is hard to do trigger by accident.
This cannot work - and here's why.
Your app would need to run in background to handle motion events. Apps running in background can get killed at any time, i.e. if memory gets low. There might be some restrictions about running and and resource usage as well.
An app in the background cannot bring itself to the front.
Launching from a locked screen would bring great security risks.
Throwing into the air seems like a gesture that can easily be triggered by accident.
I must admit that I'm pretty happy that those apps are not allowed on the AppStore - as it would open many doors that I'd like to see kept close.
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.
I am running an app in the background with significant location change and monitor regions, the app works well but if the user don't use the app for a couple of days then the app gets terminated. Is there a way to prevent the app from being terminated ? like maybe triggering an alert to remind the user to open the app every 2 days ? does anyone knows how to get the app to run continually, and not to be terminated/suspended ?
"significant location changes" over 4 days means your app is not only draining the battery (a no-no since iOS 4.x), but it is taking resources away from the system in the background. Apps cannot process forever in the background, so the OS makes the choice to kill it. Just turn off background processing and only update the user's location when they open the app. And do you want to know the best part: It's all fairly random! The OS could have killed Mail or YouTube or some such other app to make room for yours, but it didn't, it killed your app. There is no documented way around it, sorry.
I think it is not possible for an app to run continuously, and not to be terminated/suspended. You can use push notification to remind user to open app in every two days.