Mobile support

[maxtnuk]

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

[hecrj]

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]

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]

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]

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]

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]

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]

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]

Hum, I don't understand 🤔

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]

@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]

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

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

• Font loading (font-kit relies on things that android doesn't support, possibly check out RustType?)... currently just disable default_system_font feature and it works
• Currently uses Bgra8UnormSrgb texture format, just needs changed to something that works cross mobile platforms
• Handle Suspend/Resumed events from winit... this is extremely easy to implement
• Fix sizing (this is a thing that basically all winit apps on mobile need to do, I think should be easy here but might take a bit of time)
• A lot of things work off of current mouse position, touch events work for "interacting" but that's about the extent of what they handle vs touch events
• winit "bug" where redraw_requested isn't supported and does nothing, just needs to draw when nothing left to do instead, or just get the winit bug fixed (which has an open PR with suggestions for a better fix): Android: add request_redraw based on ndk_glue rust-windowing/winit#1822

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]

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 hecrj/glow_glyph#4).

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

• it's awkward to tap buttons (they don't always trigger) and, in my experience, impossible to click the toggle switches (I had to connect a Bluetooth mouse to continue that part of the tour).
• the on-screen keyboard does not automatically open when a text field is focussed.
• I don't think Iced has any gestures that you'd expect on mobile (like drag to scroll)

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]

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]

@victorstewart
Andoid
Ios

[jedugsem]

if you force the x11 winit backend touch works fine

[jedugsem]

@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]

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

[dejang]

@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]

@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]

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

[Flying-Toast]

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

[zh4ngx]

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]

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

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

[ibaryshnikov]

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
rust-windowing/softbuffer#44 (comment)

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

[jedugsem]

thank you