4 ms·

I use it so I can have a full development environment natively on device. My iPad turned into a portable SSH or X server. Great for when I’m on the go and can e

I use it so I can have a full development environment natively on device. My iPad turned into a portable SSH or X server. Great for when I’m on the go and can even use my laptop to control it to avoid the bad keyboard and lack of mouse

derefr 6y ago
> X Server This wouldn't require a jailbreak. There's nothing stopping anyone from making a no-compromises X11 server as a fully-sandboxed iOS App Store app. > SSH server (i.e. POSIX environment) There's technically no reason that this should require a jailbreak, either, though an implementation of this that conforms to App Store policies would work a bit differently than people would intuitively expect from e.g. Linux. Rather than going in and installing packages through a package-manager, any additional executable binaries you wanted would have to ship embedded into some code-signed App Store app, (i.e. put Apple's auditors in the path those binaries take to client devices.) The obvious way to structure it would be to have one "base" app that sets up the skeleton of the POSIX environment and which also acts as a terminal emulator; and then have other apps that are installed to serve as "plugins" for the environment, adding their embedded binaries into the "base" environment (similar to how XCode.app and Server.app integrate their utilities into macOS's $PATH—but in a Shared Container rather than in the host filesystem.) Compiling things and running them doesn't seem to be restricted completely any more, either, given that Swift Playgrounds exists. (I think it's just custom runtime JITs that are disallowed. Seemingly, if you have a compiler that writes an executable to storage and then fork(2)+exec(2)s it into a new process running under your app, that's fine.)
- MaxLeiter 6y ago
  There's nothing stopping people except the time and effort required. For fontconfig and some other nice to have programs (X itself builds fine) you need to either patch them or modify the SDK you're building against to remove the compiler attributes. Apple won't allow the latter on the app store, and the former would be a significant amount of work. There are terminal emulators and X servers on the app store now, but the problem is the limitations of the sandbox and performance. Alpine and an X server can be run on Qemu, but performance is far better with the native server. And, Swift Playgrounds is an Apple product. They don't hold themselves to the same limitations as 3rd party app developers.
- ViViDboarder 6y ago
  There’s already iSH[1] that emulates an x86 Alpine Shell and UTM[2] which provides x86 emulation with a full GUI. You can either join their Test Flight to install (until Apple takes it down), build and install yourself (good for 90 days and then you have to rebuild), or Jailbreak and install with no hassle. So, jailbreaking is definitely not necessary, but would be easier due to Apples code signing policies. [1] https://ish.app/ https://ish.app/ [2] https://getutm.app/ https://getutm.app/
  - saagarjha 6y ago
    UTM is not available via TestFlight because it requires entitlements that cannot be used for apps submitted to Apple. UTM also does a lot more than just x86.
  - jsjohnst 6y ago
    > good for 90 days and then you have to rebuild s/90 days/1 year/ per: https://getutm.app/install/ https://getutm.app/install/
- AnthonyMouse 6y ago
  > Compiling things and running them doesn't seem to be restricted completely any more, either, given that Swift Playgrounds exists. (I think it's just custom runtime JITs that are disallowed. Seemingly, if you have a compiler that writes an executable to storage and then fork(2)+exec(2)s it into a new process running under your app, that's fine.) If this is allowed then anybody could blow a hole through the "walled garden" the size of an interstate highway just by providing a compiler that does this, which would allow arbitrary third parties to distribute their apps as source code anybody could compile and run. Somehow I suspect if you actually did this they would shut it down, otherwise why isn't everybody already doing it? But if you can't then you hardly have anything like a POSIX environment, which is all about creating and running your own scripts and other code.
  - saagarjha 6y ago
    iOS apps cannot fork. (I have not tried to see if they can exec.)
- plorkyeran 6y ago
  Swift Playgrounds are not something that a third party could publish to the app store.
- joshspankit 6y ago
  You’re missing a major difference between jailbroken X/SSH server and sandboxed: In jailbroken you don’t need the app open (or even the sreen unlocked) in order to connect to it.

derefr 6y ago

> X Server This wouldn't require a jailbreak. There's nothing stopping anyone from making a no-compromises X11 server as a fully-sandboxed iOS App Store app. > SSH server (i.e. POSIX environment) There's technically no reason that this should require a jailbreak, either, though an implementation of this that conforms to App Store policies would work a bit differently than people would intuitively expect from e.g. Linux. Rather than going in and installing packages through a package-manager, any additional executable binaries you wanted would have to ship embedded into some code-signed App Store app, (i.e. put Apple's auditors in the path those binaries take to client devices.) The obvious way to structure it would be to have one "base" app that sets up the skeleton of the POSIX environment and which also acts as a terminal emulator; and then have other apps that are installed to serve as "plugins" for the environment, adding their embedded binaries into the "base" environment (similar to how XCode.app and Server.app integrate their utilities into macOS's $PATH—but in a Shared Container rather than in the host filesystem.) Compiling things and running them doesn't seem to be restricted completely any more, either, given that Swift Playgrounds exists. (I think it's just custom runtime JITs that are disallowed. Seemingly, if you have a compiler that writes an executable to storage and then fork(2)+exec(2)s it into a new process running under your app, that's fine.)

MaxLeiter 6y ago
There's nothing stopping people except the time and effort required. For fontconfig and some other nice to have programs (X itself builds fine) you need to either patch them or modify the SDK you're building against to remove the compiler attributes. Apple won't allow the latter on the app store, and the former would be a significant amount of work. There are terminal emulators and X servers on the app store now, but the problem is the limitations of the sandbox and performance. Alpine and an X server can be run on Qemu, but performance is far better with the native server. And, Swift Playgrounds is an Apple product. They don't hold themselves to the same limitations as 3rd party app developers.
ViViDboarder 6y ago
There’s already iSH[1] that emulates an x86 Alpine Shell and UTM[2] which provides x86 emulation with a full GUI. You can either join their Test Flight to install (until Apple takes it down), build and install yourself (good for 90 days and then you have to rebuild), or Jailbreak and install with no hassle. So, jailbreaking is definitely not necessary, but would be easier due to Apples code signing policies. [1] https://ish.app/ https://ish.app/ [2] https://getutm.app/ https://getutm.app/
- saagarjha 6y ago
  UTM is not available via TestFlight because it requires entitlements that cannot be used for apps submitted to Apple. UTM also does a lot more than just x86.
- jsjohnst 6y ago
  > good for 90 days and then you have to rebuild s/90 days/1 year/ per: https://getutm.app/install/ https://getutm.app/install/
AnthonyMouse 6y ago
> Compiling things and running them doesn't seem to be restricted completely any more, either, given that Swift Playgrounds exists. (I think it's just custom runtime JITs that are disallowed. Seemingly, if you have a compiler that writes an executable to storage and then fork(2)+exec(2)s it into a new process running under your app, that's fine.) If this is allowed then anybody could blow a hole through the "walled garden" the size of an interstate highway just by providing a compiler that does this, which would allow arbitrary third parties to distribute their apps as source code anybody could compile and run. Somehow I suspect if you actually did this they would shut it down, otherwise why isn't everybody already doing it? But if you can't then you hardly have anything like a POSIX environment, which is all about creating and running your own scripts and other code.
- saagarjha 6y ago
  iOS apps cannot fork. (I have not tried to see if they can exec.)
plorkyeran 6y ago
Swift Playgrounds are not something that a third party could publish to the app store.
joshspankit 6y ago
You’re missing a major difference between jailbroken X/SSH server and sandboxed: In jailbroken you don’t need the app open (or even the sreen unlocked) in order to connect to it.