I have a Vue app that is used both in the browser and as a PWA. I would like to ensure users receive the latest version whenever updates have been pushed to the server.
I am using Nginx, Django and vue-cli along with #vue/cli-plugin-pwa.
Currently when I npm run build and then push the new version to the server, users get the old version of the app (in browser as well as PWA on their phones). To get the new version they do a hard refresh in the browser or for the PWA they close the app and reopen it again.
Is there a way to ensure a version check is done every time the app is loaded so that the new version is retrieved?
In the end I found this excellent article which covers how to display a notification when an update is available. The user is then able to click the notification which updates the app.
https://dev.to/drbragg/handling-service-worker-updates-in-your-vue-pwa-1pip
Related
I'm developping a simple agenda app in Vue.JS (Quasar) that would be deployed in electron.
In order to enable the user to continue using the app without connection (Make a change to be synced later and view the last version), I am thinking to use Electron Store.
However, I'm not sure if it is a correct choice; or shall I use PouchDB or anything else?
i have a setup where i was using the vuex-persistedstate module to save user settings inside my localStorage.
Now i want to wipe the localStorage only once for the next release. it should be a one time thing to be sure that all users have a clean localStorage for the next release.
instead of telling all users to clear there caches manually i am searching for a way to do it automatically.
my own idea was to use my PWA "Update Available" feature, which triggers the PWA serviceWorker to cache the application and then should do a localStorage.clear() once but that's not working somehow.
the localStorage will not be cleared with that try, all the old data still exists on users machines.
You could add your app version in the localStorage.
Then, when they launch your app, you can compare the current version value (in the JS) with the version value they have in the storage. If it's different, ten you call localStorage.clear() automatically
One alternative I would do is to call an api for version compare.
If the client's version is < than the server stated version.
Then call localStorage.clear().
I have a question regarding to native app version management and direct update on Mobilefirst 8.0.
We may publish native app updates every couple weeks. We want to avoid creating a new app version on mobilefirst console (1.0, 1.1.. etc), unless the update is significant enough for us to force users to update (disabling older version on mfp console.) To achieve that, we have been updating android-versionCode and ios-CFBundleVersion in config.xml while keeping "version" the same. All works fine for previous versions of MFP (6~7). Direct update works as expected.
However, for MFP 8.0 we noticed following scenario behave abnormally.
Package app v1.0 with web_resource v1.0. Submit to app store.
Build web_resource v1.1, upload to MFP console.
--- Download app from app store, direct update triggers without a problem.
Package app v1.2 with web_resource v1.2. Submit to app store. (Note app "version" doesn't change, no new app created on MFP console)
--- new app goes on app store, user receives update notification and decides to ignore it.
Build web_resource v1.3, upload to MFP console.
User decides to open app and receive direct update for web_resource v1.3.
User finally decides to update app through app store.
--- After updating the app, the app runs web_resource v1.2 instead of v1.3. And no direct update triggered. This is not what we expected...
I understand this app version management may not be officially supported but there is an obvious reason we are doing it this way, that is to keep the MFP console app versions from going out of control.
The question becomes.. why didn't app run web_resource v1.3 after step 6? The app storage is never cleared as far as I can tell so web_resource v1.3 should still exist. Even if web_resource v1.3 is invalidated after app update, app should still starts and ping MFP server with web_resource v1.2 and triggers direct update to download web_resource v1.3.
Is there some underlying mechanism that's causing this? I suspect there is another "timestamp/last updated time" stored somewhere that's causing this. I hope this can work as it was in MFP 6~7.
I am testing WSO2-Emm system for managing our android mobile app. We have an app for taxi drivers. We deploy it using our tablets and a single gmail account. Our problem is that google allows up to 10 signed in devices for a single google account.
I have tried to load the apk to the WSO2 store. The problem is that when I want to upload a new version of the same app I get a warning message saying that this APK already exists in the store. When I try to rename it and add it as a new apk it works. The problem is that when I go to App-Management, the application appears under 'installed'. The Emm system doesn't detect there is a new version.
To be more specific, my question is is there a way to manage mobile application versions using the WSO2 store and not the google play store.
If there is a way we can go on with this system. If not, we will stop testing it.
The only way I've figured out how update an already installed app is by going to the App Management tab, selecting your latest version of the app in question, and hitting the install button under the Roles tab (NOT the Users tab). It will send the install command to any devices listed under roles you have checked, even if they already have the app installed. Keep in mind this will install the app on all the devices, even devices that already have the version you're trying to put out.
It looks like you already know about the patch on EMM-686 that must be implemented in order to upload multiple versions of the same app to the Publisher. Just in case you want to confirm it's implemented correctly, see my answer here for instructions on how to implement it.
Title pretty much explains it. Does it render JS from an external codebase so I can simply push new updates through git, or do I need to actually push the changes through App Store?
This is my previous answer, which is getting downvoted into oblivion because it didn't predict something cool like CodePush coming to React Native :)
React Native compiles to an iOS binary. Updates need to be sent to the
App Store, unless you're simply using React Native for its WebView
and rendering an existing webpage on the client.
Updated 6/2/16
It looks like Microsoft has a sweet plugin for CodePush found here that lets you push changes remotely to your React Native app without having to send the update through the App Store.
Here's a quote from the README docs:
NOTE: While Apple's developer agreement fully allows performing
over-the-air updates of JavaScript and assets (which is what enables
CodePush!), it is against their policy for an app to display an update
prompt. Because of this, we recommend that App Store-distributed apps
don't enable the updateDialog option when calling sync, whereas Google
Play and internally distributed apps (e.g. Enterprise, Fabric,
HockeyApp) can choose to enable/customize it.
I'm actually working on a project (with the React Native Playground team - https://rnplay.org/about) that will allow you do live update your apps JS on the fly without submitting an update to the App Store. It's called Reploy, http://reploy.io
We will be open-sourcing the first portion of it very soon (the updater module). There will also be a service that will help you to manage your updates and even deploy your app to TestFlight and the App Store when needed (App Store updates are still needed when adding a new native module or static assets).
Also, just so you know, Apple has allowed this type of auto-updating via item 3.3.2 in the "iOS Developer Program Requirements" document, it says:
3.3.2 An Application may not download or install executable code. Interpreted
code may only be used in an Application if all scripts, code and interpreters are
packaged in the Application and not downloaded. The only exception to the
foregoing is scripts and code downloaded and run by Apple's built-in WebKit
framework or JavascriptCore, provided that such scripts and code do not change
the primary purpose of the Application by providing features or functionality that are
inconsistent with the intended and advertised purpose of the Application as
submitted to the App Store.
https://developer.apple.com/programs/ios/information/iOS_Program_Information_4_3_15.pdf
You could push an update to a remote user if you had linked to an external bundle and had the IP / correct ports forwarded, however Apple do not allow this for released AppStore apps.
For beta testing remote apps you might want to try exponent http://exp.host/
Update---
For completeness, it should be noted that if you are part of the Apple Enterprise program you do not need to publish Apps to the AppStore at all, you can post them to end users via a download link.
I work on a project called AppHub that lets you update JavaScript and images without re-submitting to the App Store. The iOS SDK will be open source, but for now you can use the hosted service to manage new builds of your app.