CocoaConferences: a community list of Apple developer conferences

What the project is

CocoaConferences is a list of conferences for developers who work in Apple's ecosystems. The README names iOS, iPadOS, macOS, watchOS and tvOS, and the broader technology list extends to UIKit, Swift, SwiftUI, React Native and Flutter, which tells you the audience is Apple platform developers rather than conference organisers.

The site itself lives at cocoaconferences.com, and the repository is the mechanism behind it rather than the product. The list is generated from a single YAML file, _data/conferences.yml, and the whole contribution flow is an edit to that file followed by a pull request. The repository is a Jekyll site, with _config.yml, an _includes/ directory, an index.md home page, a CNAME file for the custom domain, and an api/ directory that the README does not describe in the visible text.

The choice of a static site generator and a single data file is the design. There is no database, no application server and no content management system, so the site cannot break at runtime, and the cost of adding a conference is a pull request rather than a ticket.

The project publishes no GitHub releases, and the last push to the repository was on 2026-10-05. The repository metadata shows the licence as unknown, and no licence file appears in the top level listing, which is worth settling if you want to reuse the data rather than the site.

The data file and what each field means

An entry in conferences.yml has a fixed shape. The README gives the template:

- name: The name of the conference
  link: The URL for the conference website
  location: Text briefly describing where the conference will be held
  start: The day the conference starts (in "year-month-day" format)
  end: The day the conference ends (in "year-month-day" format)
  cocoa-only: true or false
  cfp:
      link: The url at which prospective speakers my respond to the Call For Papers
      deadline: the last day on which a talk proposal may be submitted (in "year-month-day" format)

Two of those fields carry more meaning than they first appear. The cocoa-only flag distinguishes conferences that are specifically for Apple platform work from the general software conferences that happen to have an Apple track, and it is what lets a developer filter the list down to the events that are actually relevant. The cfp block is the reason the site is more than a calendar, because a call for papers deadline is the date a speaker has to act on, and it is usually months before the event.

The dates are written in year-month-day form as unquoted values, which YAML reads as dates rather than strings, and the sorting of the site depends on that.

The README also points at the comments at the top of conferences.yml for the detailed field requirements, which is where the authoritative explanation lives.

Adding a conference and the optional call for papers

The worked example in the README is a three day conference with a call for papers, and it shows the nesting in full:

- name: Example Conf 2019
  link: https://2019.example.com/conference
  location: 🏴 Anytown, Atlantis
  start: 2019-03-04
  end: 2019-03-06
  cocoa-only: true
  cfp:
      link: https://2019.example.com/conference/cfp
      deadline: 2019-01-31

The second example drops the cfp block entirely, and the README explains why that is allowed: the conference may not be accepting submissions, or the call for papers may not be known yet. The cfp section may also be left incomplete rather than removed.

- name: Example Conf 2020
  link: https://2020.example.com/conference
  location: 🏴 Anytown, Atlantis
  start: 2020-03-04
  end: 2020-03-06
  cocoa-only: false

Two practical notes in the README prevent most failed contributions. The indentation of the YAML has to match the other entries exactly, because a mis-indented file will not parse, and the cfp block is indented one level deeper than the top level fields. And when you edit an existing conference you do not have to remove the date fields for past dates, because those are updated automatically.

The contribution flow is short: fork the project, clone it, add the conference to conferences.yml, and open the pull request. The new entry is sorted into place on the site automatically, so nobody has to work out where it belongs. If a contribution is unclear, the README suggests opening an issue instead.

Running the site locally and how it deploys

The site is a standard Jekyll project, so the local workflow is the usual one. The README asks contributors to fork and clone the project, install the dependencies with bundle install, and serve the site:

bundle install
bundle exec jekyll serve

The local site is then available at http://127.0.0.1:4000, which is the default address for a Jekyll development server. The Gemfile and Gemfile.lock are checked in, so the Ruby and gem versions are pinned for contributors, which matters because a Jekyll build that works with one version of a plugin can fail with another.

Deployment is automatic: the README states that deploying is handled when a commit is made to the master branch or when a pull request is merged. Combined with the CNAME file, that is a GitHub Pages setup, and it is why the contribution flow needs nothing but a fork and a pull request. A contributor never has to run a build in order to see their conference on the site.

The repository also carries a .github/ directory, which holds the contribution templates and any workflow configuration.

What a community list can and cannot promise

The value of the site is that it exists at all. A developer looking for Apple developer conferences in a given year would otherwise check a dozen sites, and the call for papers deadlines are the kind of date that is easy to miss entirely. One page, sorted, with the CFP deadline next to the event date, is a genuine convenience.

The limit is obvious and worth stating plainly: every entry is correct only as of the last pull request that touched it. Conferences move, change names, cancel, merge with others or publish their call for papers months after the entry was written, and the site cannot notice. There is no monitoring job described in the README, no feed from the conference organisers and no scheduled refresh, so the accuracy of a given entry is a function of whether a community member cared that week.

The cocoa-only flag is a second source of friction. Deciding whether a conference counts as Apple specific is a judgement call, and the flag is a single boolean with no way to express a partial relationship, so a conference that is half relevant has to be classified one way or the other.

There is a third point about the data itself. The repository has an api/ directory, which suggests a machine readable form of the list exists, and if it does, that is the artefact to use rather than scraping the HTML. The README does not describe it in the visible text, so its shape has to be checked before it is used.

Where CocoaConferences is the wrong tool

The first case is a developer outside the Apple ecosystem. The list is scoped to Apple platforms, with cocoa-only as a filter within that scope, and a developer who wants a general software conference calendar will find a thin list.

The second case is anything that needs verified data. A conference whose CFP deadline has passed but whose entry still says it is open will mislead a speaker who trusts the page, and nothing in the repository catches that. A site that aggregates event listings from the organisers themselves can do better, and for a corporate events team that needs authoritative dates, the conference's own site is the source and this list is a pointer to it.

The third case is a requirement for coverage of a region or a niche. The list is maintained by whoever happens to submit, and the README asks for help, which is the honest description of a community project. A team that needs every Apple conference in a country, with deadlines, would have to do that collecting itself, and once you are collecting it yourself, the YAML file plus a pull request is not much of a saving.

What the project is good for is the opposite case, and it is a real need: a single page to check before you plan your year, a machine readable list if the api/ directory provides one, and a trivial way to add a conference that others have not listed yet.

Editorial conclusion

CocoaConferences fits an Apple developer who wants one page of dates and call for papers deadlines instead of a dozen event sites, and the single YAML file makes it trivial to fork for a regional list. It does not fit a team that needs verified, current conference data, since every entry depends on a human noticing a change. Check first whether your conference of interest is in the list at all, because the site covers Apple related ecosystems rather than the whole conference circuit.

Frequently asked questions

Official sources

1. Issues
2. Lascorbe/CocoaConferences on GitHub
3. Project website
4. README