There is a lot of excitement about Apple’s World Wide Developer Conference (WWDC 2018) that kicks off next week on 4th June 2018. Unfortunately, we don’t have access to Apple’s roadmap so it’s always exciting to see what they are going to show us in the WWDC, apart from some open-source projects like Swift, package manager and Swift NIO which are available on Apple Github repository. There is also suspense on what talks/session are going to happen in this WWDC and there is no way that we can see titles of talks until the conference starts.

As developers working on Apple platform, everyone expect something nice so that it can make our life easy. Almost everyone has something on their wishlist that they are expecting from Apple engineers. There are wishlists about major software or hardware are published by MacRumors, Macworld, AppleInsider, PC Magazine etc, you can find great collection here , However, in this post I will have my own wishlist about improvements those I always wanted in the area of Continuous Integration, Continuous Delivery, Test Automation,  DevOps and Apple Developer tools. This is related to Swift, XCTest, XCUITest, Xcode Server, BuddyBuild, Swift Package Manager etc.

CI/CD: Xcode Server + BuddyBuild

Apple introduced their own Continuous Integration solution known as Xcode Server so that developer can create the bots from Xcode and run then on macOS server. There are some pros and cons of using Xcode Server over other CI services like Jenkins, TeamCity, TravisCI, CircleCI. I wrote detailed articles about pros and cons that you can read here. However, Xcode server has some limitation that one can not use it for bigger teams and testing pull requests. You can read more about top 10 limitations of Xcode server in my previous blog post here. The good news is that Apple now bought BuddyBuild, the cloud-based CI service. This might solve most of the iOS development pains. Hope that Apple won’t kills Xcode Server for sake of BuddyBuild. Some of the things on my wishlist from the team that works on  Xcode Server and BuddyBuild together.

• Don’t Kill Xcode Server

As Apple has bought new vendor for dealing with CI/CD-related tasks. There is the possibility that Apple might completely discontinue support for Xcode Server and ask users to use BuddyBuild’ish solution. That would be a nightmare, companies have invested money and time to setup  Xcode Server and switching to other solution would be waste of time and money. It’s still possible to combine the feature of Xcode Server and BuddyBuild. Let the Xcode Server be for the self-hosted and BuddyBuild for the cloud-based CI solution.

• Pull Request support for Self Hosted Xcode Server

This is the only reason most of the developer or companies reject Xcode Server as it doesn’t support testing pull requests. Xcode now has tight integration with Github, this can be expected in this years WWDC.

• Automatic Upload to TestFlight from Xcode Server

Last year at WWDC 2017, Apple has enhanced Xcode Server with lots of new features. You can read more new features here or watch WWDC talk in Safari here, they have added loads of features that make Continuous Delivery of iOS apps painless. However, it missed the final point to upload the generated  .ipa  file to iTunes Connect or TestFlight. We can expect this feature this year.

• Strategy to Backup and cleanup Xcode Server

Currently, Xcode Server has no cleanup and backup strategy. It stores everything so that engineer has to write custom scripts or manually backup/cleanup Xcode Server integrations. It would be nice to see some strategy for better maintenance of Xcode Server. e.g keep X number of builds, delete all integrations, delete integrations every months etc

• Master-Slave Architecture for Scalability

Another reasons companies or developers reject Xcode Server is its scalability. The macOS machines running Xcode Server cannot be utilized effectively without scalability. Currently, it works well when macOS server has been assigned to each project, however, if there are multiple projects with multiple macOS servers, we can scale and utilize the macOS servers those are idle. Basically, we need something like Jenkins Master-Slave architecture.

• Free cloud service/ low-cost cloud service of BuddyBuild

As Apple acquired BuddyBuddy, we can expect the free or very low-cost cloud CI service. This will get rid of all the pain of maintaining macOS servers in-house and DIY DevOps activities.

• Don’t Take Control Of Continuous Integration

Most of the cloud-based CI services including BuddyBuild reads Xcode project and take control of it e.g guess schemes, run tests automatically etc. It would be awesome to give engineers ability to set up the workflow as per the project need.

• GUI and CLI Options for CI/CD (Pipeline As Code)

Currently, both Xcode Server and BuddyBuild give all the CI setup to be configured from GUI which is great but it would be awesome to have that ability to configure the workflow from the command line as well. This can help to script CI/CD pipeline in the code and keep all the infrastructure as code.

• Change swift toolchain from CI

Xcode comes with specific Swift version. As Swift is undergoing lots of changes, its essential to make sure apps and libraries are still working with the latest version of Swift. Currently, we can get latest Swift toolchain and switch the version without changing Xcode version. It would be great to have this ability to easily change Xcode Or Swift version dynamically from Xcode Server or BuddyBuild

• Parallel Integrations Xcode Server

Not sure if it’s possible with multiple Xcodes but would be good time saver feature.

• Manual and Automatic Code Signing

Xcode Server and BuddyBuild both have great support for code signing apps automatically. However, it would be good to have support for the manual or customized code signing as well so that we can manage the profiles and certificates from version control system.

• Customisable and Sharable Reports

Xcode Server has the great dashboard which shows the results of the integrations including code coverage. However, it would be great we can make it customized for specific project needs.

XCTest

As XCTest framework is getting popular for the unit, UI and performance testing, there is always hunger from developers to improve the development flow. There are many XUnit types of the framework in the market for other programming languages like JUnit, NUnit, PHPUnit, Test Unit etc, XCTest still has to reach that level to compete with the features they are providing at the moment. It would be great to see these features in XCTest in this year WWDC

• Parameters Support for XCTest

Currently, XCTest methods don’t accept any parameters which limit the ability to add data from any data provider to the tests. The good example would be the PHPUnit test accepting an array as the data provider from PHPUnit documentation. You can read more here

Although the example above is for PHPUnit framework, this mechanism will be useful for both unit and UI tests for XCTest as well. We can drive XCTests from any data providers like arrays, Dictionaries in Swift

• Official Mocking framework for XCTest

Every mature testing framework has support for well established or official mocking framework. Currently, a developer working with XCTests has to write all the mocks by hand which is painful. It would be great if there is official mocking framework available for the Swift to mock the XCTest without any efforts.

• Performance Testing Enhancements

XCTest can be used for performance testing as well, however, there is hardly any discussion about performance testing iOS apps using XCTest. I wrote a detailed post on performance testing with XCTest here which explains basics of performance testing in XCTest. This year we can expect some improvements in performance testing strategy of XCTest so that it would be easy for iOS developers to understand the usefulness of performance testing.

XCUITest

Apple has announced the UI Testing support in Xcode at WWDC 2015. The UI tests are designed to be the completely black box without having any access to main application code and data. The XCUITest uses two standalone processes Test Runner and Target app, the test runner launched the target app and uses the accessibility capabilities built into UIKit to interact with the app running in a separate process. As XCTest framework is getting popular for the UI testing of iOS apps. However, it can be better if we have the following

• Reset app in between tests with inbuilt launch argument

This is related to XCUITest, currently, XCUITest uses the same session when running in a batch. There is no clean way to reset the app state in between the tests without changing the production code in the main app. It would be great to have a native launchArgument to rest an app per test or test class.

• More Native Launch Argument

Apple has set some default launch arguments and environments for internationalization and localization, however, it would be great to add the arguments for timezone and other general settings.

• Support to open deep link URLs

Currently, it’s not possible to open universal links or deep links from XCUITests. We have to use the approach of using other apps like iMessage or Notes to automate this process. It would be nice to have support for the opening deep links in the app and assert the UI elements on the screen.

• Fix Accessibility Bugs

Currently, there is a weird bug in the XCUITest that if a super view is set to accessible, XCUITest might not be able to access its subviews. This force developer to disable the accessibility of certain UI elements for sake of XCUITest. Hope this should be also fixed as part of Xcode 10 or Xcode X

xcodebuild

Since Xcode 8, xcodebuild has got a lot of new features. Now we have more options that we can pass to the too in order to make build dynamic. There are a couple of things I would expect this year

• additional argument for the new SWIFT Build System turn ON and OFF
• Option to show simulator when requested by the user. Currently, all XCUITest runs heedlessly when running from the command line
• Improve destination  option for parallel testing without repeating simulator names or ID

SIMCTL

It became so easy to control the iOS simulators using xcrun simctl utility. We can set up the simulator to almost any state with any data using this utility. However, I would like to see some missing bits this year

• Ability to rotate or set orientation using simctl while launching simulator.
• Ability to set the location of the simulator to support international testing
• Ability to disable animation, as some apps have animations running in the background but XCUITest cannot run when animations running in the background.

Swift Package Manager

The swift package manager has been announced by Apple and it’s being developed openly on Github. However, Swift package manager doesn’t support iOS at the moment. We can clearly see the development on Github that it’s not ready to be used for iOS apps but some internal Apple magic can give us good news about this. That’s the only big thing we can expect from Swift Package Manager. This would be helpful to remove tools like CocoaPods or Carthage from iOS toolbox.

Conclusion

It’s long wish list and expected much more from WWDC, however, the show is going to begin next week. Let’s wait and watch what Apple engineers are bringing for us. After WWDC, I will write another post concluding what Apple offered from this big wishlist. Stay Tuned!