update CocoaPods examples with Themis 0.13.10

[julepka]

Updated CocoaPods examples to use Themis 0.13.10.

The Embed Pods Frameworks part was added to ThemisTest.xcodeproj by the CocoaPods.
Tested on simulator, device, uploaded to TestFlight.

Checklist

• Change is covered by automated tests
• The coding guidelines are followed
• Example projects and code samples are up-to-date (in case of API changes)
• Changelog is updated (in case of notable or breaking changes)

[julepka]

Investigating why Carthage project test is failing... Locally I'm getting another problem: it times out to load the binary...

[julepka]

The Carthage test was just in a bad mood.

[ilammy]

I've tried restarting the build on CI several times, it keeps failing with different issues. But if you keep doing that, eventually it will give in and complete its job.

On my machine I see the same issue as @julepka describes:

xcodebuild timed out while trying to read ThemisTest.xcodeproj 😭

It seems that Carthage's quirky behavior has finally bit us, with too many example projects in docs/examples.

Cartage has this weird ardency to inspect absolutely every *.xcodeproj it can find in the entire filesystem tree under the current directory, even if you only want to build the one in the current directory. I guess it especially does not like projects intended for use with CocoaPods because they are competitors do not have their dependencies set up properly. Or probably tries to fetch all SPM dependencies, because why wouldn't you do that to a project that you won't build. I guess it conservatively assumes that other Xcode project might be subprojects or whatnot.

You can check that by doing

rm -rf docs/examples
rm -rf tests/objcthemis

followed by

carthage build --no-skip-current --use-xcframeworks

which will not time out and instead proceeds building schemes of Themis.xcodeproj.

This might be used as a workaround for this specific job, I guess.

Bad news is that Carthage does the same stupid shit when building Themis as a dependency. If you force Carthage to build from source (carthage bootstrap --no-use-binaries in any of the examples) then it will time out there as well. We're kinda saved by prebuilt binaries, but that's just a side effect.

Carthage issue tracker has a couple of issues complaining about this recursive behavior, but they did not get anywhere. People just gave up and split their Xcode projects into multiple repos. I wonder if it's time for us to complain too.

[vixentael]

I've fixed similar issue on my machine by updating carthage to 0.38 and using xcode 12.4

[julepka]

I've fixed the timeout issue locally just by re-running carthage build --no-skip-current --use-xcframeworks 4 times...

The last time the error in CI reached the maximum weirdness: it complained about Package.resolved file which is specific to SPM examples in our repo.

[vixentael]

the maximum weirdness

...caches...

[ilammy]

I've fixed the timeout issue locally just by re-running carthage build --no-skip-current --use-xcframeworks 4 times...

Should I consider this a fix then?

--- a/.github/workflows/test-objc.yaml
+++ b/.github/workflows/test-objc.yaml
@@ -179,7 +179,8 @@ jobs:
           carthage bootstrap --use-xcframeworks
       - name: Build Carthage projects
         run: |
-          carthage build --no-skip-current --use-xcframeworks
+          while ! carthage build --no-skip-current --use-xcframeworks
+          do (^___^) done

   project-cocoapods:
     name: CocoaPods project