Use internal when exposing low-level types like IntPtr

Open
#97 0 comments 0 reactions 1 assignee View on GitHub

@ryzngard is already working on this.

Since May 5, 2026.

Assessment

This issue has not been assessed yet.

Description

bug

Is your feature request related to a problem? Please describe.

No, this is about hardening the API.

Exposing low-level types like IntPtr as public in user-facing code is bad practice for an interop library like this. It causes excessive, unnecessary information and APIs being exposed to users, which could lead to confusion and error-prone code being made with it.

Describe the solution you'd like

Refactor client-facing low-level members, constructors, etc. to be internal (or protected internal if necessary). For example, NSArray<T> has a public constructor with an IntPtr parameter. Users do not need to know about this, and makes the API messier for those trying to simply interface with it. Using an AssemblyInfo.cs can allow internal members to be available to other Apple assemblies without having to expose unnecessary data to users.

Describe alternatives you've considered

There are none.

Additional context

https://docs.unity3d.com/2020.1/Documentation/Manual/ScriptCompilationAssemblyDefinitionFiles.html

Example AssemblyInfo.cs file:

using System.Runtime.CompilerServices;

[assembly: InternalsVisibleTo("Apple.Core.Tests")]
Dominant language
C#
Stars
986
Forks
252
Avg merge
1h 36m
Merged PRs (30d)
2

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apple/unityplugins

All issues in apple/unityplugins

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.