Firefox for iOS

Download on the App Store.

This branch

This branch is for mainline development that will eventually ship as v5.0.

See the v5.x branch if you're doing stabilization work for v5.0. If you are interested in fixing a bug on the v5.x stabilization branch, take a look at the list of open bugs that are marked as tracking 5.0.

This branch works with Xcode 7.3.1, and supports iOS 8.2 and 9.x. Although you can only run and debug from Xcode on a 9.2.1 device.

Please make sure you aim your pull requests in the right direction.

Getting involved

We encourage you to participate in this open source project. We love Pull Requests, Bug Reports, ideas, (security) code reviews or any kind of positive contribution. Please read the Community Participation Guidelines.

• IRC: #mobile for general discussion and #mobistatus for team status updates.
• Mailing list: [email protected].
• Bugs: File a new bug • Existing bugs

Want to contribute but don't know where to start? Here is a list of Good First Bugs.

This is a work in progress on some early ideas. Don't get too attached to this code. Tomorrow everything will be different.

Likewise, the design and UX is still in flux. Don't get attached to them. They will change tomorrow! https://mozilla.invisionapp.com/share/HA254M642#/screens/63057282?maintainScrollPosition=false

GitHub issues are enabled on this repository, but we encourage you to file a bug (see above). We'll accept issues to track work items that don't yet have a pull request, and also as an early funnel for bug reports, but Bugzilla is the source of truth for lots of good reasons — issues will be shifted into Bugzilla, and pull requests need a bug number.

Building the code

As of March 28, 2016, this project requires Xcode 7.3.

1. Install the latest Xcode developer tools from Apple.
2. Install Carthage

brew update
brew install carthage

1. Clone the repository:

git clone https://github.com/mozilla/firefox-ios

1. Pull in the project dependencies:

cd firefox-ios
sh ./bootstrap.sh

1. Open Client.xcodeproj in Xcode.
2. Build the Fennec scheme in Xcode.

It is possible to use App Code instead of Xcode, but you will still require the Xcode developer tools.

Contributor guidelines

Creating a pull request

• All pull requests must be associated with a specific bug in Bugzilla.
• If a bug corresponding to the fix does not yet exist, please file it.
• You'll need to be logged in to create/update bugs, but note that Bugzilla allows you to sign in with your GitHub account.
• Use the bug number/title as the name of pull request. For example, a pull request for bug 1135920 would be titled "Bug 1135920 - Create a top sites panel".
• Finally, upload an attachment to the bug pointing to the GitHub pull request.

1. Click Add an attachment.
2. Next to File, click Paste text as attachment.
3. Paste the URL of the GitHub pull request.
4. Enter "Pull request" as the description.
5. Finally, flag the pull request for review. Set the review field to "?", then enter the name of the person you'd like to review your patch. If you don't know whom to add as the reviewer, click suggested reviewers and select a name from the dropdown list.

Pro tip: To simplify the attachment step, install the Github Bugzilla Tweaks addon. This will add a button that takes care of the first four attachment steps for you.

Swift style

• Swift code should generally follow the conventions listed at https://github.com/raywenderlich/swift-style-guide.
  • Exception: we use 4-space indentation instead of 2.

Whitespace

• New code should not contain any trailing whitespace.
• We recommend enabling both the "Automatically trim trailing whitespace" and "Including whitespace-only lines" preferences in Xcode (under Text Editing).
• git rebase --whitespace=fix can also be used to remove whitespace from your commits before issuing a pull request.

Commits

• Each commit should have a single clear purpose. If a commit contains multiple unrelated changes, those changes should be split into separate commits.
• If a commit requires another commit to build properly, those commits should be squashed.
• Follow-up commits for any review comments should be squashed. Do not include "Fixed PR comments", merge commits, or other "temporary" commits in pull requests.