ios seems broken again in iced winit

[aentity]

error[E0432]: unresolved import `winit::platform::run_return`
   --> /Users/aentity/.cargo/git/checkouts/iced-9e73d2fbe1fce35a/1a31aef/winit/src/application.rs:118:26
    |
118 |     use winit::platform::run_return::EventLoopExtRunReturn;
    |                          ^^^^^^^^^^ could not find `run_return` in `platform`

error[E0599]: no method named `run_return` found for struct `EventLoop<<A as iced_native::Program>::Message>` in the current scope
   --> /Users/aentity/.cargo/git/checkouts/iced-9e73d2fbe1fce35a/1a31aef/winit/src/application.rs:182:16
    |
182 |     event_loop.run_return(move |event, _, control_flow| {
    |                ^^^^^^^^^^ method not found in `EventLoop<<A as iced_native::Program>::Message>`

error[E0614]: type `winit::event_loop::ControlFlow` cannot be dereferenced
   --> /Users/aentity/.cargo/git/checkouts/iced-9e73d2fbe1fce35a/1a31aef/winit/src/application.rs:209:13
    |
209 |             *control_flow = match poll {

This is second time iced winit fork breaks again on ios: #1007

When will ice merge it's fork? It has been a long time now and I worry it will diverge forever soon...

[hecrj]

For now, iced does not officially support mobile platforms! #302 (comment)

We are leveraging run_return in order to allow iced applications to return control to the main thread after exiting. See #1112 for further details.

[aentity]

Hmm, this is unfortunate news to me.

So I do not use the iced application, I use integration. For me that is all dead code. It seems a simple cfg on application body can fix this issue; would you accept PR so I can continue to use iced?

If not I must sadly to look elsewhere, because I do enjoy this library very much.

[hecrj]

@aentity I understand. However, I cannot commit to maintain changes that are exclusively related to mobile platforms.

Given that you seem capable of fixing the issues for your particular use cases, maybe you could maintain a fork of your own? That way, you won't need to wait for me to merge the changes and if things break you can fix them right away!

That said, it looks like you may only be using iced_winit for the conversion module. In that case, maybe we could split that functionality in a different crate to keep it separate from any event loop code.

[aentity]

That said, it looks like you may only be using iced_winit for the conversion module. In that case, maybe we could split that functionality in a different crate to keep it separate from any event loop code.

Yes thank you, after examining, I see only this is use for iced_winit in my project:

       if let Some(event) = iced_winit::conversion::window_event(event, scale_factor, modifiers) {
            self.events.push(event);

This is interesting proposal. Do you suggest to have new crate, iced_conversion with single convert function? And then rest of iced which uses event loop be under an application feature, for example? Maybe this is nice solution instead of PR #1190, to update no iOS feature reference, but only application feature reference?

If this is correct understanding, I could help try out this in new PR if you think it OK idea.

In future though, it would be nice to also see iced fork be merged mainline; is there tracking issue to see what remains to see fork be merged? This is worrisome to me for future of iced, as I think it is over 1 year now iced uses winit fork. (and no crates release possible until this is resolved).