keepcalculator

06 Numbers and Powers

Apple Removing Non-Inclusive Terms: What Changes

Card No. 06·20410 · Updated · Standard formula, shown below

Apple is systematically removing non-inclusive language from its software, developer tools, and documentation, replacing terms like “master/slave” and “blacklist/whitelist” with more neutral alternatives. This article explains what the changes are, why Apple is making them, how they affect developers and users, and what to expect going forward.

Background: Why Apple Is Making These Changes

The tech industry has been reviewing its use of language for several years, driven by broader social movements and a growing awareness that certain terms carry harmful historical connotations. Apple’s efforts are part of a larger industry trend—companies like Google, Microsoft, and IBM have all announced similar initiatives. For Apple, the goal is to ensure that its ecosystem feels welcoming to everyone, regardless of background. The changes are not about erasing history but about choosing words that describe technical concepts without evoking oppression or discrimination.

What Terms Are Being Replaced

Apple has identified a list of terms that are being phased out across its platforms. Some of the most notable replacements include:

  • Master/slave → primary/secondary or main/standby (used in hardware and software contexts)
  • Blacklist/whitelist → deny list/allow list (used in security and filtering)
  • Black hat/white hat → malicious/ethical (in security documentation)
  • Sanity check → smoke test or quick check (in testing)
  • Man hours → person hours or work hours (in project management)
  • Crazy or insane → extreme or unbelievable (in product descriptions)

These changes are being applied to Apple’s own code, APIs, and documentation. For example, in Xcode (Apple’s development environment), the “master branch” of a version control repository is now called “main branch”—a change that aligns with broader industry practice.

How the Changes Are Implemented

Apple is making these changes at multiple levels:

  • System software: macOS, iOS, iPadOS, watchOS, and tvOS have been updated to remove non-inclusive terms from system interfaces, error messages, and accessibility features.
  • Developer tools: Xcode, Swift, and other development frameworks have updated their APIs and templates. For instance, the “master” branch in Xcode’s source control is now “main.”
  • Documentation: Apple Developer documentation has been revised to use the new terminology across all guides and references.
  • App Store: App review guidelines have been updated to discourage developers from using non-inclusive language in their own apps and metadata.

Apple has also provided a Style Guide for developers, which outlines preferred terms and explains the reasoning behind each change. This guide is updated regularly as new terms are identified.

Impact on Developers and Users

For most users, the changes are invisible—they simply see new words in settings or error messages. For developers, however, the impact is more significant. Code that references old API names may need to be updated, and documentation searches may return different results. Apple has tried to ease the transition by:

  • Keeping deprecated APIs available for a transition period (with warnings).
  • Providing migration guides for common replacements.
  • Updating Xcode’s code completion to suggest new terms.

Despite these efforts, some developers have expressed frustration over the volume of changes, especially in large codebases. However, most acknowledge that the long-term benefit of a more inclusive ecosystem outweighs the short-term inconvenience.

Common Misconceptions and Challenges

One common misconception is that Apple is removing all terms that could be considered offensive, which is not the case. The focus is on terms with clear historical ties to oppression, not on every word that someone might find uncomfortable. Another misconception is that the changes are purely cosmetic—in reality, they can affect code functionality if developers don’t update their references correctly.

Challenges include:

  • Backward compatibility: Old code may break if it relies on deprecated names.
  • Third-party libraries: Developers may need to wait for library maintainers to update their own code.
  • Habit: It takes time for developers to break the habit of using old terms.

Apple has mitigated these issues by keeping deprecated symbols available for a while and issuing clear warnings when they are used.

How to Stay Updated and Adapt

If you are a developer, the best way to stay current is to:

  1. Review Apple’s Style Guide regularly (available on the Apple Developer website).
  2. Use Xcode’s built-in migration tools when upgrading projects.
  3. Search your codebase for old terms and replace them with new ones.
  4. Follow Apple’s release notes for each new OS version.

For users, no action is needed—the changes are automatic with system updates. If you encounter any old terms in your apps, they are likely from third-party developers who haven’t updated yet.

Frequently Asked Questions

Will my existing apps break because of these changes?

No, existing apps will continue to work. Apple is keeping deprecated APIs functional for a transition period, so even if an app uses old terms, it will still run. However, developers are encouraged to update their code to avoid future compatibility issues.

Is Apple the only company doing this?

No, Apple is part of a broader industry movement. Google, Microsoft, IBM, and many open-source projects have also adopted more inclusive language. Apple’s changes are notable because of the size of its ecosystem, but they are not unique.

What if I prefer the old terms?

You are free to use whatever language you like in your own code, but Apple’s official tools and documentation will use the new terms. If you submit an app to the App Store, Apple’s review guidelines encourage inclusive language, so it’s best to follow the new standards.

Are there any terms that are still under review?

Apple has not published a complete list of future changes, but it has stated that the review is ongoing. Terms like “dummy” (in programming) and “segregate” (in memory management) have been flagged as potentially problematic and may be changed in future releases.

How can I report a term that I find offensive?

Apple encourages developers and users to provide feedback through its official feedback channels (e.g., the Feedback Assistant app). While there is no guarantee that every suggestion will be acted upon, Apple does take such reports seriously.

Do the changes affect accessibility features?

Yes, accessibility features have also been updated. For example, VoiceOver descriptions and accessibility labels now use the new terminology. This ensures that all users encounter consistent, inclusive language.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →