The Problem

Developers who need to write, compile, and run native iOS code while away from a Mac face a missing toolchain on the device itself. Current solutions require a jail‑broken phone or a constant cloud connection, which breaks workflow continuity and raises security concerns.

What This Does

emexDE bundles a full on‑device IDE that supports Swift, Objective‑C, Objective‑C++, C and C++. The core compiler lives in CoreCompiler/ (e.g., CCDriver.cpp, CCSwiftCompiler.cpp) and is driven by the mobile‑dev kit in MobileDevelopmentKit/ (e.g., MDKCompiler.m, MDKSwiftCompiler.m). UI and runtime support are in Nyxian/, where the Xcode project (Nyxian.xcodeproj) defines the app target and resources (Assets.xcassets). A small set of entry‑point templates (Shared/Templates/Utility/C++/Main.cpp and Shared/Templates/Utility/C/Main.c) illustrate how a user‑supplied program is handed to the compiler pipeline.

How It Is Wired

Execution begins with the iOS app launch defined in Nyxian/main.m. That file creates the UI and eventually calls LiveProcess/main.m, which invokes the LiveContainer layer (LCBootstrap.mLCMachOUtils.m). The bootstrap loads the user source (e.g., the Main.cpp template) and passes it to the CoreCompiler driver (CCDriver.cpp).

CCDriver parses the source, selects the appropriate language backend (CCSwiftCompiler for Swift, CCCompiler for C/C++), and runs the compilation steps:

  1. Lexing / ASTCCASTUnit.cpp builds an abstract syntax tree.
  2. Dependency scanningCCDependencyScanner.cpp discovers headers and modules.
  3. Code generationCCCompiler.cpp produces object files.
  4. LinkingCCLinker.cpp creates a Mach‑O binary.
  5. Signing – the ZSign utilities (ZSign/Utils.cpp, ZSign/archo.cpp) apply the developer certificate.

The resulting binary is handed back to LiveContainer which loads it into the sandboxed process via LCUtils.m. All file system writes occur under the app’s container; no external network calls are evident in the static analysis.

The import graph reports 0 internal modules and 0 edges, indicating that the repository does not use a module system (e.g., Swift Packages) and that static analysis could not resolve cross‑module imports. Consequently, the call‑graph is limited to the files listed above.

How To Use It

# Clone the repo (preserve submodules)
git clone --recursive https://github.com/moses-y/emexDE
cd emexDE

# Build the app (the Makefile wraps xcodebuild)
make        # invokes xcodebuild using Nyxian.xcodeproj

# Deploy to a device (requires a signing certificate)
# The README points to an Installation Guide; the repo itself contains
# the entitlements file LiveProcess/LiveProcess.entitlements.

No environment variables or external package managers are present. The Makefile is the sole build orchestrator; any missing steps must be added by the integrator.

Real‑World Use

A field engineer can open the app, paste a Swift snippet into the built‑in editor, tap “Run”, and the workflow above compiles the code on the device, links it, signs it with the installed certificate, and launches it in a sandboxed container. This enables rapid prototyping of utilities without a Mac.

Code Health & Issues

  • HIGH – Add a test suite – 127 source files but no test files.
  • MEDIUM – Least‑privilege GITHUB_TOKEN.github/workflows/build.yml lacks explicit permissions:.
  • MEDIUM – Large binaries in repoShared/swift.zip (16.9 MiB) and OpenSSL frameworks exceed 5 MiB, inflating clone size.
  • HIGH – Deep nesting – Files such as Nyxian/LindChain/OpenSSL.xcframework/.../rc4.h have indentation depth 9, making control flow hard to follow.

No structural red flags beyond the items above were detected.

The Bottom Line

emexDE delivers a functional on‑device iOS IDE with a complete compilation pipeline, but the codebase suffers from poor test coverage, excessive binary bloat, and maintainability issues (deeply nested headers). It is suitable for teams that need immediate on‑device development and are prepared to invest in improving test infrastructure and refactoring high‑complexity areas.