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.