Originally created by @kjoneandrei in a different project and now migrated here.

History

original description by @kjoneandrei on 25.03.2019
Implement obfuscation via https://github.com/rockbruno/swiftshield in CI

comment by @NickSkull on 26.03.2019
@kjoneandrei could you please add some more information to the issue? I think we need to setup some rules about titles, body, labels.

comment by @kjoneandrei on 26.03.2019
@NickSkull Of course, here it is.

The Problem and the Solution:

So we have a client security requirement that requires source code obfuscation. To do so we have found the SwiftShield framework that can perform the obfuscation for us before archive step. By doing so it will rename classes, variables etc to something random so that it will deter attackers from trying to reverse engineer the app and/or try to access API keys from the project.

Risks:

After the obfuscation step the code might not be archivable if there were errors with obfuscating the code. The framework's github page contains a lists of do and don't to help with the headaches. I would recommend though that the obfuscation is done locally first so we can spot the possible errors before they reach our CI.

Alternatives:

https://github.com/Polidea/SiriusObfuscator

Next Step:

Research and implement

In both the README file as well as the bitwise script (nodes-projects/bitrise-step-nodes-custom-script instead of nodes-ios/bitrise-step-nodes-custom-script/issues)

Slack integration should be expanded to provide better information. Slack has recently released the Block Kit interface for building/sending messages through their API which we should explore and see how it could be appended.

https://api.slack.com/block-kit

Checklist of ideas that the new messages could contain:

• App icon (useful when badged)
• Buttons that link to Bitrise, HockeyApp
• Changelog (maybe expandable, so the message isn't taking up whole Slack window)
• Build author, timestamp
• Testflight link/status (this is admittedly the most difficult, maybe a microservice would be needed to monitor this)
• Retrigger button on failed builds?
• more....

A complete revamp of error handling is necessary to provide better and more clear messages about what has failed in the build to avoid confusion and hunting non-existent bugs due to different warning messages.

Ideally these errors should also be somehow reflected in the messages going out to Slack or similar.

It could also be beneficial to preserve and make available more logs and artifacts from the builds so that when it fails they are easier to access.

A feature creep idea would be to check git author and send them an email with what has failed in the build, but this would need to be better thought out and maybe it's more fitting for a v3.

When setting up an app recently that only had CocoaPods, CI failed until I moved some dependencies over to Carthage.

The Carthage step would fail if no Cartfile is present, causing the CI to cancel all the other steps and return with an error

Motivation:

Using fastlane badge is slow, as it requires an additional bundle install to be run each time this script is used. We should remove that an instead create a custom solution that will speed up the CI buillds.

Steps:

• Remove fastlane badge plugin and cleanup dependencies
• Dynamically create a badge at buildtime using shields.io
• Using imagemagick modify app icons to have a badge

Alternatively, the code in this repo could be (cough MIT license) borrowed and adjusted for our needs: https://github.com/HazAT/badge/blob/master/lib/badge/runner.rb

Check if we have ci-version set correctly

if [ -z "${CI_VERSION}" ]; then
	# not set, fallback to default CI version
	CI_VERSION=$DEFAULT_CI_VERSION
fi

will always fail and set the CI_VERSION to default as CI_VERSION is an enviroment variable set later.

As a consequence the wrong parse project settings version will be used

We should invest some time in writing a proper documentation explaining how each component, lane, script, etc works and where is it located.

This should make it easier for joining developers to continue working on this step without extensive prior domain knowledge.

Furhtermore, it should be explained and showed how to use this step locally in a debug/mocked environment and what input does it expect in what way - if any helper scripts need to be created then that could be a part of this issue as well.

This will allow us to properly use Bitrise caching and further simplify the Fastfiles.

See the example of how run_if works here:

https://github.com/bitrise-io/bitrise/blob/master/_examples/experimentals/templates/bitrise.yml

And related issue:
https://discuss.bitrise.io/t/allow-disabling-a-step-in-the-workflow/711/5

We need to verify that changes from Xcode11 such as

	<key>CFBundleVersion</key>
	<string>$(CURRENT_PROJECT_VERSION)</string>

won't have an impact on the step

Currently, everytime bitrise interacts with this step it has to load all dependencies, do bundle install and other which take considerable amount of time (~20-30 seconds each time it is run), which we could optimize away.

We could either make this step do all the logic we need and have it as the final step in the Bitrise workflow or somehow check/make sure the dependencies are not being installed everytime.

Currently we support hockey and testflight, but it is pretty error-prone if you want to use one but not the other. Also, hockey is going away this fall and we will probably need to support other distribution platforms.

The build process should be able to selectively upload to different platforms without any inter-dependencies, and upload to new platforms without needing new builds or configuration changes.

We are getting to a point where our Fastfile is incredibly large which makes it very hard to navigate and also distinguish what is the actual logic.

There is an option of splitting up Fastfiles into multiple files which I think is the right way moving forward to keep responsibilites and code better separated.

See these docs and discussion for more info:

https://docs.fastlane.tools/actions/import/#import
fastlane/fastlane#13929