How can we make the flutter app to make automatic update whenever we release a new version of the app into the store. but I don't want to use the pop up to alert the user to update I want to update automatically without letting the user even know we update it.
As said in the comment, if you publish to Google Playstore or iOs AppStore, they will handle the updates for you. You just have to upload the new version (just set the release number correctly) and, when the validation is done, their system will notify/update the app. I don't know how other stores behave, but I'm guessing that's the standard behaviour now.
Instead, if you need to bypass the store functionality and perform the update "by yourself", I don't think that is gonna be a simple task. Apple simply doesn't allow installation from other sources than their store, so I fear it may be simply impossible. On Android, on the other hand, I know that's possible, but it will require some user interaction beforehand, since the "installation from unknown source" authorization must be provided to the app that downloads/opens your .apk file, and the procedure may vary from a device to another, so I fear there won't be a single mechanism that will work everywhere.
In any case, the base mechanism will probably require some HTTP GET by your app towards some webserver that will reply with the latest version: the app should then compare the received version number with its own, and then proceed to the download of the package (the URL for the download can be provided along with the latest version number). After that, you have to manage somehow to install/update the downloaded file.
I personally used this approach with Flutter on Windows 7 and newer, where there are no store constraints and I can simply run and download the .msi or .exe file for the latest version, and works just fine.
I think you are looking for the concept of codepush which was loved by many React Native developers.
In Flutter, I think you might want to check out flutter_code_push if this fits your needs.
Related
I am trying to make a system for checking version numbers of an application and prompting for updates, I would like to use Application.version for this.
Unfortunately I'm having some difficulty finding out where the version is set or where unity acquires the number from, at least on desktop platforms.
Has anyone had any success with setting version number in the editor or is this a post build step?
This is more likely to be handled by the store, it will show in the update section when a new version is released.
If you need to inform in game, then you would have a value stored in the app and a value stored on a server, compare those, if not the same, you put a banner with a link to the app store page of your app.
I had a serious bug in my itunes latest updated build. I want to restrict users to update the current version. How?
any suggestions will help me a lot.
do you mean you want people who have the buggy version to update ?
unless you have push notifications setup with your app, or a means to display them a message, or have their emails as part of a sign up process, your very limited to what you can do.
If you have published the new version, just make it clear in the version notes that this includes a bug fix.
Currently, there is no functionality built into the App Store to force updates.
In your initial version, you should add a way to force updates, and then test to ensure that it works. Typically, you will have a callback to the server and a way to display a message and link them to the update in the store.
If you don't have such functionality, and you are making any API calls, you can add a version number to the API call, and if the version isn't sent, then you can refuse access, and preferably send them a message.
Can I force a user to upgrade my app? Does Apple recommend it?
Yes, you can. Just check the version number when the application starts and if needed, bail out with an error screen. I don’t think Apple explicitly prohibits this. (And I doubt they would find out during the review.) Of course it’s annoying from the user’s viewpoint, I would only write something like that if there was no other option.
Yes you can force an upgrade to the user. You can call a webservice when your app start and check on your server if an update is available (you have to add an update when an update available on app store). If an update is available then you can present a view that will have the update button. When pressed this button will redirect the user to the installed app store app and open the upgraded app in it. (you should return this url in your webservice). Let me know in comments if you need more explanations.
And I don't know apple recommend this way. But I have seen this in one or two apps.
Extremely bad approach. My perfectly fine working app forces upgrade, which can not be supported due to obsolete iOS. I am not only forced, but moving away from the coupon app in determination to never use it web-based either.
Security issue, if that is the reason for upgrade, should be patched for existing iOS.
I have an application already on the store and would like to release an update. Since my app deals with databases and I've had to change some parts of it, I would like to ensure that the update does not affect the existing functionality in any way once the user updates from the App Store.
What I did was this - install the first version of my app on my device. Changed the update's version in info.plist to 1.1 and run it via xcode (and install on my device). But what happens by doing this is some of the changes I made to the XIBs do not show up. It looks as if the app was only half-updated (if you know what I mean)
Is there any way to update an existing app programmatically without having to go through the app store and then find out it could lead to a disaster?!
Thanks for any help!
I would double check your build configuration. Between building the two versions of the app, I would recommend a "Clean All" just to be safe. The process you described works to verify updates. The only other alternative I can come up with is to create Ad-hoc distributions of both versions of your app, and install those.
I am near the end stages of developing an iPhone application and will be releasing it as both a 'lite' (ad-supported) version and a 'pro' (ad-free, likely with additional functionality at some point) version.
I've followed suggestions here and elsewhere about creating multiple targets, etc. and am able to build these without any problems.
But this does bring to mind a question: What is the best, most user-friendly, accepted way in which to handle transitioning from a lite version of an app to a pro version?
As I see it - and please correct me if any of my assumptions are wrong - there are potentially two ways to do this:
Give each application its own Bundle identifier (ie. com.companyname.fooapplite and com.companyname.fooapppro). This will result in both being treated as being completely separate entities. Data is not automatically migrated should a user move from one to the other and both could very well have both installed on the same iPhone at the same time.
Give each application the same Bundle identifier (ie. com.companyname.fooapp), so that they are treated as essentially the same application. The lite version of the application will be overwritten by the pro version if they download and install it. Data from the lite version is maintained in the pro version.
The latter seems ideal to me - I can't imagine someone wanting to keep a lite version after they've just purchased a pro version - but this brings up a few questions:
Does Apple even allow option #2?
Will using option #2 result in any goofiness I should be aware of, ie. the two versions stepping on eachother in some way.
If it's not allowed, is there a suggested practice in place to migrate data from what are basically two completely different applications? I'm aware of StoreKit, but it isn't supported on free applications.
As it is, this current app doesn't really generate data of huge value and the worst thing that will happen is users will have to re-enter some authentication credentials upon upgrading to pro. But down the road, if I were to develop a similar app that stores valuable data locally, I'd like to know how to best transition users and their data in a seamless manner.
Thanks,
Jeff
One more option is to exchange data from the Lite to the Full version via a URL. Register a myFullApp URL with the full version and have the Lite app present an upgrade option that calls that URL with the various data you want to exchanged encoded in it.
That does require the user fire up your Lite version and hit a button, but it's fairly simple too.
I have not tried this myself, but a third option to exchange small amounts of data is to use the Keychain API. Apps that share an identifier stub -- com.companyname.foo as a parent to com.companyname.foo.fooapp and com.companyname.foo.fooapplite -- can supposedly write to the keychain from one app and read from the other. Haven't seen this done, but a lot of people claim it's possible. And in any case, the keychain is probably a good place to be storing things like authentication credentials.
Option four would be to have the lite app store some user data on a server you operate, and have the full app retrieve it from there, but there are all kinds of problems with that approach.