This will download Rome to the Pods/ folder during your next pod install execution and will allow you to invoke it via ${PODS_ROOT}/Rome/rome in your Script Build Phases.

The Rome binary is also attached as a zip to each release on the releases page here on GitHub.

Using Rome? Let me know by opening an issue and I will gladly add you to the user list.

You can integrate Rome into your fastlane automation with the fastlane plugin for Rome.

Suppose you're working a number of frameworks for your project and want to share those with your team. A great way to do so is to use Carthage and have team members point the Cartfile to the new framework version (or branch, tag, commit) and run carthage update.

Unfortunately this will require them to build from scratch the new framework. This is particularly annoying if the dependency tree for that framework is big and / or takes a long time to build.

Use a cache. The first team member (or a CI) can build the framework and share it, while all other developers can get it from the cache with no waiting time.

The Rome's workflow changes depending if you are the producer (i.e. the first person in your team to build the framework) or the consumer.

If you are running Rome in the context of a framework and want to upload the current framework see CurrentMap.

or

If you are running Rome in the context of a framework and want to download the current framework see CurrentMap.

A CI can be both consumer and producer.

A simple workflow for using Rome on a continuous integration should resemble the following:

• get available artifacts
• check if any artifacts are missing
• build missing artifacts if any
• upload build artifacts to the cache if needed

You can use the fastlane plugin for Rome to implement a CI workflow too.

If you are running Rome in the context of a framework and want to upload or download the current framework see CurrentMap.

This workflow relies on .version files being produced by Carthage. This means that you have to invoke carthage with --cache-builds for this to work.

In code:

This workflow relies on querying the cache to check for missing dependencies and then selectively telling Carthage what to build. This flow is more fragile as Carthage will refuse to build indirect dependencies.

In code:

If no frameworks are missing, the awk pipe to carthage will fail and the rest of the command will not be executed. This avoids rebuilding all dependencies or uploading artifacts already present in the cache.

If you plan to use Amazon's S3 as a cache, then follow the next three steps:

• First you need a .aws/credentials file in your home folder. This is used to specify your AWS Credentials.
• Second you need a .aws/config file in your home folder. This is used to specify the AWS Region.
• Third you need a Romefile in the project where you want to use Rome. At the same level where the Cartfile is.

If you just want to use only a local folder as a cache then:

• You need a Romefile in the project where you want to use Rome. At the same level where the Cartfile is. Since 0.17.1.49, if you want to place the Romefile elsewhere or name it differently use --romefile when running rome .

Since version 0.2.0.0 Rome will expect to find credentials either as environment variables $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY or in a file at .aws/credentials. This aligns Rome behavior to other tools that use Amazon's SDK. See Amazon's blogpost on the topic.

In your home folder create a .aws/credentials like the following

this should look something like

these will be the credentials that Rome will use to access S3 on your behalf. To use configurations other than the default profile set the $AWS_PROFILE environment variable to your desired profile.

Since version 0.21.0.58 Rome also supports privilege escalation via Amazon STS by specifying role_arn and source_profile in ~/.aws/config

In your home folder create a .aws/config like the following

To use configurations other than the default profile set the $AWS_PROFILE environment variable to your desired profile.

Alternatively the AWS Region can also be specified by setting an AWS_REGION environment variable.

To your .aws/config in the profile section you wish to use, add an endpoint key like so

Do not remove the region key.

Default port for https endpoints is 443 if the port is left unspecified.

Default port for http endpoints is 9000 if the port is left unspecified.

Alternatively the endpoint can also be specified by setting an AWS_ENDPOINT environment variable.

You can write your own script that Rome will use as engine to execute upload/download/list commands. You start by specifying the path to a script or executable in your Romefile as shown in the example structure. Rome will invoke the specified script or executable with three commands and different parameters based on the action to perform:

• ./script.sh upload local-path remote-path
• ./script.sh download remote-path local-path
• ./script.sh list remote-path

For example, if your Romefile specifies engine: script.sh, Rome will execute the following command when uploading/downloading/listing a framework:

The script should take the given remote-path, carry out its logic to retrieve the artifact and place it at local-path. Please refer to the cache structure definition for more information on the cache is constructed.

For an example of a custom engine, take a look at engine.sh which is used in the integration tests to simply copy artifacts in a different directory. Infinite uses cases are opened by using a custom engine, such as uploading artifacts to any non-compatible S3 storage system.

Other example engines:

• Google Storage

Since version 0.17.0.48 the Romefile is in YAML format. Rome can still read the INI Romefile, for now.

Sucessive release might abandon compatibility.

Feature support that require additions or changes to the Romefile won't be supported in INI.

You can migrate your Romefile to YAML by running rome utils migrate-romefile.

If you are looking for the documention prior to 0.17.0.48, check the wiki

The Romefile has three purposes:

1. Specifies what caches to use - cache key. This key is required.
2. Allows to use custom name mappings between repository names and framework names - repositoryMap key. This key is optional and can be omitted.
3. Allows to ignore certain framework names - ignoreMap key. This key is optional and can be omitted.
4. Allows to specify the current framework's name(s) - currentMap key. This key is optional and can be omitted.

A Romefile is made of 4 objects, of which only one, the cache, is required.

• A cache definition object
• A repositoryMap made of a list of Romefile Entry
• An ignoreMap made of a list of Romefile Entry
• A currentMap made of a list of Romefile Entry

Each Romefile Entry is made of:

• A name
• A type which can be static or dynamic
• A set of supported platforms including iOS, Mac, tvOS, watchOS

A Romefile looks like this:

The cache must contain at least one between:

• the name of the S3 Bucket to upload/download to/from. The key s3Bucket is optional.
• the path to local directory to use as an additional cache. The key local is optional.
• the path to a custom engine to use as an additional cache. The key engine is optional.

This is already a viable Romefile.

This contains the mappings of repository and framework names. This is particularly useful if dependecies are not on GitHub or don't respect the "Organization/FrameworkName" convention.

Example:

Suppose you have the following in your Cartfile

which translates to the following Cartfile.resolved

but your framework names are actually HockeySDK, CatFramework and DogFramework as opposed to HockeySDK-iOS, awesome-framework-for-cat-names and better-dog-names.

simply add a repositoryMap key to your Romefile and specify the following mapping:

Note that it was not necessary to add Alamofire as it respects the "Organization/FrameworkName" convention.

This contains the mappings of repository and framework names that should be ignored. This is particularly useful in case not all your Cartfile.resolved entries produce a framework.

Some repositories use Carthage as a simple mechanism to include other git repositories that do not produce frameworks. Even Carthage itself does this, to include xcconfigs.

Example:

Suppose you have the following in your Cartfile

xcconfigs can be ignored by Rome by adding an ignoreMap key in the Romefile

Each entry in the IgnoreMap is also a Romefile Entry and supports all keys.

By default the currentMap is not used. Specify --no-skip-current as a command line option to use it. It is supported by Rome versions greater than 0.18.x.y and can be specified only in YAML.

The currentMap contains the mappings of repository and framework name(s) that describe the current framework. This is particularly useful if you want to use Rome in the context of a framework. It is the equivalent of Carthage's --no-skip-current.

Each entry in the currentMap is also a Romefile Entry and supports all keys.

The currentMap is subject to the ignores specified in the ignoreMap. If you explicitly specify names of frameworks to upload, download on the command line, you don't need to pass --no-skip-current to use the currentMap. Just specify the name(s) of the current framework.

The version of the current framework is determined by

If the commands does not resolve to any tag, the HEAD commit hash from git rev-parse HEAD is used as version.

In order for --no-skip-current to work, make sure to run carthage archive to create an artifact to cache.

Suppose you have a framework Framework that builds two targets, t1 and t2, Rome can handle both targets by specifying

Note: if ANY of the aliases is missing on S3, the entire entry will be reported as missing when running rome list [--missing]

Multiple aliases are supported in ignoreMap too

Since version 0.30.1 Carthage has support for Static Frameworks. To indicate that one of the aliases is a Static Framework, modify the repositoryMap like so:

If left unspecified, an alias is a Dynamic Framework by default.

Since version 0.17.1.49 Rome allows you to specify what platforms are supported for a specific Romefile Entry. This serves a differet purpose than the command line option --platforms.

The above means that t1 is only available for iOS and Mac. The --platforms command line options can be used to futher limit the Rome command to a specific subset of the supported platfroms.

The following describes the structure of the cache that Rome creates and manages.

By default frameworks, dSYMs and .bcsymbolmaps are placed in the cache (local and/or remote) according to the following convention:

Carthage version files are placed at:

For example the cache for the Cartfile.resolved in RepositoryMap would look like the following

Since version 0.12.0.31 Rome supports prefixes for top level directories in your caches. You can append --cache-prefix MY_PREFIX to all commands. This simply means that both the framework/dSYM and .version file conventional locations can be prefixed by another directory of your choosing. Thus the conventions become:

and

This is particularly useful when the need to cache frameworks at the same version but build with different versions of the compiler arises.

Suppose you want to cache v4.0.0 of DogFramework build for Swift2.1/Swift3.1/Swift3.2/Swift4. Once built you can upload each build with the same version number to a separate top level directory in the cache via the --cache-prefix option.

Thus running for the Swift2.1 build

and running for the the Swift3.2 build

would lead to the following cache structure

Getting help:

Uploading one or more frameworks, corresponding dSYMs, .bcsymbolmaps and Carthage version files if present (an empty list of frameworks will upload all frameworks found in Cartfile.resolved):

Referring to the Cartfile.resolved in RepositoryMap

Uploading for a specific platform (all platforms are uploaded by default):

If a local cache is specified in your Romefile and you wish to ignore it pass --skip-local-cache on the command line.

Since version 0.20.0.56, if you are on a fast Internet connection you can use the --concurrently flag to maximise concurrency for the operation and maximise bandwith use. Using the --concurrently flag should result in a x3 speedup.

Downloading one or more frameworks, corresponding dSYMs, .bcsymbolmaps and Carthage version files if present (an empty list of frameworks will download all frameworks found in Cartfile.resolved):

Referring to the Cartfile.resolved in RepositoryMap

Downloading for a specific platform (all platforms are downloaded by default):

If a local cache is specified in your Romefile and you wish to ignore it pass --skip-local-cache on the command line.

Since version 0.20.0.56, if you are on a fast Internet connection you can use the --concurrently flag to maximise concurrency for the operation and maximise bandwith use. Using the --concurrently flag should result in a x3 speedup.

Listing frameworks and reporting on their availability:

Listing only frameworks present in the cache:

Listing only frameworks missing from the cache:

Listing frameworks missing for specific platforms:

Forwarding a list of missing frameworks to Carthage for building:

Since version 0.13.0.33 list results can also be printed as JSON by specifying --print-format=JSON

Note: list completely ignores dSYMs, bcsymbolmap and Carthage version files. If a dSYM or a Carthage version file is missing, the corresponding framework is still reported as present.

A collection of utilities to make life easier.

Migrate the Romefile from INI to YAML in place, by running:

rome utils migrate-romefile

Implicit dependencies of frameworks when using binaries are not copied over by Xcode automatically despite "Always Embed Standard Libraries" set to YES (see 56).

Here is an example with ReactiveCocoa, which depends on CoreLocation and MapKit. If ReactiveCocoa is built via Carthage or as a Xcode subproject, CoreLocation and MapKit are copied into the app's bundle. On the other hand, when using the binary, Xcode has no clue of that and does not copy the necessary frameworks even if "Always Embed Standard Libraries" is set to yes.

To fix that, add an explicit import statement to one of your files:

Storing artifacts or a the same famework at different Swift versions can be achieved by specifying a cache prefix when using any Rome command like so:

If you prefer a more accurate way of generating cache prefixes for different swift versions consider using the following:

Developing

IDE

Releasing

Presentations and Tutorials

License