The first version of our app 1.0.0 was uploaded and approved by Apple and currently, it has a status "Developer Removed From Sale". However this version has severals bugs and some features are missing, so we decided not to release it, to improve it and release another version.
So, we uploaded another version 1.1.0 after some time, and currently, it has "Pending Developer Release" status. The funny thing is managing guys decided to add yet another features, so we will have to upload the third version.
The question is will the second approved app version (1.1.0) be there after uploading the third version to itunes connect, or will it be deleted? We definitely don't need the first version because there are bugs but it's unable to delete it even if it was not released to app store. But I would prefer to have the second version until the third be approved (just in case).
The current approved version will remain Ready for Sale (wether you choose to put it live on the App Store by making in available in one, some or all countries or not) while the Update is Waiting for Review, In Review, and Processing for the App Store, and will be removed when the Update's status goes to Ready for Sale. (It will also remain should the Update be Rejected.)
Related
I have a problem with automated build distribution thru Fabric Beta with concurrent uploading.
For example I starting upload of first build and 5 seconds after it I starting upload second one. But because Internet is a magic-unstable-box the second build have uploads before the first build. And it's treated as first build is newer then second. But it's not true.
So I want to discard older (first) build when I uploading newer one.
Or I want some other workaround for my situation.
Mike from Fabric here. There is not an automated way within Fabric to stop the upload once it's started. You can manually remove versions via the app's settings page. From the documentation:
To remove, a specific version of your app, head to your app’s settings. Select the app whose name you want to change and click on the “Versions” button. After that, select the toggle on any build or version you want to disable. Disabling a version prevents new crash reports from flowing in, hides it from the version filter, and prevents beta testers from installing that version.
I participated in the Affectiva Hackathon, when their license was the 30 day free trial. I was excited to hear they have changed to allow those not trying to sell a free license. However, when I tried to convert to the updated free license when I try to launch the android app on my phone: "Unfortunately, Good Vibes has stopped." Good vibes is the app name.
I have followed the steps outlined on Affectiva's web page
However, I kept everything at 3.0.1 rather than 3.2.0, as I developed the app and it worked fine using the 3.0.1, and I'm just trying to get it back up and running with the updated license.
I believe the issue is that I need a new actual license file. In the original app I had a mylicensefile.license stored in my app/src/main/assets/Affdex directory. This stored the expiration date information and it was incorporated in the code like this:
camDetector = new CameraDetector(context,CameraDetector.CameraType.CAMERA_FRONT, cameraPreview);
String licensePath="mylicensefile.license";
camDetector.setLicensePath(licensePath);
So, my question is where do I get another license file? I don't see that anywhere in the instructions.
The Android SDK can be used without a license since v3.1.1.
I would suggest upgrading to the latest version. This states that the license API's have been deprecated. You can check on the developer-portal to figure out if you qualify for a free license.
I am trying to update my app for the first time and ran into this issue. I searched a lot but none of the solutions worked for me.
App Store Connect Operation Error
ERROR ITMS-90062: "This bundle is invalid. The value for key CFBundleShortVersionString [2020.0] in the Info.plist file must contain a higher version than that of the previously approved version [2020.0]. Please find more information about CFBundleShortVersionString at https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring"
And my info.plist file is :
General Window:
TL;DR: If you have an app version that was approved for the official app store, you cannot upload a build with the same version to TestFlight. You have to remove the app from official app store submission, or increase your TestFlight version #.
I figured out why this happened to me.
I have an app in the app store with version 2010.
I have been running an external beta test with version 2020, and build numbers in the range of 400-410
In order to discover if my app would get rejected in the app store once I'm ready to actually release it in a few weeks, I submitted version 2020, build 407 for official app store review. I expected it to be rejected for various reasons. It was approved! However, i'm not ready to release it since I still have more fixes I want to implement. So, I let it sit there, waiting for me to do something with it.
Then, I wanted to upload a newer build for my External beta, still version 2020, build 410, and I received this error.
Thanks to user462990's answer, I realized that the error could be due to the fact that I have version 2020 currently approved and waiting to be launched into the official app store, so iTC didn't allow me to submit the same build # for a TestFlight external beta.
So, I selected "cancel this release" of the official approved version, and Viola! I can now upload a build with the same build #.
I think it was some issue on Apple's side. It resolved itself automatically after few hours.
What worked for me is to change it from 1.0 (.6) to 1.1 (.0) It's not really a new "Version" but incremental improvements and corrections. One thought is that when an app is accepted into the iTunes store then next upload must be to a higher VERSION.
You must always increase the version number when uploading updates, so change it from 1.0 to 1.1.
I'm having a similar issue today. I uploaded a new build a couple days ago with no issues. I found someone who posted a similar issue here: https://discussions.apple.com/thread/7297092. They were able to resolve it by changing the Info.plist values in their sub-projects, however, I tried doing that, and I still ran into the same issue.
I cannot find any information on why this is occurring or when this started, but I know that I uploaded a prerelease build to TestFlight with all of the same projects 5 days ago.
I currently increment my prerelease builds this:
1.10 (1) -> CFBundleVersionShortString (CFBundleVersion)
1.10 (2)
...
I was up to 1.10 (7), which I deployed 5 days ago. Now, I can't get anything to work 1.10 (8), 1.10 (9), 1.10 (1.10), etc. They all say "CFBundleShortVersionString [1.0] must be greater than previously approved version [1.3]"
1.3 is correct as the previous version available in the store, but clearly, 1.0 as the Bundle version is not.
I ran into this issue when going from version 1.141 to version 1.15. Apple does not treat the version as a decimal number - they treat it as multiple integers separated by periods. Thus in my case Apple considered 1.141 to be Major version 1, Minor version 141 and then my new version was Major version 1, Minor version 15. Since 141 > 15 it fails.
Two options to deal with this:
Use Apple's interpretation of version numbers, so you always increment the minor version by 1: 1.1, 1.2, ... 1.9, 1.10, 1.11.
If you wish to use "hundreds" or "thousands" places (I do, as I try to encode the scope of the build in the precision - I use the thousands place for minor bug fix releases), then always pad them out with zeros: 1.10, 1.11, 1.20, 1.30
So in my case I went from 1.141 to 1.150 and I was able to upload.
Our product version follows Semantic Versioning with an extra digit for build package identification:
major.minor.patch.build
The first 3 parts are for source code versioning, depending on API compatibility and bug fixes (patches). The last part is to keep track of multiple build packages. Multiple builds can happen with no source code changes (therefore no changes to major.minor.patch). Reasons for multiple builds are numerous all relating specifically to Android APK packaging (such Icons missing/changed, minSDKVersion increases, permission changes, SDK updates, descriptor-file changes [we are using AIR], etc)
Unfortunately, Google Play does not recognize this 4-part version. It only recognizes the first 3 parts. Example:
2.3.1.1 - Uploaded, received warning about SDK/API min version mismatch.
2.3.1.2 - No source code changes, only bumped minSDKVersion in manifest.
As far as Google Play is concerned, both are version 2.3.1 (2003001)
Why does it matter?
In order to test In-App-Billing (IAB) purchases, a version has to be published to Alpha (or Beta or Production). Once published, you cannot upload another APK without incrementing the version. As far as we are concerned, we are incrementing the version, but Google doesn't recognize that. For us, to bump the patch number when there were no source code changes is stupid and goes against the company versioning scheme which spans many more platforms then just Google Play.
So what to do for IAB testing?
- We distribute APKs to QA internally (not through Google Play), however we are still required to publish an APK to Alpha in order to test IAB.
- Without publishing an APK with increased version number, IAB testing errors out (APK version on device cannot be higher than the latest uploaded APK in Google Play)
How do others handle this?
My standard route has been to go to confluence, find the docs sections, then navigate through to the install docs for the version, e.g. sakai 10:
https://confluence.sakaiproject.org/x/iYGLBQ
Through one means or another I happened across the source route to this too, so starting here....
http://source.sakaiproject.org/release/
You get redirected to the latest stuff, and appended version numbers to that url gives you other docs, e.g. adding 2.8.2 or 10 to the end of the url
But the links to what I should download are quite often not there, at the time of writing the 10 tar ball and zip in the confluence links are dead and the source.sakaiproject links doesn't have the 10 docs yet (redirects to 2.9.3) presumably this is because v10 is not released yet....
So, I'd like to evaluate a new version of a sakai source install, what's the best way to do this? (considering the official documentation for install is still being formed)
Do I download the latest SVN, or the latest RC or the latest beta or??? How do I know what's best to test against without being "too" bleeding edge? Is there a recommended tar ball/zip link to test against? Is there a "latest good" SVN branch?
The latest code is always in the Sakai trunk (currently svn):
https://source.sakaiproject.org/svn/sakai/trunk/
That code may very well not be stable though as it is where things are being actively developed. If you are not actively developing then you should stick to the releases as indicated on the project website here:
http://sakaiproject.org/current-release
If you want to use something in between (say an upcoming release) then you can grab the most recent tag or maybe use a recent branch (both currently in svn, latest shown below at the time I write this):
https://source.sakaiproject.org/svn/sakai/branches/sakai-10.x/
https://source.sakaiproject.org/svn/sakai/tags/sakai-10-rc02/
The reality of the situation is that if you want to use something other than the release then you should really participate in the dev community for Sakai. Joining the mailing lists and the weekly calls will provide the information you are asking about and much more.