I've seen less of a problem with this over time though it still seems like it takes longer for the IOS devices to "understand" that their current version of a PApp is NOT the currently published version and to display the "A newer version of this app is available......" warning message banner. Furthermore, on both Android and IOS devices, I still insist on AT LEAST two launches and exits AFTER the user gets the new-version warning and has clicked on it. I.e. it seems just as problematic that the clicking on the new-version banner fails to actually do the download/install/launch of the latest version. Since I display a version timestamp in all our PApps, I can readily tell which version the player is actually running.
As a (painful) workaround for times when I MUST be certain users all are immediately on the most current version, I create an export package for the PApp, then delete the existing app, then import the package back in with the same (display) name for the app.
Since it gets a new App GUID, the player does not "see" the new app as a new version of the (old) app. It sees it as if it were a totally different app. But, there are downsides to this:
1) You have to re-establish your user permissions for the app (we have simple groups so no biggie for us).
2) You lose prior version history so you can't rollback to a prior version using the PApps site (but we make export package backups for all major versions so we'd use those for rollback if needed).
3) Users get prompted for permissions to access (datasource) resources again. (but we use powershell to admin-override access dialogs anyway).
Not pretty, but it's a workaround until the player is more adept at quickly noting newer versions and getting them in place.
Thanks @DeeTronSEAM. 12 messages and someone finally answered the actual question.
This is a large problem in our 1000+ user environment. This workaround will work.
I'd love if Microsoft could bring the app version into the app and then we could continue to alert the users. The small notification at the top is missed way too often.
At this risk of getting a reputation as Mr.Workaround, @D10ny5u532 , one idea I'd suggest for making an out-of-date (aka past version) app more conspicuous to end-users would be to keep a datasource (e.g. SharePoint list) of the current version identifier for each of your apps. When the app is launched, it should check its embedded version stamp (e.g. Set(appVersion, "2020-07-11 15:16") ) against the value in the datasource. If they do not match, the app can display a full screen panel that warns the user or even blocks access to the rest of the app. It could also squirt email to your support staff to warn them of users that are not getting updated. Or anything else that lights your fire. We have ours write to our app logging system.
But, I agree that MSFT getting the built-in versionCheck to be more dependable would be best. Ideally, I'd like an app setting that could prevent the app from running if a newer version is available.
The issue i'm experiencing is the user already has the App open in a web browser. I told them many times that when I publish an update, they should close the browser and open the app again before they use it.
Yet they forget and that is causing issues for me.
Is there a way to force update when the app is open in a web browser tab? Or maybe a reminder to close and update the app before using?
Check out the on demand sessions that are available now!
ISV Studio is designed to become the go-to Power Platform destination for ISV’s to monitor & manage published applications.
Features releasing from October 2020 through March 2021
Una semana de contenido con +100 sesiones educativas, consultorios, +10 workshops Premium, Hackaton, EXPO, Networking Hall y mucho más!