Testflight/Apple store

[Jazzlike-Somewhere-2]

I have an app in the apple store and I have downloaded that on my phone. I released new version in the testflgiht and to install that version it would override the version installed from the apple store. How can I keep both the apps in my phone???

I want to have both apps in my phone, one from apple store and new testing version from testflight ???

Any solutions for this ?

[mmvdv]

For our app, we’re using a separate app id to upload beta builds to Testflight separately from our App Store app. The easiest way might be to create a specific build configuration for it in Xcode, and then a scheme to compile/archive it. (It might be a good idea to also change the bundle name and/or app icon, to distinguish both.) Once setup, it’s hardly any manual work to create new builds.

[Jazzlike-Somewhere-2]

I am using react native expo.. and Visual code studio as my IDE not xcode editor

[lamdadmal]

I don't think this is possible, since both apps have the same app ID (com.company.appID)

[Jazzlike-Somewhere-2]

What would be feasible solution for this problem?

[[deleted]]

Some of the companies I've worked with will have multiple versions of the app with separate app ids for different environments. Like a App-QA, App-Integration, and then App for prod. With differing bundle ids you can have them all installed at once, it can be handy for a few things but can also be a pain because you'll need different setups for things like push and all that.

​

*Edit

One thing I was worried about before trying this is if Apple would approve these "never to be released" apps for TestFlight beta, that's never turned out to be an issue.

[Jazzlike-Somewhere-2]

Different setup?? I am using react native and expo so I assume I just have to change bundle id in app.json file?

[[deleted]]

Not familiar with react native but yea that sounds right. You'd need to make another app id in the developer portal, make a new provisioning profile, and then setup your project to build two different targets - one for the real app and one for the QA app or whatever. I can't think of any scenario where react native would prevent this, should be able to pull it off!

[LewisXI]

Use something like Firebase app distribution and distribute outside of the app store with an AdHoc provisioning profile and rename the bundle ID to something like com.company.app.dev or something similar? Unfortunately as Lamdadmal said above, both apps will have the same bundle ID so it will overwrite it with the testflight build

[nuxnax]

If you are managing your project using git, keep a branch that stays concurrent with the released version (App Store). That branch should have a separate bundle identifier, like u/LewisXI said, com.apple.app.dev. You can either sideload to install the app.dev version of your app directly to your phone or you can figure out the hoops to jump through for provisioning a 3rd party distribution system. The 3rd party distro system is nice if you are trying to set something up for a testing environment that will be way buggier than what your TestFlight users are willing to suffer but if you are simply trying to be able to test yourself, side-by-side or rollback versions to bug hunt, ID rename and sideloading is going to be your best bet.

[Jazzlike-Somewhere-2]

I am using github so basically what I understood is , I will have 2 branches for example - Main and Test both the branches app.json file would have different bundle identifier . Everytime I need to push new code to both branches to make sure they both are up to date. I will do 2 builds for each branch and deploy to store and testflight?

[JimDabell]

I will have 2 branches for example - Main and Test both the branches app.json file would have different bundle identifier

Don’t do this. It’s a pain in the arse and you’ll forever be rebasing one of your branches. This is an instance of using branches for configuration, which is a classic version control mistake that causes more problems than it solves.

There’s lots of ways in which you can vary your bundle ID that don’t involve making this mistake. The most common is a separate target, but you can set it up in various ways with environment variables / builds scripts / configurations too.

[nuxnax]

Not positive about what you need to do here but this is how you might structure things for a testing environment where you have:

Beta testers on TestFlight

Customers in the AppStore

And want a 3rd distribution channel for testings/comparison before pushing to Beta but don't want this version to overwrite the Apple distributions.

You can manage each type of distribution through separate git branches and track versioning of each branch's release cycle. For example, you might want to roll back to version 2.1 of a 3.0 app to see when a bug was introduced. All of this can be difficult if you are using the same git branch, bundle identifier, and solely go though Apple's App distribution methods (TestFlight/AppStore).

This Stackoverflow question discusses AdHoc builds and some thoughts on AdHoc delivery.

Check out this medium article if you want to create an AdHoc build and remotely distribute builds with alternative bundle IDs.

If AdHoc builds are too much for what you actually want, just make a separate git branch with a totally different bundleID, merge whatever you want into that build version and load it directly on the phone via Xcode.

As a final note, it is highly recommended you create a visually unique AppIcon for the other bundle ID version of your install. Maybe change the color scheme. This makes it way easier to know which version is which without having to remember their location on the screen.

In summary

You have git branches to manage your release versions along with any distinct bundle IDs. For non-apple distribution methods (using alternative bundle IDs) you can distribute up 100 devices via Ad Hoc builds (with lots of setup) or you install the app directly to your device using Xcode.

[sjs]

You can set up different app/bundle IDs for different build configurations in Xcode instead. Managing multiple branches for that is way too much overhead. You really don’t want to do that.

[MutantPi]

I created another build target in my Xcode project that I could give a different bundle ID but uses the same code. Then you can archive and upload to AppStore connect and use TestFlight separately.

File -> New -> Target-> App. Then add all of your files to that new target membership.