Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use SwiftTerm for QEMU backend #3473

Closed
osy opened this issue Jan 13, 2022 · 3 comments
Closed

Use SwiftTerm for QEMU backend #3473

osy opened this issue Jan 13, 2022 · 3 comments
Labels
enhancement New feature or request
Milestone

Comments

@osy
Copy link
Contributor

osy commented Jan 13, 2022

Currently we use hterm.js for QEMU backend and SwiftTerm for Apple backend. We should switch to SwiftTerm across both backends for both macOS and iOS. The only complication is that SwiftTerm requires iOS 13 and we support down to iOS 11. So there's two possibilities:

  1. We drop support for iOS 11 and iOS 12, which will free up the codebase as well. However, there still seems to be some people who are on an older jailbreak or a device that doesn't support iOS 13.
  2. We drop console mode from < iOS 13, which depends on how many people on < iOS 13 actually use console mode.
  3. We keep both hterm.js for < iOS 13 and use SwiftTerm for iOS 13+. This is the most user friendly but will add even more complexity to the codebase (which is already swelling with conditional code for different platforms and configurations).

Calling for comments on the options above.

@osy osy added the enhancement New feature or request label Jan 13, 2022
@osy osy added this to the v3.1 milestone Jan 13, 2022
@conath
Copy link
Contributor

conath commented Jan 13, 2022

I say 1. - we should drop iOS 11/12 in 3.0 in favor of easier maintainability.

The last compatible version should be made available where possible and maybe a final bugfix update could be released for version 2 before 3 lands. (not sure if needed)

One interesting thought I had just now: maybe we should add some anonymous telemetry to the app so we can make more informed decisions about these kinds of issues. I would suggest TelemetryDeck since you have full control over the data it sends.

@adespoton
Copy link

I was going to say 2, until I read through the outstanding issues, and realized that there are other issues and feature requests that are also incompatible with 13 and below.

And the reality is, devices that are limited to iOS 11/12 are also RAM and CPU-limited. I've tried UTM on both and it's "usable" for running a lightweight BSD or Linux without X (so, console mode only), and possibly Windows XP, but it's not really usable for anything more recent, and even struggles to run Mac OS 9. The additions in 3.x and later are going to make this situation worse, not better, for iOS 11/12 users, so it would make more sense in my opinion to limit support to version 2 with bugfixes.

Having said that, probably worth gathering some degree of telemetry from active users to see how many people are actively using UTM on iOS 11/12. If not via TelemetryDeck, then by a feedback form in a new release of 2.x. Anyone not willing to upgrade to the new release and fill out the feedback form is unlikely going to complain about 3.x dropping support.

@osy
Copy link
Contributor Author

osy commented Jan 22, 2022

Also it’s not like we’ll pull the downloads for older versions. It’s just that it won’t get any new updates which is relevant only to the QEMU backend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants