All modern web browsers employ a multi-process architecture where a single browser application is implemented as a collection of operating system processes with one main process that spawns child processes. This generally involves loading each site in a separate process, and moving certain sensitive functionality (e.g., GPU usage) into a dedicated process. This design allows the browser to be more resilient against crashes, more responsive under load, more secure against malicious exploits, and less susceptible to information leaks like Spectre. Most applications don’t need this level of granular isolation, but for browsers — which load interactive content from many different origins — it’s a table-stakes requirement.

On iOS, Safari uses a multi-process architecture. However, it does so with a proprietary mechanism that is not available to third-party applications unless they use Safari’s WebKit engine. To support third-party browser engines, iOS should provide a mechanism to create and efficiently communicate with isolated child processes.

Some basic requirements:

• The number of child processes and their duration are dictated by user browsing behavior and should not be fixed outside of reasonable device constraints.
• The child process should be configurable with tightly controlled privileges while permitting inter-process communication using messaging and shared memory.
• The parent process must be able to establish shared memory mappings with child processes and vice versa. Child processes must be able to communicate with each other in the same way.
• Access to shared memory regions should be configurable as read/write or read-only per region.
• For optimal security, child processes’ entitlements/privileges should be configured independently from the parent process and the parent process should be able to create child processes of different types using different executables.
• Child processes should be able to load libraries from the bundle that are shared with the parent process.
• To support isolating GPU access to a GPU process, child processes should be able to use Metal or OpenGL (when configured as such) to render into an IOSurface. Child processes should be able to share IOSurfaces across processes.

Firefox uses a shared codebase across different operating systems with platform-specific adapters for functionality like process management. Some quirks may be inevitable, but it’s important that the interface and behavior be broadly similar to other platforms like macOS and Android so as to avoid systematically breaking assumptions in overall browser architecture and platform-specific code. Something shaped like posix_spawn would be a reasonable starting point.