The downside is whenever you want to do something quite standard in UIKit that doesn't exist yet in SiwftUI. The "carousel" that we have at the start of the app is a UIPageViewController in UIKit, but we had to re-implement it ourselves in SwiftUI.
Also there are weird bugs and crashes. A lot. I think in the end, the productivity gain from SiwftUI evens out to the same productivity as UIKit due to the time spend on those bugs/limitations.
We also planned to build widgets very soon, and having the same code base (they are SwiftUI only) is definitely going to be a plus.
Also right when we started (in Feb), we had to implement Apple Sign-in, and the UX around it for React native or Hybrid framework was absolutely terrible.
In the end, I still think it was a good choice: while we compromise and make people wait a bit more for Android, it gave our (small) team a lot more focus. We learn and make mistakes on one platform, iterate faster on it, and once we feel comfortable with what we've done on iOS, we'll roll it out to Android (which we plan to do in Jan/Feb next year).
That’s already quite hard to do with a 2 people tech-team, so adding on top of that limitations from cross-platform frameworks would have been shooting ourselves in the foot.