에뮬레이션 아키텍처와 JIT 격차
iSH는 iOS 샌드박스 제한을 우회하기 위해 정교한 이중 레이어 에뮬레이션 전략을 통해 작동합니다. 첫 번째 레이어는 Linux 커널을 에뮬레이션하여 시스템 호출(syscalls)을 iOS 스레드에 매핑하고, 두 번째 레이어인 Asbestos 인터프리터는 어셈블리 수준의 직접 스레딩을 통해 x86 코드 실행을 처리합니다. 그러나 이러한 추상화 레이어는 심각한 성능 저하를 초래하며, 종종 네이티브 코드보다 5-100배 느린 벤치마크 결과를 보입니다. JIT 없이는 iSH는 모든 명령어를 스크립트처럼 해석해야 하므로, 네이티브 실행과 경쟁할 수 없습니다.
기술적 잠재력과 BrowserEngineKit
BrowserEngineKit에서 영감을 받은 아키텍처로 프로토타이핑을 진행한 결과, iSH 팀은 JIT 컴파일이 즉각적으로 2-5배의 속도 향상을 가져오고, 잠재적으로는 10배 이상의 개선을 이룰 수 있음을 확인했습니다. 이는 Apple이 Safari와 macOS의 Rosetta 2에서 JIT를 사용하는 방식과 일치하며, 네이티브 코드 생성이 경쟁력 있는 성능을 위한 유일한 경로임을 증명합니다. iSH는 Apple이 실행 가능한 메모리와 관련하여 일반적으로 우려하는 위험을 완화하기 위해 메모리 안전 언어와 프로세스 격리를 사용하는 보안 우선 JIT 모델을 제안했습니다.
규제 마찰: 상호운용성 요청
iSH는 디지털 시장법(DMA) 제6조 7항을 근거로, 이전에 Safari에만 허용되었던 JIT API에 접근하기 위한 상호운용성 요청을 제출했습니다. 견고한 보안 모델을 제시했음에도 불구하고, Apple은 이 요청을 거부했습니다. 그들의 논리—자신들이 에뮬레이션을 직접 제공하지 않으므로 해당 기술을 공유할 의무가 없다는—는 Apple이 이미 점유하고 있는 범주로 혁신이 제한되는 순환 논리를 만듭니다. 이러한 ‘Anti-Sherlock’ 입장은 서드파티 개발 도구가 iOS에서 인위적인 성능 한계에 계속 직면할 것임을 시사합니다.