Why You Don’t Need XCUITest Anymore: Changes on the Horizon

In 2015, Apple launched XCUITest, a native testing framework for iOS. Apple’s goal was to allow for the automated testing of iOS applications while simultaneously enhancing the testing process as a whole by way of a low-code approach. Integrated in Apple’s IDE as XCode, the XCUITest is built upon XCTest, a pre-existing testing framework meant for the creation and implementation of UI tests, performance tests, and unit tests. 

The difference between the XCTest and XCUITest lies within the specific realms of their tests: Apple intended XCTest for internal software testing and XCUITest for external software testing. (External software testing, colloquially known as black-box testing, means that rather than focusing on the internal functionality of the software, the focus is on the behavior.) 

Thus, XCUITest has neither access to application data nor API access. The test codes for XCUITest require Swift or Objective-C as programming languages.

XCUITest is widely used by developers today and is a de facto industry standard. However, there’s a big shift occurring that may have an impact on your decision to use XCUITest. But before we get into that, let’s take a look at some of the benefits and problems users currently navigate with XCUITest.

Benefits

Historically, XCUITest has offered developers a variety of benefits: 

1. Installation: Since both it and XCTest are already integrated into XCode, XCUITest requires no further installation 
2. Fast and reliable: The integration further suggests that, since the XCUI test is considered a native testing framework, implementation of tests becomes faster and even more reliable  
3. Test recording: XCUITest offers users test recording (done with features such as XCUIScreen and XCUIScreenshot) where the UI tests are recorded and can subsequently be used as a basis for comparison or for building upon. As a result, less time is wasted during the creation and implementation of tests. 
4. Collaborate with ease: The sole use of Swift or Objective-C as the programming languages means that developers and test engineers can collaborate easier using existing CI/CD pipelines along with other DevOps tools. 

Problems

However, XCUITest also brings with it a variety of problems, such as: 

1. Native only: XCUITest only allows for native iOS application testing
   • Only using Swift and Objective-C as the programming languages to write the tests conversely means that cross-platform testing is impossible due to incompatibility
   • As Android apps are not supported, approximately half of the market for mobile apps remains unaddressed (see below for more discussion this)
2. Restrictive: Lacking support for popular languages like Java or Python, developers are stuck with either Swift or Objective-C if they wish to develop with the XCUITest
3. Can be inefficient: Developers will have to create separate tests on different platforms if they wish to create complementary Windows or Android applications, which is highly inefficient
4. Low-code: Low-code is still code! And that means that you can expect to spend time writing, maintaining, and updating XCUITest code.

Bigger problems on the horizon?

As with any other native testing framework (and as we highlight above), XCUITest does not allow for cross-platform testing, implying a need to spend more time and resources in order to develop on other platforms. A majority of developers tend to eventually branch out beyond one platform for their application, so choosing an option that would hinder said expansion can all too often prove troublesome later on. 

Moreover, the mobile app market is a heterogeneous market, where at present Apple’s App Store is the second largest app marketplace, consisting of approximately 2.22 million apps. First place of course currently goes to the Google Play Store, which at present contains approximately 3.48 million apps.

The above tallies of downloads per app market may indicate stagnancy among iOS-centered apps compared to the growth of Android-centered apps. Indeed, according to 2020 a study by Sensor Tower, Apple’s App Store downloads saw a growth rate of a mere 2.5% whereas the Google Play Store downloads consisted of a shockingly high growth rate of 31%.

These platform-specific observations highlight the restrictiveness of utilizing a native testing framework, especially if a developer values the opportunity for future expansion into a different platform for their app(s).

A tremendous shift

The obvious question here is, what is a better alternative to this low-code, native testing framework? The answer lies in the introduction of no-code, automated testing frameworks that allow for cross-platform testing without the need for any code whatsoever. 

The market has shifted from a dependence on code-intensive tests to low-code approaches. And now we’re seeing a natural shift toward entirely no-code tool sets. Why? The answer is simple: When a team can achieve the same or better functionality with no-code tool sets as it can with any other approach, the result is that a team saves time, money, and resources. 

Other approaches entail some sort of creation, maintenance, update, and release cycle for producing test cases, all with the end goal of keeping a testing system relevant and applicable to current standards. However, no-code approaches like that of Sofy allow testing teams to focus on testing rather than maintenance and upkeep for all modern operating systems and languages. 

Sofy’s ability to encompass all languages erases any need for knowledge of a specific language to develop your app and removes the aforementioned reliance on only two iOS-inclined programming languages. With Sofy, you can run your automation testing end-to-end without the need to script in any particular language for any particular platform. Sofy is an enterprise grade solution that works for the most complicated apps and test cases. At Sofy, we’re happy to assist you with taking the next step beyond XCUITest—and reaping the benefits.