holzschu
commented
1 year ago There are technical and legal restrictions that prevent having a full package manager. Basically, binaries can only be loaded and executed if:
- they have been signed with the developer certificate,
- they are placed in a specific directory, that can only be accessed for writing by the application install process (it's
$APPDIR, if you want to explore). Both conditions must be satisfied. So, for the time being, there is no way to have a full package manager, whether based on binaries or source code. There is a small package manager in a-Shell (pkg), that uses binaries compiled to WebAssembly, because there are no restrictions on executing WebAssembly code. But then WebAssembly itself is very limited, and very few programs can be compiled to WebAssembly.
There are also differences between the formats for Arm64 binaries for OS X and the Arm64 binaries for iOS, so you cannot just copy binaries generated for OS X to an iOS app.
On top of the binary format issues, there are the restrictions from iOS itself: there is no fork(), no exec(), no system(), no usable stdout and stdin, no curses library, you have to make sure that memory is released when leaving... Just cross-compiling a program to Arm64 on iOS is already quite difficult, but it's only the beginning.
Also keep in mind that the FSF has said that all GPL programs are incompatible with AppStore distribution, so (for example) emacs has another limitation.
I just discovered a-shell—thanks for this project! Perhaps a new iPad Pro M2 chip could be useful after all! Apparently the restrictions on shared libraries make this a nonstarter for on-device builds.
Would you please comment about the practicalities of building an actual package manager for iOS/iPadOS? The first thing I started looking into with a-shell is how to download and compile new code with a package manager. MacPorts—which has a heavy emphasis on source-code based builds—could be ideal for this.
How would one copy native arm64 binaries into an a-shell build? Then how would this build be deployed?
I personally would prefer a much more loaded a-shell: emacs, tclsh, more Python libraries, and so forth. ِEven at 20 GB app that eases iPadOS many limitations would be awesome.