Category: iOS

Ensuring Quality in iOS Apps

Code coverage is an important metric that is a measure used to describe the degree to which the source of a program is executed when a particular test suite runs. A program with high code coverage, measured as a percentage, has had more of its source code executed during testing which suggests it has a lower chance of containing undetected software bugs compared to a program with low code coverage. Many different metrics can be used to calculate code coverage; some of the most basic are the percent of program subroutines and the percent of program statements called during execution of the test suite.

XCode allows to generate code coverage artefacts for any project, which it does by using llvm-cov internally. Although the code coverage metric/data is available in the XCode itself but often it is a requirement to transfer/export this data for an input to a third party tool so that the metrics can be made available to all stakeholder(eg: business). We will use this blog post to lay out the mechanism to export this profiling data regarding code coverage as a text file, so that other tools(Third Party, eg: TICS) can use this as input.


  • Make sure that the code coverage generation is enabled in XCode and the metrics are visible in xcode itself. Much has already been said about this and some excellent documentation is available here.


  • Once you have made sure that the coverage metrics is enabled, run the tests.
  • Post the test run the console should tell you the location(path) where the profiling data was generated. In my case the path was located here:screen-shot-2017-01-18-at-10-51-04
  • Translate Coverage.Profdata(This should be available at the path which we identified in the step above). The translation is done via this command:

    /usr/bin/xcrun llvm-cov show -instr-profile /Users/path/to/DerivedData/Build/Intermediates/CodeCoverage/Coverage.profdata  /Users/path/to/DerivedData/Build/Intermediates/CodeCoverage/Products/Debug-iphonesimulator/ > /Users/path/where/you/want/imported/data/llvm-cov-show.txt

  • By now, at the provided path in the command above, a text file with llvm-cov coverage data(llvm-cov-show.txt) would have been generated. This file is the end product and can be used as input to the any of the third part tools.

A good way to share a functionality across teams or companies is to share it via packaging through libraries, where the code is invisible and the team requiring it can integrate it seamlessly with the code they are working on. iOS allows the usage of static libraries via “.a” files which can be statically loaded at compile time. Runtime usage of libraries(dynamically, “.so” files) is not allowed for user apps. Some general information about these archives and their usage is mentioned below:

• iOS Simulator and an iOS device have different architectures i.e i386 and armv7s respectively. This means it is necessary to test the final library (".a") file on a real device.

• It is possible to compile a i386 based lib via command line on the terminal on a Mac OS X system. However, it is not the same for if you are building for armv7s architecture. In case of armv7s (iOS device), XCode needs to be used.

Below mentioned are the steps to create a library that can be statically linked to iOS code on a device:

• Fire up XCode and choose a new project template type under OS X→Frameworks and Libraries→C/C++ Libraries.


• Name the project and choose type as “Static”.
• Import or just drag and drop .c and .h files into the project.
• Click on “Build Settings” for the project. “Base SDK” should be Latest iOS(7.0) and “Architectures” should be Standard(armv6, armv7).


• Check the “Build Phases” in targets. Add or move the header files to “Public”.
• Select the appropriate scheme and build (Make sure you have a connected iOS device which can be selected as a scheme).


• Go to Product→Archive→Distribute→Save to save the end product which will be a folder containing the headers and the .a file.

Below mentioned are the steps to create a library that can be statically linked to iOS code that will run ONLY on the simulator. Although this is redundant but is helpful if you just want a quick lib integration/usage check:

• Fire up the terminal on OS X and fire the two commands one after another.
• gcc -Wall -c -arch i386 -arch x86_64 *.c
• ar -cvq libXXYYYZZZ.a *.o