5 ms·
> 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 i
by brantonb 3y ago
> 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 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 3y agoThanks! 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 3y agoYou 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 3y agoI 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!
- brantonb 3y agoAt 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-programming-language/extensions/ https://docs.swift.org/swift-book/documentation/the-swift-pr...
- jshier 3y agoThey 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 3y agoOK. I see. I'll definitely give it a try at some point. Thanks!
- KerrAvon 3y agoI'm also puzzled by your statement about popovers; UIKit has supported them for a long, long time.
- papereditor 3y agoNSPopover 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.
- deleted 3y ago[deleted]