With Direct Update, the mobile application can be automatically update with a new version of the web resources. In order to update the native resource, a new version of application must be uploaded to application store.
Consider the case that I have an update for my Worklight app with both native and web resources code update which has already been in application store.
Questions:
Is the following a correct way to update the app?
Step 1. Package the app in .ipa / .apk (with native + web code) and submit to application store
Step 2. Deploy an updated .wlapp file (with web code) to Worklight Server.
In application store, I can specify the application version when uploading the application. Will the application version be incremented automatically once I deploy the .wlapp to Worklight Server?
If the user does not update his application in application store and open the application, since there is a new web resource update in Worklight Server, it means that there will be a direct update alert box to prompt the user to download the latest application and in this case only web resource will be downloaded. There are some problems when the native code and web code are correlated?
Thanks a lot.
This would essentially be the correct order of steps, yes.
However, since you say you're updating both the native and web resources, I would make sure that the existing app can work with just the web resources update (without updating the native), because once deploying the .wlapp to the Worklight Server, existing users will receive a Direct Update.
If this scenario is not one you want to support, then in application-descriptor.xml you should also up the value of the version=" " attribute in the environment's element. When building the app after doing so, this will create a new .wlapp (for example: myProjectNameMyAppName-1.1.wlapp instead of ...-1.0.wlapp).
This means that the existing 1.0 users will not receive any Direct Updates, unless you deploy an updated ...-1.0.wlapp to the Worklight Server.
In relation to the above, no, the application version is not incremented automatically, it is something you need to control manually.
Also, I don't think the version value is something you control in the application store interface...
IFAIK the application version is changeable in Xcode prior to creating the .ipa for iOS and in AndroidManifest.xml prior to generating the .apk for Android (and in similar fashion for other environments).
EDIT: Actually... I think that changing the version value in application-descriptor.xml will also up the application's version number. Need to look at the end result (in AndroidManifest.xml or the Xcode project, in Xcode).
This would really depend on the behavior of your application and how resilient you've written it to be in the face of updates. I have slightly covered this in #1 above.
Other than talking about it theoretically I would suggest taking the jump actually upload an app to an application store, and test it privately, of course. This would be the most convenient to do using Google Play where publishing an app is near-instant.
Related
Today we have an app in applestore with a version labeled as 7.6.2 and internal build number as 1.0.0. We are using mobilefirst 7.1 to develop. Problem is that now we have a new app, that is 7.6.2.1, but we would like to know if is possible continue to use 7.6.2 app from applestore onto 7.6.2.1 mobilefirst app (asking it because we would like to keep our customers using just a single app from applestore). We also have an app on google play and would like to apply same idea.
Maybe this is an edge case, so do we have a way to control this directupdate by ourselves?
Customization of direct update is limited to the UI and options when you receive a direct update push.
As for version management, if both versions 7.6.2 and 7.6.2.1 are deployed in the MFP server, end users can have these versions deployed on their devices. Direct update or other configurations can be separately configured for these different versions.
However, if an end user is on v 7.6.2 and they take an update from AppStore or Playstore, and the version on the device becomes v7.6.2.1, this updated application on the device will start connecting to only v7.6.2.1 in the server. And only direct updates this version on the device ( 7.6.2.1) will receive are the ones uploaded to 7.6.2.1 in the server.
Direct update feature is meant only to push small web resources changes into your application. If the MFP Application Version numbers for both app versions(i.e 7.6.2 and 7.6.2.1) are different, you can continue to use both the versions and push direct update indvidually based on version number.
I wonder how direct update works. What is the full process (checksum, build version, etc.) that links the war, wlapp and the apk or the ipa files in order to show direct update notification when the application is launched?
You can find this information about Direct Update in MobileFirst Platform Foundation 6.2 - 7.1, here: https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/7.1/advanced-client-side-development/using-direct-update-to-quickly-update-your-application/
The .war file is not related to Direct Update
The .apk and .ipa (binary files) are not related either
Direct Update relates only to the web resources that are bundled in the Hybrid application.
When you want to make such an update you need to:
Update the resources in your project
Build the project, which generates an updated .wlapp file
Deploy the updated .wlapp file
Now the server holds updated web resources for the application. As part of this a checksum value of the web resources is stored in the server. A similar checksum value is also stored in the application.
The next time the application attempts to connect to the server, be it via WL.Client.connect or an adapter request, the server will will compare the checksum value of the application (which is send as part of the request to the server) with the checksum value it has stored. If the values differ this means that the server will serve the updated web resources back to the application.
Notes:
If you are using MobileFirst Platform Foundation 7.1 the frequency of checking for an update is determined based on your token expiration value. Refer to the link above to learn more about this.
Direct Update works only on the same app version. i.e. if your application is at v1.0 and you want to update it using Direct Update, make sure that when building the application in MobileFirst Studio, the environment version is also set to 1.0. If your application is at a different version, Direct Update will not be done due to version mismatch.
I am developing both Android and iOS B2C app (will upload it to Store). Reading from here, it seems there are some restrictions for Direct Update.
- The update is for the app web resources only
- To update native resources, a new app version must be uploaded to the respective app store
- Android: no restrictions
- Windows Phone 8: no restrictions
- iOS:
B2C: according to the terms of service of your company; usually at least bug fixes are allowed
B2E: through the iOS Developer Enterprise Program
But the requirement is:
User want to update some .txt files in production without want to use Adapter.
Is this allowable and able to be done as in the doc saying for web resources only?
I don't know how do you intend to use this "txt file" in the application but I am pretty sure you can classify it as a web resource without worries.
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.
We have already delivered the 1.0 version of our Worklight application. By mistake we have disabled the Direct update feature by updating the attribute "connectOnStartup = false"
We dont want to redeploy the application to markets (AppStore/GooglePlay) again, but wanted to make our users to utilize the direct update feature. We do have the access to WL server.
Our issue is little different from the one which is already discussed here "IBM Worklight - How to disable Direct Update?"
How can we provide the direct update feature to our end users without redeploying the application to AppStore/Googleplay. And just by changing the Webresources of the application.
We are using the adapters in our application but no where we are explicitly calling the "WL.Client.connect".
The Direct Update feature is always enabled by default.
You need to edit your question and explain what it is you've done in your Worklight project.
The feature will not work if:
You have set connectOnStartup:false
You are not using WL.Client.connect
You are not invoking adapters
You disabled it via the checkbox in Worklight Console
Otherwise, the feature will work, and a check for Direct Update will be performed:
On application startup
On return to foreground
The application will need Re-deployment on the App stores.
So the solution to your problem is
Rebuild the Application with connectOnStartup:true.
Redeploy the Application on App Stores
Once the users download the updated application, future updates will go to the users directly.
While rebuilding, make sure that you change the Version of your application within ApplicationDescriptor.