How can we setup access to different builds so that they can easily / quickly viewed in the simulator..
We have several builds - production, development and one or more feature branches.
From a development and testing point of view, it would be really useful to be able to quickly see each of these versions of our app.
I'm just wondering if there are any services or some sort of configuration we could employ to make this easier.
I'm thinking one major obsticle might be the app id is always the same, so this would stop of from running the builds / app in the same simulator...
I'm wondering if the app could be bundled locally (perhaps from some kind of snapshot) and a script could copy in app to the simulator ?
I guess this could be some kind of tool which would use use the simulator command line tool and swap app builds.
I found a solution, all you need to do is keep a copy of the app and drag and drop it into the simulator
https://medium.com/swift2go/how-transfer-your-app-from-one-xcode-simulator-to-another-f4225da9eb7b
Related
I have one app but I have different backends for Production and Testing to isolate the data between the two. This means that when I upload a version of the app to the App Store, it is locked-in pointing to either the Testing or Production backend. Since each version of the app uploaded to the App Store must be its own unique version, I'll have some versions that are 'test-only' that will never be promoted to production and other that are 'production-only'. Is there a better way to handle this situation, either within the App Store or within my Swift code itself?
After working with TestFlight more, I settled on the pattern of having all builds for the same release use the same semantic release version and just change the build number.
I may take this a step further and use different build number schemes between the Testing builds and the Production builds. This would make the distinction between test and production builds much more explicit within TestFlight.
Another solution that requires more setup but creates an even cleaner separation would be to create separate Apps in App Store Connect with the intention that your non-Production Apps would never be released to the public App Store. I could see this being a great solution if your app had to go through multiple test environments. There would be some more overhead (i.e. a lot more builds and separate targets to maintain) but you would never have to worry about accidentally submitting a version of your app whose backend points to a test environment instead of a production environment. For more details on this type of solution, I recommend https://savvyapps.com/blog/using-testflight-to-distribute-multiple-versions-ios-app.
We create iOS and Android apps that are white-labeled. They all use a single code base (one for iOS and one for Android). Whenever we need to make changes to all of our apps (> 100 live in App Store) we rely on Fastlane. We have a "bulk" command that submits each new build to Apple, changing out config variables first and a few files so each app is unique.
This has worked well for us... but... its getting really slow. We'd love to be able to take advantage of some of the continuous development services out there. It seems like they weren't necessarily made for this use case but it might still work?
Ideally instead of running bulk on a local machine we could spin up 100 instances on something like CircleCI and they all run side by side, using our fastlane script to build, submit, etc.
We started by looking into CircleCI. The problem we are running into is they don't allow injection of variables into a job (https://ideas.circleci.com/ideas/CCI-I-690).
Is there a better service for this goal? Is there a tool that was built to achieve this? Struggling to find an alternative to hacking together a bunch of smaller tools.
I think you already identified your first step: You will have to split your fastlane (and other tooling) configuration, so it is possible to build each app in isolation.
Then you can trigger a job for each app on a CI service like for example Travis CI or Azure Pipelines (both have a simple API you can use to start jobs and give them some parameters that will be available to your job) that builds and releases the app.
All the other things (e.g. one big build vs. many small build steps etc.) are just implementation details and will depend on the individual service or tools you choose.
I've build Jenkinsfile for multibranch-pipeline as on this gist: https://gist.github.com/nysander/0911f439bca7e046c765c0dc79e35e9f
My problem is that I want to automate testing on multiple simulators and multiple iOS SDK versions. To make this work I make a lot of duplication in attached code.
Is there any way to make this work in loop and pull list of simulators / SDK's to test from some library, array, etc?
The other thing is that testing as in gist is made in sequence (when I made it parallel it broke - something like Xcode database locked)
Other issue is that tests on tests results summary are shown now 3 times every test, and if some fail on one simulator/SDK I have no idea how to know on which SDK it failed.
Any comments and help appreciated, also if such workflow is bad from the beginning.
I used to develop unit tests on Jenkins, running on multiple simulators. I came up with this https://github.com/plu/pxctest allow me to run testing in parallel, saving time as well. In your case it should be multiple simulators with different SDKs.
Regarding the summary, maybe you can export environment variables to tag every test.
Hope it helps!
I have a project which has an Xcode Tests suite and I want to implement a CI system by using "xcodebuild ... tests" command. The only limitation that I have is the hardware. I'm limited to only 2 Macs and 2 iPads and I also want to build for Debug and Release. The problem is that I have different app flavors and I would like to run a part of them (e.g. all the flavours on debug) on one iPad and the others on the other iPad.
I tried to call multiple times "xcodebuild" commands using the "tests" argument, hoping that it would be parallelized, but the problem is that it kills the tests app instance that is running already on the device.
I spent some time searching for someone who did this, but the only thing that was close to what I need was the usage of multiple iOS Simulators which I'm not comfortable because real device testing is required for the project.
Is it doable to run parallel tests on the same device? Am I missing some arguments that I need to add to the xcodebuild command?
No you can only run one test operation on 1 device at a time. Thats why people use multiple simulators as you can set them all to the same OS if you need to run the same test multiple times.
Not the answer you are looking for, but you could use Xcode server to have multiple bots, one for each flavour. If they all point to the same repo / branch, then they should all run one after the other. It would mean less manual effort building a tool to do it.
I also thought I read somewhere that with Xcode 10 you can load balance across multiple Xcode servers, but can't find a link to it. That might be helpful if you have 2 machines. If not you could duplicate the bots across both Xcode servers. Maybe using the API to control the creation of bots?
Xcode server setup guide
I've started developing my iOS app across two machines. A MBP and an iMac. I'm using an only repository which works almost identical to how GitHub works. So Source Control features built into Xcode 5 work perfectly too.
Here's the thing though - I sometimes change Xcode preferences or my work space / schemes etc and when I get to the other machine - obviously these settings need to be setup again.
Is there a way to sync the workspace / preferences of my Xcode from one machine to the other?
personally I work with github and the job is done automatically by pushing and pulling the data from the git. So it's possible to do it, maybe you should include the storyboard and Project Settings (project.pbxproj for me) in your git sync files.