I think this should be part of eframe, i.e. so you can call eframe::safe_area_top(ctx) to get how many ui points from the top it is safe to put widgets.

@emilk so, I move the safe area insets function to eframe, but what about the safe area widget. I think it would be better to use something like this instead of a widget:

fn safe_area<R>(ui: &mut Ui, inner: impl FnOnce(&mut Ui) -> R) -> R {
    let insets = get_ios_safe_area_insets();
    if let Some(insets) = insets {
        let cursor = ui.cursor().min;
        /*
        let x = insets.left - cursor.x as f64;
        if x > 0. {
            let (id, rect) = ui.allocate_space(vec2(x as f32, ui.available_height()));
            ui.interact(rect, id, Sense::hover());
        }
        */
        let y = insets.top - cursor.y as f64;
        if y > 0. {
            let (id, rect) = ui.allocate_space(vec2(ui.available_width(), y as f32));
            ui.interact(rect, id, Sense::hover());
        }
        let max_height = ui.available_height() - insets.bottom as f32;
        if max_height > 0.0 {
            ui.set_max_height(max_height);
        }
        let max_width = ui.available_width() - insets.right as f32;
        if max_width > 0.0 {
            ui.set_max_width(max_width);
        }
    }
    inner(ui)
}

where should I put it? should this be part of egui/egui_extras. should this & the safe area insets function be hidden behind a feature or should it be enabled for every iOS build? its kinda essential and probably needed in every iOS build anyway. And this example above will not work when the inset is != 0 on the left. do you have any ideas how I could get this to work properly?

Something like this would be great ui.within(rect, |ui| {});

One approach would be to modify FrameState::available_rect so that is is the safe area. That would mean egui::CentralPanel (and other panels) would start within that smaller rect. However, one should still paint some sort of background color outside that.

Seems like winit will soon have a safe area api: rust-windowing/winit#3890
Maybe we can use that one instead? Then other platforms will also be supported once support is added to winit (rust-windowing/winit#3910)

Preview available at https://egui-pr-preview.github.io/pr/4915-iOS-safe-area-widget
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

Im not quite sure when which events fires in winit. I guessed. theoretically WindowEvent::Resized(_) & ScaleFactorChanged should be enough, but im not sure if the events fire when the app is minimized or repopend in split screen or if the device was flipped while the screen was of so included Focused(true) & Occluded(false).

Im not quite sure when the safe area gets merged into winit as it had no updates the last 3 weeks. Migrating from my implementation to the winit implementation should be quite easy anyway(self.egui_input_mut().safe_area = Some(egui::SafeArea::from(safe_area::get_ios_safe_area_insets())); would need to be changed to self.egui_input_mut().safe_area = Some(egui::SafeArea::from(window.get_safe_area()))

The winit PR was approved and is added to the 0.31 milestone so I think it makes sense to just wait for that and then update your PR with the winit implementation

@emilk the code was merged so once the version bump is in crates.io & this project is updated, this can be merged without change

Cool, Can this be merged now?

Sorry, I didn't expect the winit 0.31 release to take so long. I'm fine with merging the objc approach. Will look into it next week.

I've merged master and reverted the commit relying on winit's safe area implementation, and tested it with my egui ios demo, works well!

Only thing I noticed is that windows and popups can extend past the safe area, which I don't think it should. It could mean e.g. a combobox popup is partially hidden behind the bottom bar thingy.

It'd also be nice if the keyboard opening would affect the safe area so that the ui could adjust accordingly.

Works really well now!

I've updated the way safe area is handled, it now maches screen_rect in that it's only updated if it's Some. Also I made the InputState::screen_rect field private and added a getter fn that respects the safe area and added screen_rect_including_unsafe_area which returns the unmodified screen rect. Not sure on the naming but I couldn't come up with something nicer.

@lucasmerlin I've gone ahead and tried to address the open points of feedback on a branch here: https://github.com/irh/egui/tree/ios-safe-area.

It would be great if we could get this landed, should I open a new PR or would you prefer to pull my changes into this one?

@irh Nice! You should create a new one, I don't think you can update this one

@irh Nice! You should create a new one, I don't think you can update this one

@lucasmerlin Ok great, new PR here: #7578.