I submitted my Full and Lite version of my iOS App to the Apple App Store for an incremental release (1.2) - both Apps are already For Sale. I added In-App purchases to my Lite version.
My Full version was approved, but my Lite version was not. In discussing with Apple, they have provided a screen shot showing that they can't access the In-App functionality in the Lite version, but the screenshot is from my Full version, which doesn't have that functionality.
I'm appealing, and am hopeful that they will address.
This is the first time any App I've had was rejected, and I have several questions that I would appreciate any suggestions from developers who have gone through this.
Is there a way for me to run the exact code that I submitted from the Organizer/Archive so that I can verify that my Lite version is indeed the Lite version and not the Full version? I can see them in on the local file system, and there are 2 different, distinct files that have different sizes.
If I have to rebuild my App and resubmit can I do that from the same archive that is in Organizer?
If I have to rebuild, I think I'm in a bit of trouble, because I've been heads down on the next release for the past week and a half. Is there a way to access the version that was used to build the archive?
thanks.
You can resign the released version to be an adhoc version and run it on your device.
If it requires a new build it won't let you submit with the same version number which will probably stop you from using the same archive unfortunately.
It has been my practice to make a snapshot for every release for this case. If you don't have a saved snapshot or if you aren't using source control then you may be out of luck on that one.
Related
I've just published an app on Apple's store and I'm wondering about having multiple versions of the same app for testing on TestFlight. Of course dev doesn't stop when publishing... from now on I'll have to update the app store version (v1.0.0) with bug fixes (v1.0.1, v1.0.2, ...) and before doing so I'd like to check them in test flight to ensure the fix was appropriate.
My problem is that I'm already starting to develop the next version with further functionalities of the app which will become v1.1
So ideally I'd like to have my app available both for my bug fixes, for instance v1.0.2 and also my next version v1.1.0 (this will include all bug fixes made to the store version and also many new features, refactors, redesign, etc)
I know that if I build and upload to the apple store connect a build with v1.1.0 (next version) I won't be able to upload one for a built with a bug fix on the current app store version (v1.0.2) since this version would be lower than the one I uploaded (next version)
Is there a way to accomplish this? I've read this article https://savvyapps.com/blog/using-testflight-to-distribute-multiple-versions-ios-app which solution is to create extra applications in iTunes with different app ids and bind them to different certificates. But what will happen when the next release is ready to be in the store? I would have to release it and then disable the previous one? How may this affect my users? Will they have to re-install a new app rather than updating it?
I really need to start testing and checking the next release of my app in TestFlight and also support the current one with updates if something pops up. Thanks in advance!
I am able to upload multiple versions of the app to TestFlight. Each upload requires a higher version/build number, but you can switch the TestFlight test version between them as need be for testing.
Once I submit a particular build for release, however, I seem to lose the TestFlight access to the old builds.
In short, you can have many builds available in TestFlight, but once you submit the app for release, you have to start over making builds for TestFlight.
You keep talking about numbers like v1.0.1. That looks like a public-facing version string, with a major, minor, and patch number.
But that is not what TestFlight cares about. Well, it cares to some extent. But all TestFlight really cares about is that every new build you upload has a new build number. This is just an integer which you simply increment every time you submit a new build.
So you could have v1.0.1(23) on the App Store, and then on TestFlight you could upload v1.0.2(24) which starts moving forward toward version 1.0.2, but also upload v1.0.2(25) which is actually an attempt at a prospective version 1.1. TestFlight doesn't know or care what these different builds signify. They can all exist simultaneously on TestFlight. Keeping them all straight and on their individual trajectories is up to you.
We want our testers to be able to:
1) Replace an installed Tesflight version of our app (test-version) when installing the App Store released version of our app (app_store-version) without loosing their data (all inside the app bundle, Core Data and other DBs, Keychain data, User Defaults).
2) vice versa
Replace an installed app_store-version with an test-version without loosing the above mentioned data.
The only information I found is in the Testflight documentation:
...If you already have the live version of the app installed on your
device, the beta version of the app will replace the live version.
When you’ve downloaded the beta app, you’ll see an orange dot next to
its name that identifies it as a beta. ...
I did not find any information regarding the opposite case (... if you already have a test-version installed, the app_store-version will replace it...) nor if the above mentioned data is kept when replacing the app.
Apple Developer Support told me that they do not have this knowledge. :-/
My Questions are:
1) Is is possible to replace a Tesflight version of our app (test-version) with a App Store released version of our app (app_store-version) without loosing the above mentioned data?
2) Is is possible to replace a App Store released version of our app (app_store-version) with a Tesflight version of our app (test-version) without loosing the above mentioned data?
3) If 1+2 is possible, which parameters are taken into account to replace/ not replace an app? (BundleID only, BundleID & BundleVersion ...)
You can override TestFlight and App Store version like regular updates. But, in order to do that, the Next Version should have a build number greater than the installed one.
That means that you cannot install the TestFlight version, release it on the App Store and upgrade, because the build numbers will be the same
I have 1.1 version of my application already in review process now I also want to upload 1.1 version of the application for review process.
So that if anything bad happens to version 1.1, I could directly release 1.2 without going through review process (as it would have been done already). So, I want to send two version of my same application to appstore review process.
Is it possible. If yes then how?
No, you can only upload one version of the application for the App Store review process. But You can have multiple versions in your application in TestFlight. We can even have greater version of the application available on TestFlight from the current version which is under review.
You can refer here if you want to know more.
No. You cannot submit multiple versions of the same app when it is already in review. If you're unsure of the current version, you can anytime remove the binary and upload new version. Also to avoid app rejection, you can go through the App Review Guidelines for once.
https://developer.apple.com/app-store/review/
Also in the below link you can find new rules and changes in existing ones :
http://www.appstorereviewguidelineshistory.com/articles/2017-06-08-new-rules-following-wwdc-2017/
You need to cancel the current version in review to put another version.
I wonder if there is any way to distribute different versions of same app (same means same bundle id, same account) in Apple Appstore.
Lets say, I want to distribute, MyApp (com.stackoverflow.myapp) version v1.2 but there is already a version v1.1 open to public. Is it possible to keep both version open for public. And fixing issues and release different sub version like, v1.1.2 and v1.2.2.
As far as I know with single bundle its not possible. But still I am curious if there is any workaround.
When you release a new version on to the app store, you can now select an option for a "phased release", where the update is shown to current users incrementally over a 7 day period, but at the end of that seven day period the updated version is available to everyone. Also, new users will get the latest release when they install from the App Store.
You cannot maintain two "active" releases on the store.
If you want to test a new version or new features with a limited set of users then TestFlight may be an appropriate tool.
You can use whatever versioning system you want (such as semantic versioning), but you can't distribute multiple versions of an app at a time without uploading them to the App Store as 2 entirely different apps
I released an update for my App and it was approved. It was approve despite the fact that it included a serious localization bug where most users are getting the wrong language. Is there any way to quickly revert back to the previous version, suspend current downloads of the current version, or anything else that might help aid this issue?
I did read the following thread from a couple years ago:
Can I revert to my previous version app in iTunes Connect?
I was hoping maybe there is a more painless solution to this now.
Btw, I did thoroughly test the version before it was added as a new version. So, I'm still not entirely sure what's wrong or how to fix it.
It is not possible to revert the app version. You can upload the previous version as new version again to fix this.
One thing you can do is : "Expediting an App Review"
Please check the following link.
https://developer.apple.com/appstore/contact/?topic=expedite
Thanks
Here's a snippet from iTunes Connect Help page :
Question: The new version of my app on the App Store has a bug. Can I use a previous version to replace it?
No. You cannot revert to a previous version on the App Store. You must submit a new version.
Source : iTunes Connect FAQ
Obviously the alternative would be to submit a new build but ask for expedited app review.
But that means that either your app is event-related or you have a critical bug that you need fixed as soon as possible.
I believe that you can prepare for problems by creating a fallback version with a higher version number and submitting it for approval with manual publishing. That should cause it to be quiescent in your store until you choose to fall back, and you publish it.
I am not certain whether you can then submit improved versions with a lower version number than your fallback version.
I had to do this recently. I was able to adjust a previous version archive. I started by copying the archive and opening the copy, then editing the info.plist files, adjusting/incrementing both the version and build numbers at both the archive and app package levels. Then uploaded to iTunes, which recognized it as a new version.
Preface: I agree with the other posts here that you can't perform a rollback through the iTunes Connect itself. Even if you could, you'd suffer the lag time it takes for users to update to the rolled-back-version. But that doesn't mean we can't still rollback apps.
Retroactively, you cannot rollback an app. Proactively, however, you can instrument your app to enable future rollbacks after a build has been released and installed.
High-level steps:
Build each version of your application as a framework
For each release build, include both the current and old framework versions
On app boot, decided which framework to load and execute (include sane defaults)
When you want to rollback, update the cached values across all user devices and wait for the next app open.
This strategy uses similar mechanics to feature flags which are commonly used to enable/disable features without re-releasing. However, in this case, you're "feature-flagging" your entire app version.
Is feature flagging between embedded libraries against App Store Guidelines?
No. Embedding two versions of your app into one release is not against App Store review guidelines:
4.7 HTML5 Games, Bots, etc.
Apps may contain or run code that is not embedded in the binary (e.g.
HTML5-based games, bots, etc.), as long as code distribution isn’t the
main purpose of the app, the code is not offered in a store or
store-like interface, and provided that the software (1) is free or
purchased using in-app purchase; (2) only uses capabilities available
in a standard WebKit view (e.g. it must open and run natively in
Safari without modifications or additional software); your app must
use WebKit and JavaScript Core to run third-party software and should
not attempt to extend or expose native platform APIs to third-party
software;
Similar to feature flags, all code that you plan to run is included in the binary that you submit for review. What's more, as long as you are rolling back to releases that Apple already reviewed and approved, you're not breaking the spirit of the guidelines.
Does this hurt performance?
I've profiled this approach against many of the popular and heavy open-source iOS apps including Wikipedia, Signal, Firefox, etc. You can be smart about deduping assets and shared libraries, resulting in a sandwiched-app-bundle size of about 1.2x the original size (really just depending on how much code you changed). You also incur about a 50ms startup cost when choosing which version of the app to boot.
IMO, both time and size increases are worthwhile in return for the ability to selectively rollback users experiencing issues while you take time implementing a fix.
Do real apps do this?
Major apps feature-flag between dylibs all the time when launching new features and optimizing performance. I have also heard of major tech companies using this app-level pattern for their largest releases. I have a personal app in the App Store using this pattern, and I have helped other developers do the same.
How can someone do this for their app
If you are comfortable going deep on the Xcode build system, you can follow the steps outlined above and with some fiddling, start feature flagging your app version on boot. Note that you'll also need some form of caching and a server endpoint to update the on-device flag.
The implementation described above is also exactly how screenplay.dev implements iOS rollbacks. The tool:
Adds two build targets to your Xcode project, one for building the framework version, and one for bundling the final release build.
Serves as a repository for your old app build versions.
Provides a web UI for toggling live versions.