I am setting up the production, staging and development stacks/configurations modes for my iOS and API (backend).
I figure the "RELEASE" mode definitely be when the application is public on the app store. I would like to know which configuration mode is used when the iOS application is distributed on TestFlight ?
I understood that the scheme is what determines which configuration mode is used. While I upload the .ipa to TestFlight the Archive scheme is used.
Therefore, now I would like to know if there is a way to have a different configuration for what is on TestFlight and what is released.
What I am trying to solve
We use TestFight to distribute the application to our external testers and stake holders. Therefore would like that application to have a different configuration (e.g. SERVER_ENDPOINT_URL)
Thanks!
Well, I found out that I what I want to accomplish is not possible. Nor was the system built in a way to address my issue.
So what I am doing now is.
Archiving a build with "debug" configuration
Uploading to TestFlight and distributing the executable
After testing is complete
Recompile / re archive the build with "release" configuration
Upload to iTunesConnect and publish the application
Thanks!
Apps are distributed to TestFlight in release mode. If I understand your question right, which I'm not sure I do, at the basic level you want to use a different endpoint URL in your release version. You can differentiate between debug and release using the following
#if DEBUG
static let baseURLString = "https://mydebugurl.com"
#else
static let baseURLString = "https://myreleaseurl.com/"
#endif
However for that to work you need to add custom flags to your build settings, see this question for more info
I hope that answers your question
As far as I know, you won't be able to provide "a different set of variables" for builds pushed to testFlight and app release. That is what it is there for, to test the same byte code that will be published to the public.
With that said, what you could do: Create a "version" endpoint. So if you know that when you first push build 1.2, you will want stakeholders/external testers to see it first. Send a request to your prod server, passing along the build version that is being used, if version == 1.2, point all endpoint traffic to your special "development" endpoints(creating a hostName variable in your SessionManager device side, and setting that accordingly will make that really simple), else push the user on to use prod data.
Related
The task is to use different API URLs inside the Flutter application for the app installed through the Testflight and for the app installed through the App Store.
Libraries like: store_checker and detect_testflight
do not give 100% results, and I cannot be sure that they will not stop correctly detecting the installation source after the next update.
I also cannot rely on the kReleaseMode constant, since there is no way to create a build that compiled in debug mode and uploads it on a Testflight. This can only be done in release mode.
Using custom configuration files and setting up the .gitattributes file also seems like a perversion, and is not suitable because, besides the local repositories of many developers, bitbucket is used, in which I cannot add my merge driver. Also, there is no guarantee that other developers will use this driver.
Tell me a simple and concise way to implement this? Didn't Apple come up with the idea that developers would need to use different settings for builds in Testflight and in App Store?
I'm looking into the best ways to deploy React Native apps to devices for testing. We don't want to put the app on the app store yet, but we do want the app to be downloadable to, say, an iPad.
What is the best way to do this? Do I need a testing platform or something like diawi? Or can I just put the file in an email and install it from there?
Anyway for deploying an iOS application, you have to follow the standard developer portal process. If you already did that then all good to go otherwise you just need to follow this tutorial.
Once you are done with code signing create a build using XCode Archive. This will generate .ipa file for you OR you can upload that to the testflight. If you want to skip testflight, there is one more tool available called diawi.Diawi gives you a link instantly using which you can deploy the application on test devices.
For iOS apps, test flight is the best way to go about this. https://developer.apple.com/testflight/
for Android , use internal testing and beta testing of google play
check android documentation of internal testing here
for IOS,use test flight
I use two different build schemes for managing live and staging environments in my enterprise app. Both schemes use different app ids. Now, I want to integrate AppCenter analytics. I want to know, how can i manage two separate environments for same app, since I don’t want staging analytics to corrupt the live one.
Do I need to create a separate app in AppCenter for live and staging and use the corresponding app-secret to start analytics services depending on the selected build scheme? Or is there a better way?
I think you already answer your question since you said "I don’t want staging analytics to corrupt the live one" :). So I recommend to separate as Prod and Debug app.
In my app, I separate them by setting pragma PROD & DEBUG in Build Settings:
active compilation conditions:
DEBUG - Add pragma DEBUG
Release - Add pragma PROD
Then you can set your AppCenter secret key by using the code:
#if DEBUG
secretKey = "YOUR_DEBUG_KEY"
#else
secretKey = "YOUR_PROD_KEY"
#endif
Hope this helps.
I know that it is possible to determine if an app is installed through TestFlight or AppStore. But for those app installed through TestFlight, is it possible to know if they are distributed for internal or external tester?
Thanks.
The app does not know where it comes from. You have to handle this information by yourself.
1) Identify your users one by one and decide whether they are internal or external testers
2) Make a custom build for internal/external testers. In this case you can add new a new target for your project and only change one variable in the build settings to differentiate internal/external build.
Here you can find an example of use of multi target project :
http://www.raywenderlich.com/68613/create-paid-lite-version-iphone-app
Sorry, if there is an obvious answer, but I didn't find anything.
Is there a known way to definitely make the App Store validation process (the one while uploading the App) fail but will still work for Ad-Hoc-Distributions? In code, not info.plist configurations or something.
I tried private APIs such as "[UIApplication addStatusBarImageNamed:....]" but they only seem to be checked during the actual review, that's not what I want.
I'm being a bit paranoid about my builds configurations (and using the wrong one for a live submission) and want to have an "assert" style fail option in there that makes sure I don't upload a build created with a wrong configuration.
You could use a different (developer) code signing identity for your "wrong" build configuration. This will make the upload process fail.
Or maybe you could use "invalid" combinations of iOS requirements / supported architectures. For example only support armv7 but minimum require iOS 3.0 - that should be able to compile, but not work on a device.
Add a entitlements file this is signed with a code signing identity of a specific app. Just add this and usually it's not building.