Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Hosting IPA and dSYM Files of Continuously Delivered iOS Apps

DZone's Guide to

Hosting IPA and dSYM Files of Continuously Delivered iOS Apps

Learn a few methods of hosting IPA files when developing mobile iOS apps, so you can easily access previous versions of the app.

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

Continuous Delivery enables frequent releases of new features as soon they are ready and approved by product owners. The continuous delivery pipeline should be able to analyze, build, test, archive, and deploy iOS apps to iTunes Connect. In the previous post, we saw how to setup basic pipeline with Fastlane tools. Every iOS build deployed to iTunes Connect creates an .ipa file and A dSYM file is a "debug symbols file" as part of the archive step. Those are very important build artifacts generated as part of the build which can be used to go back to the previous version of iOS apps. It's useful to host those IPA files somewhere so that we can access previous versions of iOS apps easily. In this post, we will see the automated way of hosting an IPA files to GitHub or similar hosting server.

Benefits of Hosting .IPA Files

You might be wondering why we need to host IPA files of released apps on the server. There are some situations when IPA files come in handy:

  • Easily install the previous version of iOS apps if needed.
  • Building from the source code might fail as the version of Swift or other dependencies have been changed, and the developer might not have the same environment as when an app was released in the past.
  • IPA files are universal binaries so that can be deployed to iPhone as well as iPad.

Where to Host IPA Files

The Continuous Integration server is the best place to host an IPA files in case of the self-hosted CI servers like Xcode Server, Jenkins, TeamCity, etc, however, for a cloud-hosted CI server like TravisCI and CircleCI we need to host IPA file somewhere else. It's because cloud-based CI server launch fresh VM for the each build and VM will be destroyed after the build is finished. We might lose the IPA and other build artifacts unless we upload it to some other services. There are a few options; we can host our build artifacts like test reports, IPA files, dSYMS, etc.

  • Continuous Integration Server for self-hosted solution.
  • AWS S3 bucket or similar third-party services like Artifactory.
  • GitHub.
  • Internal Server within the company.

Hosting IPA Files on Self-Hosted CI Servers

There are self-hosted CI servers like Xcode Server from Apple, and other open source CI servers like Jenkins, TeamCity, etc. The good thing about self-hosted CI servers is we don't have to find any other place to host the build artifacts. It's already available on the CI server unless we remove it. Sometimes we need to clean up the CI server; in that case, we need to move out the build artifacts of the release build to any other location on the same server. In both cases, we have an access to IPA files and dSYMS.

Xcode Server

The latest version of Xcode Server with Xcode 9 has a new feature that will create IPA files which can be visible from the Xcode Bots. I shared new features of the Xcode Servers in my previous blog post, Xcode Server + Xcode 9 = Comprehensive iOS CI.

With Xcode Server, it becomes so easy to access the IPA files of release bots. Similarly, we can have those on Jenkins or other CI servers.

Hosting IPA Files From a Cloud-Based CI Server

As mentioned earlier, it would be challenging to access build artifacts from cloud-based CI servers as new VM are launched for every build and destroyed at the end of the build. We have to upload the generated build artifats using a script to some other services, like AWS. We can easily upload the assets on GitHub using the Fastlane set_github_release action.

Hosting IPA Files as Part of GitHub Releases

We can combine some Fastlane actions to achieve this:

$tag = "#{app_version}-#{testflight_build_number}"
)
add_git_tag(
       tag: "#{$tag}"
)

push_to_git_remote(
      remote: "origin",
      local_branch: "master",
      remote_branch: "master",
      tags: true
)

github_release = set_github_release(
  repository_name: "your_git/repo",
  api_token: ENV["GITHUB_TOKEN"],
  name: "Upload Assets",
  tag_name: "#{$tag}",
  commitish: "master",
  upload_assets: ["./build/myapp.ipa", "./build/myapp.dSYMS"]
)

The above code snippet will push the tag to GitHub and create a release by uploading IPA and dSYMS to GitHub.

Pros and Cons of Using GitHub

There are some pros and cons of using GitHub for hosting IPA and dSYMS on GitHub.

The pros are

  • Easy setup and access to all the developers,
  • It doesn't require any other third party service, like AWS S3 bucket,
  • GitHub is already on the network with most of the cloud-based CI servers like TravisCI and CircleCI, so no need to add network related dependencies, and
  • We don't have worry about the security of token and credentials of third-party services like AWS.

The cons are

  • The IPA and dSYMS are heavy in size, so they could eat lot of memory available to use on GitHub servers, and
  • It's hard to share with non-techies who don't have a GitHub account.

Using Old IPA Files

Now we managed to upload our IPA files to the server, but how to use those files to go back to the old version of iOS app? There are multiple ways to achieve this, but simplest one is using Xcode. The process is very simple. In Xcode 8, with iPhone plugged in, open Window -> Devices. In the left navigation, select the iPhone plugged in. Click on the + symbol under Installed Apps. Navigate to the .ipa you want to be installed. Select and click open to install the app.

Mind the Certificated and Provisioning Profiles

Although using Xcode is the simplest way to install IPA on a real iOS device, we need to have certificates and a provisioning profile that has been used to sign the app. Xcode couldn't install the app on devices without having a certificate or provisioning profile. There is one more thing to note: if the distribution certificate has expired, then we are no longer able to install the app using Xcode unless we resign the app with an active certificate and provisioning profile.

Conclusion

In the fast-paced world of Continuous Delivery, we deploy an iOS app frequently, so it's very important to track the important assets like IPA files and dSYMS to go back to the previous version of the app easily if needed. You might want to see how your app evolved over a period of time, or maybe not, but keeping the build artifacts for some time is a good idea. We can achieve this using Fastlane or self-hosted CI servers.

Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.

Topics:
xcode ,swift ,devops ,continuous delivery ,ios ,mobile ,continuous integration

Published at DZone with permission of Shashikant Jagtap, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}