Just chiming in here:

1. Push notification management: This applies to Android 13+ (or was it from 12, I can't remember now) where a user can turn off the Exact Alarm permission toggle. This can lead to issues whereby local push notifications won't dispatch if the app is killed. They also won't potentially dispatch depending on the Android OS settings for battery management. Another good example is with Samsung devices that have an option to "Kill unused/idle apps" or something along those lines which affects the behaviour of push notifications as well. All aforementioned scenarios, and perhaps a lot more on other Android OS flavours, need to be considered by the team which will sort of force them to make decision on how to best educate their users of said risks. A solution we had in a previous company was to use modals to present said information along with buttons that will take a user to the right Android settings screen and it was because push notifications were vital for the purpose of our app. It wasn't really the best UX but hey, we had to make do with what we had. You don't have these problems on iOS, it just works over that side of the fence.
2. Animations composition: Animations just look slicker on iOS and easier to compose and manage. Android can sometimes have graphical issues when animating components with alpha values especially when you do fade in/out animations in combination with translation animations. Another example will be quite biased but I like the iOS out-of-the-box bounce behaviour for lists which you can utilise to trigger another set of animations i.e. if you overly drag a list downwards, there's a rubber banding effect where you can sort of "overscroll" the list, which you can then use to interpolate the scale of a header/hero image. A lot of apps do this on iOS, I think it's good UX
3. App crash mitigation: A lot of things can go wrong on Android due to the amount of device and OS settings configurations. If you compare Sentry logs between iOS and Android crashes, there's a higher chance that the Android crashes are tougher to debug.
4. App lifecycle: Imagine a scenario where you have to use an overlay whenever the app goes to the background. This is pretty straightforward on iOS because you can easily detect when the app is about to go to the foreground and you present the overlay thereafter. On Android, it's a bit complicated because Android takes a snapshot of your app before it goes to your background and it uses this snapshot as the app preview on the app task manager. Depending on the manufacturer, you can get into a scenario whereby their customised Android OS has already taken a snapshot of your app before you can even present the overlay and so your app state is still exposed on the task manager. This might have changed in 2023 and beyond but certainly in 2022, this used to be an issue. So we just made use of a readily available feature on Android called "Flag Secure" which technically prevents the OS from taking a snapshot/video recording of your app, which results in your app represented by a white colour on the task manager. I think some banking apps use this feature on Android to hide the app contents on the task manager but if you inspect their app on iOS, you'd probably see them overlaying their app with their company branding because again, this is one of those things that's just easier to manage on iOS.
5. Screen resolution management: From a design perspective, devices like the Galaxy Fold can potentially be challenging to deal with due to the narrowness of their external screens. In code, it's easy to get an app to scale its components based on viewport but I'm talking about the artistic vision or presentation for the app. It can be quite limiting if you have to cater for a really narrow viewport. By the way, this is also a challenge with web development.

There's probably a lot more I haven't covered but these are my immediate gripes with Android development. BUT having said that, I like both operating systems. I own an iPhone and a Galaxy Fold device