Hosting of ipa and dSYM files of Continuously Delivered iOS apps
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 analyse, build, test, archive and deploy iOS apps to iTunes Connect. In the previous post, we have seen how to setup basic pipeline with Fastlane tools. Every iOS build deployed to iTunes Connect creates a .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 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 comes 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 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 the 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 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 Company
Hosting IPA on Self-Hosted CI Servers
There are Self-Hosted CI servers like Xcode Server from Apple, 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 CI server in that case we need to move out the build artifacts of 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 and IPA files which can be visible from the Xcode Bots. I shared new features of the Xcode Servers in previous blog post ‘Xcode Server + Xcode 9 = Comprehensive iOS CI ‘
With Xcode Server, it becomes so easy to access IPA files of release bots. Similarly, we can have those on Jenkins or other CI servers.
Hosting IPA from Cloud based CI Server
As mentioned earlier, it would be challenging to access build artifacts from could based CI servers as new VM has been launched for every build and destroyed at end of the build. We have to upload the generated build artifats using a script to some other services like AWS or similar. We can easily upload the assets on GitHub using Fastlane set_github_release action.
Hosting IPA as Part of GitHub Releases
We can combine some Fastlane actions to achieve this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
$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 with 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 or similar
- GitHub is already on the network with most of the cloud based CI servers like TravisCI and CircleCI etc so no need to add network related dependencies.
- We don’t have worry about the security of token, 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
- Hard to share with non-techies who don’t have Github account.
Using Old IPA files
Now that, 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 the real iOS device, we need to have certificates and provisioning profile that has been used to sign the app. Xcode couldn’t install the app on the devices without having certificate or provisioning profile. There is one more thing to note that if distribution certificate has expired then we 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 Continuously 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 app easily if needed. You might want to see how your app evolved over the period of time or may be not but keeping the build artifacts hanging for some times is a good idea. We can achieve this using Fastlane or self-hosted CI servers.
