I have read about the Xcode 9, and there is an interesting term “bots”, which will do the CI/CD work for you, but didn't get any proper guide. Could anyone help me find the configuration guide on it?
From Apple’s About Continuous Integration in Xcode guide:
Bots are at the center of the Xcode Server automated workflow. Bots
build and test your projects with the schemes you specify. Because
Xcode Server can access the source code repositories of your projects,
you can create and schedule bots to run periodically, on every source
code commit, or manually. You can also configure bots to send email
notification of the success or failure of their integrations. Xcode
Server also allows your bots to conduct performance testing and
initiate pre- and postintegration triggers.
On how to setup and configure bots, please read Install macOS Server and Configure Xcode Server.
Related
I'm developing a mobile app (using React Native for that matter), and I'd like to have one of the members of my team try it out.
With Android, I can just share the apk with them. Is there something similiar in iOS?
There is a bunch of tools to do this. Test Flight is not the easiest way to share a build because you need to submit it to the app store, it needs to be processed, pass through all the checks before someone can download it.
Whilst you should definitely use Test Flight to deploy official test versions, an internally used tool for alpha and beta versions is quicker and easier.
I would suggest a tool like Fabric Beta (currently owned by Google), which is a free app deployment + analytics tool. you will need to add some code to allow it to work but it is a simple process. It comes with a program to help deploy and you can plug it into most CI software.
You will need to ensure you have the device UUID's of people in your internal team to sign the application for their devices.
Test Flight is what you're looking for.
First though you need to add the UDID of your team member's device to the provisioning profile used to create the .ipa (iOS equivalent of an APK). But after that, just follow the information and tutorial(s) at the provided link.
I would like the Internal Testing and External Testing users on TestFlight to goto different API servers when they first run the app. I'm wondering if it's possible for the app to detect if it was installed as "Internal Testing" or "External Testing" app from TestFlight.
If this is not possible my next option was to build a separate app to send to Testflight that would use a different API server on startup. But this is more complicated.
The reason behind doing this is I only want external testers to see real data from the server. And not the bogus test data we have been submitting while developing the app.
As far as I know it is not possible to detect internal vs external testers running your application.
But you don't have to build two different applications. I have similar requirements than you: I have a special menu in the application settings where internal testers may tweak several aspects of the application, like for example the server they are connecting to, so they can test the application without messing with production data, or buying content in a controlled environment. I don't want those settings to be available to external testers, so I do the following:
I create two different build configurations, one for internal testers (e.g. ReleaseInternal), and other for the rest (Release)
I define a preprocessor macro / Swift flag in the internal tester build configuration (e.g. INTERNAL_TESTING)
I use the preprocessor macro / Swift flag to activate / deactivate certain sections of code or functionalities
I create two different schemas, each one using the corresponding build configuration, so you just have to switch the schema to build the appropriate version of the application
And finally, I automate the release of the application using fastlane, with a flag indicating whether I want to release the application to internal or external testers, so I don't make a mistake and release the wrong version to the wrong people
It is not possible to detect whether an app was installed as "Internal Testing" or "External Testing".
Another solution is to make a build that points to real data by default, but has a hidden switch you can teach internal users to use to switch to test data.
You can use NSUserDefaults to save the switch setting so internal users don't have to switch it every time they install a new build or re-launch the app.
If you're worried about real users finding your secret switch, you'll have to make a separate app as you say.
Did anyone managed to get Travis CI to deploy the app on iTunesConnect? I have read tons of articles and tried them without success.
My closest bet was this article:
Continuously Delivering iOS Beta Builds Automated with Travis CI
They didn't provide info that you need to install Mako in order to work, so pay attention if you go this way.
The main problem however is the fact that I do not have Crittercism or HockeyApp accounts, however the python script want them from me and no matter if I do not provide them or provide fake it fails later as it actually tries to do something with them.
Other thing that I come across is:
Automated iOS beta distribution using Travis CI and Testflight
which is essentially written on top of Deploy an iOS app to testflight using Travis CI. The problem here is that they deploy to TestFlight app instead of iTunesConnect.
Any help would be appreciated.
I would consider looking into the ruby gem fastlane. We have been using it for quite some time and it has definitely saved us hours of problems related to deploying to iTunesConnect. I haven't used TravisCI before but from this blog post I know they support fastlane. The community is great and #KrauseFX is awesome at answering any questions you might have. He even uses TravisCI to build the fastlane tools!
Is there a way to activate pre-release builds (activating them for beta testing) without having to go to iTunes Connect's dashboard and manually activating them?
Every time I have a new build I have to go there, click on the app, click on pre-release and click the toggle. Being able to do it via terminal would fix my problem.
The old testflight didn't had this, i.e. builds were available right after you uploaded them.
Edit: I was expecting a solution that wouldn't require third party tools. However it seems like using fastlane is indeed the best solution. I may mark that answer correct, but I need to try that out first.
You can use the fantastic deliver tool. It supports both uploading a new build and activating it for pre-release testing (aka Apple TestFlight beta testing).
My company was using the old Testflight service for adhoc/beta builds running on a Jenkins server. When it finally stopped working, I looked into using the new Testflight service and was pretty bummed to see that (at least at the time) there was no way to set up automation with it, so we stopped using it. We have now switched over to using Crashlytics Beta which accomplishes pretty much 100% what the old Testflight did with full commandline (and hence automation) support. It also comes with some other nice features.
I am going to develop an iOS application for a customer of mine and I would like to make him constantly up-to-date during the development phase. In order to do so, I am looking for a tool which should allow me to share the current status of the application with my customer. The goal is to allow my customer to personally run the latest prototype of the application on a kind of simulator/emulator or on his own device (either iPhone or iPad).
Is that possible? Is there a tool (or a set of tools) which I can use to do so?
In case it is not possible, as far as I know the only alternative is to take screenshots or record videos, right? Just let me know if I am mistaken.
Thanks a lot!
The best way, I know of, is TestFlight.
This allows you to upload an AdHoc build of your app to there server and allow you customer to download it.
They even supply an SDK which can alert the user that a new version of the app is available also you add some debug functionality to the build (reading crash reports).
If you want to do, one elegant solution would be to use a continuous integration server to pull the code from your repository, make an adhoc build and place it somewhere publicly accessible.
The whole solution can take some time to set up and depends quite a lot on how is your development environment. In my company we are actually doing it with Jenkins and some shell scripting. If you Google a little bit about continuous integration of iOS projects with Jenkins you'll find some information.
Might not be the best way to do it, but I can't trust online repositories like TestFlight.
Not the easiest but rather secure workaround for this;
Get your customers device into your developer account
Create your new development provisioning profiles (consisting that device)
Distribute your application via Archive, and save it
Send your IPA to your customer