Extract iOS from Unity Buy SDK repo

[sleroux]

Problem

This repo is using the now-defunct Circle CI 1.0 service for running automated tests. We'll need to migrate our tests to run on the open sourced version of Travis CI. A challenge with porting this repo directly to Travis is that it contains both the Unity C# libraries and iOS Swift libraries which have tests and Travis's support for running a test suite across multiple types of projects is limited [1]. The Android portion of the SDK was already extracted from the repo and has it's own CI setup here [2].

Solution

I propose we extract out the iOS plugin from this repo and put it in it's own repo (game-buy-sdk-ios) which can be tested independently inside it's own Travis CI job. This will also make it easier to modify the plugin when we need to support new versions of iOS

• [ ] Extract iOS plugin into it’s own repo (game-buy-sdk-ios)
• [ ] Setup game-buy-sdk-ios to run tests on Travis CI
• [ ] Get iOS tests to go green

[1] https://docs.travis-ci.com/user/customizing-the-build/#build-matrix [2] https://github.com/Shopify/game-buy-sdk-android

[sleroux]

I did some research into what it would look like to extract the iOS code from Unity and found a couple of things:

• Since the plugin code is written in Swift, to pull it out as a dependency similar to what we do for Android we would have to package it as a Swift Touch Framework which Unity doesn’t support as a plugin. It does support raw .swift files though since they get copied over into the Xcode project directly.
• There are some tight couplings between the iOS plugin code and Unity references such as UnityBuyAppController and UnitySendMessage. With all the code in the repo its simple enough to test since the Xcode project builds the project with the Unity APIs so the references are found.

I was able to move over the iOS tests to run on Travis so I propose we table this work for now. Motivation behind moving this out into it's own repo would be to reuse Apple Pay functionality on different gaming integrations. When that happens we'll need to convert the Swift code to ObjC++ to be compatible at a more native level and pull the code in as a static lib. Along with the refactoring we'd also reconsider the API boundary between Unity/Apple Pay to be more cross-engine compatible - similar to how Android is implemented today.