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.
Related
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.
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.
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 have an app on the Store for which we’re readying an update.
The other members of our team have the App Store version already loaded up (~purchased) on their respective iPhones -- and those contain User Data which each member needs to be able to keep.
In the meantime, we need to test out a Beta version of the next version of the app.
Presumably, we’d need to have the two versions (ad hoc, and app store) co-existing on each device, at least until everyone’s signed off on the beta and it’s uploaded to the store (at which point, they'd delete the beta version).
[Once it’s on the Store, of course, they can each update their main (i.e., Release) version of the app via the usual App Store 'update' mechanism. In that case, all their user data is still retained intact.]
So assuming that’s the proper workflow ...
How do I issue a Beta to the team, and have it not replace/overwrite the existing App Store version?
I’ve tried customizing parameters in the beta’s “[appname]-Info.plist”, but haven’t found a setting yet that allows the two versions (beta and release) to co-exist on the same device.
Any ideas? And is this is the proper approach to them being able to keep their data?
(And last, how might I do it with & without a script? I assume there's just one parameter that'd need to be changed.)
I hope this all makes sense -- thank you in advance for your help!
So you want to have two versions of the same application on one device? I don't think there's a way to get this effect -- updating an application, which keys on unique CFBundleIdentifier, replaces old version bundle but not data.
For the effect you want, you must have two distinct applications. They need different CFBundleIdentifiers, so they won't overwrite each other. They then cannot share data, so you'll have to arrange for export/import involving an off-device shared space.
If you don't want this hassle, issue the team extra devices and test on those. The team's primary devices remain on the AppStore version. You must still export/import to bring content from the test devices to the primary devices. Any paid content each has on the App Store version should be available for their beta, though, as usual for app upgrades and one-owner multiple-devices scenarios.
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.