search

iced-rs / iced

A cross-platform GUI library for Rust, inspired by Elm
https://iced.rs
MIT License
23.46k stars 1.08k forks source link

Mobile support #302

Open maxtnuk opened 4 years ago

maxtnuk commented 4 years ago

is there any plan to make iced library for mobile? (like Android,iOS )

hecrj commented 4 years ago

There are no plans to officially support mobile platforms for the time being. We are focusing on desktop platforms first.

That said, while I cannot commit to maintaining mobile-specific code, I'd love to see any exploration in this direction. For instance, @simlay added touch support in #57 and I believe they are also experimenting with UIKit.

simlay commented 4 years ago

Yeah, at this point in the iced project I (or anyone really) should probably write something of an RFC about adding iOS support to discuss things about maintainability and what not.

It's a pretty substantial undertaking but not crazy to add iOS support. The biggest concern I have is maintainability. Like for example every new widget feature will need to be updated in the iOS support and there's just not many people that know the weird and annoying things with iOS rust programming so it may be a bit slow.

cryptoquick commented 4 years ago

That said, I think Iced & Rust would have a lot of value to add if compiled to ARM64-native targets, and not using HTML for compositing. In fact, Iced could be a fantastic way to keep all development in one codebase-- a React / Electron / React Native developer's dream.

I cannot understate the value this could provide. I understand you're just one developer, but the impact of this project on application development could be enormous. React has performance issues when scaling, and to sidestep the need for DOM overhead, virtual DOM or repaints entirely would be incredible. WASM binaries are easier to optimize, as well, due to a degree of confident dead code removal that isn't safe to do on JS. The most we can do is tree-shaking of dependencies, and even that is imperfect.

As for React Native and Electron, they also have their respective performance issues. Being able to deliver native app performance, without the overhead of a browser and JS interpreter, just using native target instructions on desktop and mobile apps, would lower size on disk alone by about two orders of magnitude (many 100s of megabytes of Electron or React Native apps, to fewer than 10 megabytes, for most projects). The subsequent impact on resource usage cannot be understated.

That's my vision for this project, and I know it absolutely can be done. The major obstacle is platform idiosyncrasies themselves, but those implementation details, that can be abstracted away by the package in the same way wgpu and native renderers already do, or handled inline with macros, in the same way some small parts of the application might be written differently for web than on native. What's frustrating is, you already have precedent for the modularization of renderers, and that could be incredible for supporting development on pretty much all platforms. Maybe a CLI "UI" could be the icing on the cake... 😹 I would suggest updating your Roadmap, since it's already sorely out of date, and putting the call out for help with this goal, on both iOS and Android. You absolutely are correct for wanting to focus on the core codebase, and what you know best. I just think the adoption of Iced would be enormous, if mobile devices are developed for and supported, as well. And keep in mind, Hector, you've always made it clear this is an alpha project. But imagine if it could fill the shoes of SPAs, Electron apps, and React Native apps, and do it way better (faster and with one codebase in one language-- Rust).

victorstewart commented 4 years ago

I can't commit to this responsibility now as I'm still in the research phase, and wouldn't be beginning the efforts for at least 6 months. That said. My team and I might be interested in assuming responsibility for all things mobile.

Ware about to launch an iOS app (native UI via Texture Group then all custom everything and animations built on top of that) once the virus situation is over. And for our 2.0, creating an Android version is priority # 1.

But rather than creating and maintaining a native iOS app + an Android (because performance is critical for us) and all the endless headaches that would entail, I've been thinking there's no reason why nowadays that there isn't a platform agnostic UI library that provides "native over vulkan" (because let's leave OpenGL in it's grave lol). And that if there weren't one already, then it might be worth our time to build.

Which lead me here to you all, and i'm vibing with the fact we seem to be on the same page about this.

knocte commented 4 years ago

I just bumped into this project, looks very interesting. I'm surprised it's not mobile-first (and desktop-second) like all other popular agnostic platform UI toolkits out there nowadays. IMNSHO that's the key to their success (e.g. Xamarin.Forms), because desktop is fading...

Maybe instead of adding mobile support to iced, it's simpler to create a new toolkit (similar to iced) toolkit that abstracts Android and iOS only at first, and later add desktop. This is just my 2cents because I cannot commit to this effort, but if it was done this way and works, I'd probably move out from .NET altogether and embrace Rust for all my dev needs!

Happy hacking.

zyansheep commented 3 years ago

I wonder where one would even start implementing an abstraction layer... The desktop rendering backend uses Vulkan so could that be copied? I guess the hard part would be dealing with all the various APIs for permissions and inputs and such.

pickfire commented 3 years ago

I wonder where one would even start implementing an abstraction layer... The desktop rendering backend uses Vulkan so could that be copied? I guess the hard part would be dealing with all the various APIs for permissions and inputs and such.

We could probably take a look at how flutter does it.

librelois commented 3 years ago

Hum, I don't understand :thinking:

Both wgpu and winit already support Android and iOS.

Wouldn't it be simpler to force the use of the wgpu renderer and winit shell for Android and iOS targets ?

The wgpu renderer is precisely designed so that those who rely on it don't have to worry about "platform specific" logic, the same goes for winit. If we only go through these layers, it seems to me that there would be no maintenance overhead.

I feel like I'm missing something, can someone enlighten me?

cryptoquick commented 3 years ago

@librelois I'm not a mobile developer, so there may be some "devil in the details", but I've wondered similar with regards to cargo mobile, since it supports both renderers.

Dispersia commented 3 years ago

Ya, basically everything it relies on already supports android (to some extent). iced

Took about an hour to get most of the examples working. Things that need fixed:

Even though that's several things, most of it is super simple to do, otherwise everything else just seems to work.

depending on time commitments, might be interested in getting this moved forward, at least for android. don't have iOS nor a mac so can't really help there (most things should be cross plat, but there might be specific bugs I'm unaware of). More interested in moving to wgsl (hopefully everything needed is supported) and killing off shader-c before doing the android stuff.

reivilibre commented 3 years ago

I 'ported' Iced to be able to run on my PinePhone (https://bics.ga/reivilibre/iced-mobile/src/commit/2dc42b4a22ffc31a83297bfed7641e3737a0a940 if anyone is interested in the code; there is a tour_glow example for demonstration), which basically just came down to making the code compatible with older OpenGL (including https://github.com/hecrj/glow_glyph/issues/4).

It actually looks quite good, but the following issues/considerations need to be kept in mind:

The awkwardness around tapping things may be because we need to handle touch events specially (and make those toggles a bit bigger for mobile!). Popping open the on-screen keyboard, as far as I know, involves making a D-Bus call.

Other than that, I don't think we're too far away from having something working quite nicely -- though it would be nice to add support for Images to the glow backend eventually (c.f. #846).

victorstewart commented 3 years ago

i think it would be super helpful if we put together an agenda of work that would need to be accomplished to achieve full iOS and Android support

13r0ck commented 3 years ago

@victorstewart Andoid Ios

jedugsem commented 2 years ago

if you force the x11 winit backend touch works fine

jedugsem commented 1 year ago

@Dispersia could you share the steps you took to make it work because it looks like it would totally work in my usecase for a private app asking me question about an exam which i would like to do on my phone

zh4ngx commented 1 year ago

@Dispersia yes, please do share if you can. Would love to see it as well.

dejang commented 5 months ago

@Dispersia, I'm also interested in what you did to make mobile work. I'm curious more about iOS but doesn't hurt to know what you did, in principle, to get it working on Android.

Dispersia commented 5 months ago

@dejang Sorry, unfortunately that was years ago and I don't think i had any steps outside of what I described under the post, and don't know if they're even still applicable (draw types were changes in wgpu so that might not be needed anymore, and the winit bug was definitely fixed)

Otherwise I just kept running it, it failing, then fixing it and going to the next problem haha. Sorry I can't help more, as I haven't touched Iced since the android issue was closed with them not wanting to support it and went a different path (this is in no way shade to the project, just didn't fit my needs since I was wanting it for mobile)

rhjdvsgsgks commented 3 months ago

i have some small progress. it can display something now, within 100 line of change. but font/input/resume still need to be worked on 1

Flying-Toast commented 3 weeks ago

Is it possible to build for web and use webviews to render on mobile? Like how Dioxus does it?

zh4ngx commented 2 weeks ago

Is it possible to build for web and use webviews to render on mobile? Like how Dioxus does it?

Unless you're referring to canvas, this would defeat the purpose of using something like iced to do high-performance rendering.

jedugsem commented 2 weeks ago

i have some small progress. it can display something now, within 100 line of change. but font/input/resume still need to be worked on 1

Hello can you publish your changes, would be interested in reading them

ibaryshnikov commented 2 weeks ago

Current state of affairs is that integration example works on android with almost no changes.

Since iced relies on softbuffer, there's a work-in-progress fix for it https://github.com/rust-windowing/softbuffer/issues/44#issuecomment-1594931253

And here's a working example https://github.com/ibaryshnikov/android-iced-example

jedugsem commented 2 weeks ago

thank you