Allow the user to register the application delegate on macOS and iOS by madsmtm · Pull Request #3758 · rust-windowing/winit

madsmtm · 2024-06-24T13:09:20Z

Register for event-loop lifecycle events using the NSNotification API instead of application delegates. This gives the user full control over the application delegate, which opens several doors for customization that were previously closed.

In particular, this fixes #1751, closes #3713, fixes #2674, fixes #3499, fixes #3650 and fixes #2141, all by allowing the user to override NSApplicationDelegate/UIApplicationDelegate themselves outside Winit.

Also fixes #1281 by listening on notifications instead of using the application delegate.

Resolves part of the macOS side of #2120.

Tested on all platforms changed
- macOS
- iOS
Added an entry to the changelog module if knowledge of this change could be valuable to users
Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior

daxpedda

I'm starting to understand the MacOS backend quite a bit now, the cleanup you have done so far is pretty amazing.

kchibisov

I'm not that familiar with observers, but it looks ok-ish? I know that it works by appkit basically signalling you when something happens and you can register a lot of observers.

Also does it affect performance/input latency in any aspect or it's all the same because macOS is just giant message passing infra already and dispatching observer is not slower than dispatching regular methods?

kchibisov · 2024-06-29T15:28:51Z

src/platform_impl/apple/appkit/app_state.rs

-);
+// TODO(madsmtm): Use `MainThreadBound` once that is possible in `static`s.
+thread_local! {
+    static GLOBAL: OnceCell<Rc<AppState>> = const { OnceCell::new() };


What's the reason to Rc thread local global? I'd assume the main reason is that the user creates it in Rc and shares the pointer with winit, thus it's correctly ref-counted.

And you're using global here just for simplicity?

Rc

I haven't really decided how I want to pass the state around yet, so I just went with something that worked, and matched the semantics of what we were doing before (Retained<ApplicationDelegate> is basically the same as Rc<AppState>).

thread local

That was to avoid a bit of unsafe until I've released a version of objc2-foundation with a const MainThreadBound::new. But I've worked around it with a helper for now instead.

global

I think that the only piece of state that has to actually be global (in Winit) is the ApplicationHandler, since we have to access that from our overwritten WinitApplication when (hackily) dispatching device events. But if I find a different way to implement that, then I might be able to remove this final piece of global state in Winit's AppKit backend.

madsmtm · 2024-07-14T14:39:31Z

Also does it affect performance/input latency in any aspect

I looked into it:

On AppKit, when calling -[NSApplication setDelegate:], most of the delegate's NSApplicationDelegate methods (at least the ones we use) are internally registered as observer methods for the notifications we use here. So the performance impact of this PR is basically zero.

On UIKit, the delegate method is called directly, while the notification is emitted immediately afterwards. I'd suspect the performance impact of this PR to be very minimal, as UIKit still creates the NSNotification object even when there are no observers for it, but I haven't measured it.

In any case, you don't need to be concerned with buffering of notifications or other such shenanigans, the notifications are emitted at (basically) the same time as the methods are called.

Korne127 · 2024-07-20T23:16:19Z

@kchibisov Just to make sure you didn't miss it

kchibisov · 2024-07-21T08:02:46Z

@Korne127 miss what? I approved the PR long time ago...

Korne127 · 2024-07-21T11:49:20Z

Sorry if I'm wrong, to me it just looked like you were expected to give feedback to the new changes / address Mads' answer to your question.

kchibisov · 2024-07-21T11:55:43Z

I've asked for feedback just to confirm my assumption, otherwise I'd request changes.

nicoburns · 2024-07-29T01:18:31Z

This looks absolutely fantastic. This would solve a lot of the problems I've had with Winit on MacOS. Giving the application control of the AppDelegate is excellent on it's own. But I'm particular excited that this approach seems to open up the possibility of modular libraries that independently hook into apple system events!

This is a breaking change, although unlikely to matter in practice, since the return value of `application:didFinishLaunchingWithOptions:` is seldom used by the system.

This allows the user to override the application delegate themselves, which opens several doors for customization that were previously closed.

madsmtm · 2024-08-11T21:09:49Z

The holdup for this PR has not been Kirill at all, it's because I was on vacation ;)

Korne127 · 2024-08-11T23:22:38Z

Woohoo! Awesome :D
Thanks for all your work on this, and I hope you had a great vacation! :)

iOS parts of rust-windowing#3758. This allows the user to override the application delegate themselves, which opens several doors for customization that were previously closed. To do this, we use notifications instead of a top-level application delegate. One effect of not providing an application delegate on iOS is that we no longer act as-if the application successfully open all URLs there. This is a breaking change, although unlikely to matter in practice, since the return value of `application:didFinishLaunchingWithOptions:` is seldom used by the system (and this is likely the preferred behaviour anyhow).

madsmtm · 2025-04-29T11:26:52Z

I backported the iOS parts of this to v0.30.10, the macOS parts are more extensive, and will have to wait until v0.31.0.

CC @extrawurst, this should allow what we talked about on Discord with v0.30.10.

iOS parts of rust-windowing#3758. This allows the user to override the application delegate themselves, which opens several doors for customization that were previously closed. To do this, we use notifications instead of a top-level application delegate. One effect of not providing an application delegate on iOS is that we no longer act as-if the application successfully open all URLs there. This is a breaking change, although unlikely to matter in practice, since the return value of `application:didFinishLaunchingWithOptions:` is seldom used by the system (and this is likely the preferred behaviour anyhow).

iOS parts of #3758. This allows the user to override the application delegate themselves, which opens several doors for customization that were previously closed. To do this, we use notifications instead of a top-level application delegate. One effect of not providing an application delegate on iOS is that we no longer act as-if the application successfully open all URLs there. This is a breaking change, although unlikely to matter in practice, since the return value of `application:didFinishLaunchingWithOptions:` is seldom used by the system (and this is likely the preferred behaviour anyhow).

pomali · 2025-05-13T13:48:54Z

I backported the iOS parts of this to v0.30.10, the macOS parts are more extensive, and will have to wait until v0.31.0.

Is there any way I can help with macOS parts?

madsmtm · 2025-05-13T22:16:01Z

Problem is that it depends on a bunch of other refactoring PRs I've done, and backporting those (correctly) is kind of a nightmare.

I know how useful this feature would be to downstream projects, but I can't really justify that time usage, I think my time's better spent getting v0.31 out the door.

Though I'd probably accept a PR that cherry-picked the required stuff against the v0.30.x branch, if you want to do it?

madsmtm added S - enhancement Wouldn't this be the coolest? DS - appkit Affects the AppKit/macOS backend S - docs Awareness, docs, examples, etc. DS - uikit Affects the UIKit backend (iOS, tvOS, watchOS, visionOS) labels Jun 24, 2024

madsmtm force-pushed the madsmtm/remove-app-delegates branch from ae4da6c to 33670a2 Compare June 24, 2024 13:26

madsmtm mentioned this pull request Jun 24, 2024

macOS/iOS: Various refactorings in application state #3720

Merged

1 task

madsmtm force-pushed the madsmtm/remove-app-delegates branch from 33670a2 to 5b45632 Compare June 24, 2024 13:31

madsmtm requested a review from kchibisov June 24, 2024 13:31

madsmtm force-pushed the madsmtm/remove-app-delegates branch 5 times, most recently from 39b651e to 4a53350 Compare June 24, 2024 21:53

madsmtm added this to the Version 0.31.0 milestone Jun 24, 2024

daxpedda approved these changes Jun 28, 2024

View reviewed changes

kchibisov approved these changes Jun 29, 2024

View reviewed changes

madsmtm added 3 commits August 11, 2024 22:39

Use notifications instead of top-level application delegate methods

85122fa

Don't act as-if the application successfully open all URLs

4f2b932

This is a breaking change, although unlikely to matter in practice, since the return value of `application:didFinishLaunchingWithOptions:` is seldom used by the system.

Don't register an application delegate

1030703

This allows the user to override the application delegate themselves, which opens several doors for customization that were previously closed.

Use a normal static and some unsafe instead of a thread local

53f7c34

madsmtm force-pushed the madsmtm/remove-app-delegates branch from 7e17899 to 53f7c34 Compare August 11, 2024 20:40

madsmtm added 5 commits August 11, 2024 22:50

Tweak comment

3e4208c

Fix MSRV

ad269bf

Remove unnecessary braces

9148b60

Fix comment grammar

995c58d

Merge branch 'master' into madsmtm/remove-app-delegates

e1679a7

madsmtm merged commit 92e9bfe into master Aug 11, 2024

madsmtm deleted the madsmtm/remove-app-delegates branch August 11, 2024 21:14

This was referenced Aug 11, 2024

Handle URLs on macOS #3825

Closed

Feature request: Custom URI handling #2190

Closed

maxammann mentioned this pull request Aug 13, 2024

Render to views on Android/iOS maplibre/maplibre-rs#28

Open

ardocrat mentioned this pull request Sep 13, 2024

Open files with the app on MacOSX GetGrin/grim#12

Closed

madsmtm mentioned this pull request Apr 29, 2025

Winit version 0.30.10 #4206

Merged

madsmtm mentioned this pull request Jun 5, 2025

add app delegates for macOS #4262

Closed

4 tasks

madsmtm mentioned this pull request Sep 4, 2025

Cant embed winit as a dylib into cocoa due to NSApp delegate limitations in winit > 0.29 #4322

Closed

SuchAFuriousDeath mentioned this pull request Jan 2, 2026

macOS: Documentation claims winit won't register application delegate, but it does (and panics if replaced) #4458

Open

0HyperCube mentioned this pull request Jan 5, 2026

Mac: support opening files through the native openFile API GraphiteEditor/Graphite#3575

Open

SuchAFuriousDeath mentioned this pull request Feb 24, 2026

winit-x11: fix debug mode overflow panic in set_timestamp #4492

Merged

4 tasks

Conversation

madsmtm commented Jun 24, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

daxpedda left a comment

Choose a reason for hiding this comment

Uh oh!

kchibisov left a comment

Choose a reason for hiding this comment

Uh oh!

kchibisov Jun 29, 2024

Choose a reason for hiding this comment

Uh oh!

madsmtm Jul 14, 2024

Choose a reason for hiding this comment

Uh oh!

madsmtm commented Jul 14, 2024

Uh oh!

Korne127 commented Jul 20, 2024

Uh oh!

kchibisov commented Jul 21, 2024

Uh oh!

Korne127 commented Jul 21, 2024

Uh oh!

kchibisov commented Jul 21, 2024

Uh oh!

nicoburns commented Jul 29, 2024

Uh oh!

madsmtm commented Aug 11, 2024

Uh oh!

Korne127 commented Aug 11, 2024

Uh oh!

madsmtm commented Apr 29, 2025

Uh oh!

pomali commented May 13, 2025

Uh oh!

madsmtm commented May 13, 2025

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

6 participants

madsmtm commented Jun 24, 2024 •

edited

Loading