This may sound paradoxical. My goal is to find a tool which automates the process of logging in to App Store Connect, and click the Make App Available button. This is because my team has an internal process of releasing changes to our products. There are a lot of things to do but we also have tools to automate all of those. So I'm looking for something to append to our release automation tools so the whole release process is completely automated.
Problem statement
Because we need to have full control over the release time. Sometimes, in a company environment, after all the testing is done, we want to release the app, and start monitoring usage on that day. On Google Play, this is not a problem. We can expect an app we submit for release to go live shortly after the submission. But on App Store Connect, with the current submit for review process, we have no control over the review time.
Using Fastlane, setting the automatic_release flag to true, it would mean the app could go live at weekends. If a problem occurred with that new version, no ones would be on hand to quickly fix the issue.
Or the other option, setting the auto_release date, we could still run into the same problem if the review process took longer than the defined release date.
Is there a way to submit for review with the "Manually release this version" option, then, after the approval, have some tools/apis that would log in to App Store Connect and press the Make App Available for us?
You can list all available Fastlane actions on GitHub.
If you can't find a predefined action for your need, it's worth to check Fastlane Spaceship module for low level API calls:
spaceship exposes both the Apple Developer Center and the App Store Connect API. It’s super fast, well tested and supports all of the operations you can do via the browser. It powers parts of fastlane, and can be leveraged for more advanced fastlane features.
While searching in the Spaceship source code I found that app releasing is already added:
for phased release use: release
for immediate release to all user, use: release_to_all_users
I don't have a chance to test this, but the following snippet might help to start if you're not familiar with Spaceship. Put this in Fastfile then call it from where you need:
lane :release_app do
require "spaceship"
Spaceship::Tunes.login('email#example.com')
app = Spaceship::Application.find('com.example.app')
app.release_to_all_users
end
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.
I currently have an app on iTunesConnect with a few hundred external beta testers using it. Important to note, we will have 2000 testers by the end of the month. I want to push new builds to this app- and this, I know how to do.
What I don't know is, what is the expected behavior for my beta users when I add a new build?
Our company cares a lot about user experience, and we don't want to have our current testers of our current build open the version that they've already installed, only to see it crash because I added a new build that i'm hoping will just update their current version automatically.
Apple does a good job of making a developer think this might happen. I've searched everywhere to find this answer in the docs- please help! After selecting a newly approved build to switch to in the External Testing portal, upon selecting Save, this alert appears:
(405 is the first build, 407 is the new build)
So, what happens when I save this- will users be notified that they need to update the app?
Will the "update" happen automatically for them if they've already installed the first build?
If they open the already installed version, will it simply crash?
If so, what can I do to prevent this from happening?
My team will likely want to send out 1-2 builds / week (of the same app, with fixes and improvements) to the same group of testers until we're ready to officially launch the app. I'd hate to think this would crash the app on them every time. As far as I know, there is no way for me to test this before performing this action- I'm already added as an Internal Tester, but that's a completely different UX in TestFlight (builds are made available to internal testers immediately after uploading)
If you think this has been asked already:
This is not a duplicate of this question- because I haven't attempted to send out the build yet. I want to make sure that linked issue does not happen to my testers!
My question is unlike this one where the user did not know how to properly increase his build number, unlike this one, referring to testing a new build of an app that already has a version in the app store, unlike this one which refers to a bug in the app store where a user couldn't initiate an external test after uploading a build, and unlike this one where the user just didn't know how the iTunesConnect portal works.
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.
Is there a way to remvoe TestFlight apps from users that have installed them? Also is there a way that TestFlight can bake into the app some sort of password that the users all have to log in with (in case of a lost phone, we don't want our developement apps exposed).
If left untouched, the provisioning of your apps will eventually expire automatically. Even without the native ability to remove applications with TestFlight there is still something of an expiration date on the application.
That would still leave your question of a "baked in password prompt" and removing the application itself physically from the device.
The first part, the app checking for authentication could be solved by implementing a solution with a more robust SDK that happens to have that sort of security-minded approach. As far as I know, and based on TestFLight's feature grid, this exceeds the abilities of their tool.
The second part, removing the application itself from the device, would be accomplished by using a tool that has the ability to use MDM (Mobile Device Management) for device-level control. Specifically you'd want to look for something that can selectively control a single application, rather than having to apply a blanket MDM policy. Again based on knowledge of TestFlight and based on their web page this is also not something TestFlight is capable of.
There are solutions out there that will give you exactly what you are asking about - easy beta testing with the added ability to force the app to check in and re-authenticate as well as the ability to remove applications from the device when you're done testing. If you hit your search engine of choice you can find a few tools that will give you a "yes" to all of your questions here. The list is very short so they're easy to find. :)
If it is at all helpful to you, I am associated with one of those companies, AppBlade, and would be happy to answer questions about this sort of thing. We're at https://AppBlade.com and you're welcome to give us a call or even log into the tool to see how it works for yourself.
Unfortunately you can't delete apps that are already installed on the device via TestFlight, unless you do it on the device itself. As for the password, TestFlight doesn't exactly support that either. You could however put a passcode lock feature in all of the Beta versions of your apps through your code. Sorry thats probably not the answers that you wanted to hear, but TestFlight is still in its early stages.
You are not able to delete apps from a users device, however TestFlight is testing in their 'Area51' an option to force users to update to a new build if there is one available.
If you no longer want testers to access your app you probably could add a new build which justs shows some info screen.
There is a way to expire the builds in the app store connect when you click on build.
Another way if you want to get rid of it as a tested to open the app page and click on stop testing.
My application is in the Apple App Store but when downloaded it crashes after the splash screen.
I thought the week long approval process was to ensure the quality of the app.
Version 1.0 of my app does run but I hear there is no way to roll it back. For now I have changed the availability date to the future so that people do not download it. When will it be taken out of the search results?
Thanks.
The approval process is not for QA testing. (Of course, they will reject an app if it crashes while testing they are other for things, such as violation of various SDK rules, HIG guidelines, etc.) A developer has to test and QA your apps themselves on the OS versions and the iOS device types for which they submit the app as appropriate for, and under stress conditions as well. A developer also needs to make very certain that the build they submit is identical (except for certificate signing) to the builds they have tested. (It is a common mistake to have different Build Settings or source files selected between the Release and Distribution builds.)
Check to see if a bad preference setting is the culprit.
Or if it worked only for you, then it may be the lack of a preference setting. You may have created a good preference before the bug was introduced.
Was taken out of search results by the end of the day.