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.
Related
i have a big problem. I am working on an app about accessibility. The app should work through the iPhone microphone to take over sounds from the environment (indoor) and compare them in real time with sounds in the app database (recorded from users previously). If sounds match, the user will be warned by the app through a notification. So... firstly, the app should listen sounds working in background, but after some minutes, iOS closes the app in background automatically. IS THERE SOME SOLUTIONS FOR THIS PROBLEM? TO ALLOW THE APP BE OPENED AND WORKING?
Secondly, do you know in which way is possible compare sounds recorded with sounds listened by microphone in real time?
Really really thank you. 🙏🏻
Regarding the problem that your app is automatically closed, it seems that something was not configured properly in your project.
When the UIBackgroundModes key contains the audio value, the system’s
media frameworks automatically prevent the corresponding app from
being suspended when it moves to the background.
Make sure that you have enabled the "Audio, AirPlay and Picture in Picture" background mode in your project.
Fore the first question:
Because your app will be recording the audio while in background, you can:
set UIBackgroundModes key in your app’s Info.plist file to audio.
It should keep your app alive when you press Home button. See the Declaring Your App’s Supported Background Tasks section
At some point, iOS can kill your app due to some conditions, but
eventually it would restart your app later.
And be careful with this, you might have to deal with Apple Review team to prove that your app is not doing something harm to user privacy. Otherwise, they wouldn't let it go live.
For the second question:
I think you can use some AI/Machine Learning service out there to do so. It's much more accurate and faster than building it your own.
Once in a while we want to force update our up. We do this by checking with our server at boot and if the new required version of the app is higher then the current installed version we display a typical "Download new Version" button that takes you to the App Store page directly. Here is where we run into issues.
It appears that the "Update/Open" button of the App Store App doesn't refresh immediately, even after the app has propagated properly. It almost seems that once you open the App Store App it needs some time to check the status of all the apps, you can actually force this by clicking on the Update tab, after that the page linked for our app, shows the "Update" button instead of the "Open" button.
Now here is where our users have problems. They open our app and it tells them to update, they click the button and it takes them to the app store which tells them to Open. If they click it, it goes back to the app and they are now in a cycle.
That seems to happen, if they have good connection, only once, but if not they need to do this cycle at least a couple of times before the App Store App has realized that the button needs to be switched to Update.
Has anyone had to deal with this issue? How have you handled it?
Wait more time after propagation?
Special link that forces refresh?
There is a view to update the app that I think can be called from inside our app without going to the app store?
Any suggestion is welcome.
Thanks
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.
I have an app that uses the ALAssets framework to access to the users photo library. I wrote some code that detects whether or not the app has permission to access the photo library, and if it doesn't, I display an alert message which tells the user to turn on location services for the app in settings.
Problem is, when the user manually changes the privacy settings and then they reopen the app, iOS forces the app to crash with SIGKILL.
I've noticed that the way another app handles this is by somehow detecting a change in the privacy settings, and forcing the app to restart the next time the user opens it. Does anyone know how to accomplish this?
You misunderstand what is happening. Your app is not crashing (though it may appear so if you are running the app with the debugger).
When you switch to the Settings app (and your app is suspended in the background) and change the privacy settings, suspended apps are terminated. When you switch back to your app, it is simply started again. This is no different than your app being killed for any other reason.
It is up to you to code your app to handle this by restoring its previous state. The other app you talk about is simply returning the user to the previous state. Many apps do this. It has nothing to do with being killed due to privacy changes. The app would restore state when being killed for any reason.
You can check whether you're authorized to access the photo library using the authorizationStatus class method of ALAssetsLibrary. You should check this value in some method that will be called each time your app "opens", and update your UI accordingly.
I'm trying to use the new Saving/Restoring app state feature on iOS 6, but (application:shouldRestoreApplicationState:) method is not called if I killed the app so it doesn't restore the app state, but If I'm running it from the debugger it gets called.
It worked when I added (Application does not run in background) in the plist and set it to YES, I don't want to set it to YES though. I was wondering if anyone got it working without setting the (Application does not run in background) to YES.
From the Apple docs:
The system automatically deletes an app’s preserved state when the user force quits the app. Deleting the preserved state information when the app is killed is a safety precaution. (As a safety precaution, the system also deletes preserved state if the app crashes twice during launch.) If you want to test your app’s ability to restore its state, you should not use the multitasking bar to kill the app during debugging. Instead, use Xcode to kill the app or kill the app programmatically by installing a temporary command or gesture to call exit on demand.
From experience, the easiest way is to put your app into the background by pressing the home button (or Command+Shift+H for the simulator). Then use the Xcode stop button. As the docs suggests, a debug exit gesture also works.
Update:
I found a small work around. The app saves its state in Library/Saved Application State/[Bundle ID]-[App Name].savedState/data.data.
When using the simulator, you can copy this file and drop it in anytime you want to restore to that specific state.
Similarly, on a device you can generate a .xcappdata archive from the organizer. Then, you can upload the .xcappdata archive when you want to restore from that saved state.