[brantonb]

> For instance, the NSPopover is a good candidate for bubbles that hint at stuff in the Mac app. An iOS counterpart sadly does not exist, so no bubbles in the iOS app.

Ignoring popover presentations in UIKit, there’s also a new TipKit framework in iOS 17, but it’s Swift-only.

https://developer.apple.com/documentation/TipKit

The author has done a great job while remaining in Obj-C. I’m really curious how long they can avoid Swift, keep the native experience, and offer new features in the platforms.

[papereditor]

Thanks! Indeed, there is TipKit. I've just learned about it a few days ago.

I think so far when Apple added new features to existing components, they've always made dual APIs. Only some completely new things are Swift-exclusive.

That said, as the pile of those exclusive things gets bigger, it would be harder and harder to stay in Objective-C.

[jshier]

You know you don't have to choose one or the other, right? The languages interoperate and there's really no overhead to adopting Swift anymore. On newer OSes you're using tons of Swift under the hood anyway.

[papereditor]

I have not investigated it, to be honest. If it's as easy as switching the compiler to Swift, and everything remains working as is, but I also get to use all the Swift stuff in addition to Objective-C, then I am clearly missing out!

[jshier]

They are separate compilers. Obj-C is compiled by clang, Swift by the Swift compiler. You enable bridging in Xcode and then get access to your Obj-C code in Swift through the use of a bridging header, and Swift in Obj-C through the use of the *-Swift.h generated header. You can write classes in Swift that are visible to Obj-C and vice versa. You can't expose everything from Swift to Obj-C since Obj-C is missing most of Swift capabilities, but it's easy to call back and forth.

[papereditor]

OK. I see.

I'll definitely give it a try at some point.

Thanks!

[brantonb]

At my last job, we slowly started adopting Swift in 2016 by writing some unit tests with it. Once we felt comfortable and established some coding conventions, we started adding some production code. By the time I left in fall 2023, we were well over 50% Swift without any big rewrites of Obj-C code. Almost all the new code came in as Swift because developers enjoyed writing it over Obj-C.

Sounds like you rely on Categories a lot. Check out Extensions in Swift. [1]

There are some limitations (e.g., Swift enums lose a lot of their power if they're needed in Obj-C) but overall the interop is great. I don't remember anything in UIKit that couldn't be done with Swift. And if you're dealing with unicode text, doing things in Swift may make your life much easier.

[1] https://docs.swift.org/swift-book/documentation/the-swift-pr...

[KerrAvon]

I'm also puzzled by your statement about popovers; UIKit has supported them for a long, long time.

[papereditor]

NSPopover and the popover presentation style of UIViewController are a bit different things.

I think, technically, you could emulate NSPopover with the latter. I will need to test it.

Feel free to clarify, if I've misunderstood your comment.