Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 14 additions & 12 deletions docs/getting-started/mobile/ios/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,12 +22,19 @@ sidebar_position: 1
$ git clone https://github.com/bitwarden/ios
```

2. Install [Mint](https://github.com/yonaskolb/mint):
2. Install [Homebrew](https://brew.sh/) dependencies (including
[Mint](https://github.com/yonaskolb/mint)) from the repository root:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❓ I feel like calling out Mint is an artifact from when we only brew installed Mint. Maybe we should leave the mention off here, and migrate things later in the file to not call out Mint specifically?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this suggestion. If we take the Mint callout out of step 2, does it still make sense to have the "alternative" Mint install instructions on line 38?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say it makes sense to remove it there, too. It's an artifact from when mint was the only thing we'd install with homebrew.


```sh
$ brew install mint
$ cd ios

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

πŸ€” is the cd ios necessary, since we also say "from the repository root"? It doesn't hurt, I suppose

$ brew bundle
```

> **Note** The dependencies are listed in the
> [`Brewfile`](https://github.com/bitwarden/ios/blob/main/Brewfile). `Scripts/bootstrap.sh`
> checks that they are installed, so re-run `brew bundle` if bootstrapping reports missing
> dependencies.

Alternatively, if you prefer to install Mint without `brew`, clone the Mint repo into a temporary
directory and run `make`.

Expand Down Expand Up @@ -97,17 +104,12 @@ sidebar_position: 1
$ bundle exec fastlane --version
```

When necessary, update the Ruby version with:

```
$ rbenv install 3.4.4
Comment thread
tomhartnett-bw marked this conversation as resolved.
```
If you see an error that a Ruby version is not installed, or that you should run

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

πŸ€” While we use fastlane on CI, I don't know that we need to include it anymore for local discussion, unless there's something I'm missing? @vvolkgang you may want to weigh in.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, it should only needed if you need to work on fastlane stuff, @tomhartnett-bw let me know if that's not the case.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we saying we should take out this troubleshooting comment about the Ruby version on lines 107–108, or clarify that step 4, beginning on line 80, applies to ci/automation and is not needed for local development?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should keep it in, but clarify that it's only needed if you're going to be doing local development of CI/automation flows.

`bundle install`, re-run `rbenv install -s` and `bundle install` from the root of the `ios` repo.

Update dependencies with:

```
$ bundle update
```
> **Note** Only run `bundle update` when you intend to upgrade the project's Ruby dependencies.
> It resolves the newest gem versions allowed by the `Gemfile` and rewrites `Gemfile.lock`, which
> then needs to be committed.

If you're still having issues, here are some helpful commands for troubleshooting:

Expand Down