Hacker News Reader

Comment by michaelvoz | Hacker News Reader

You miss his point. It is much easier to consume Objective-C API from Swift then consuming swift API from Objective-C. Even more so if you need the library integrated at a C++ layer of your app.

View on HN

I didn't miss his point. I disagree with it. Using Objective-C sacrifices so much that is great about using Swift, and the continually-shrinking Objective-C-only developer market doesn't make up for the loss of all of the Swiftyness.

C++ layers are rare for framework authors, so I don't think that the idea of them should be used to dissuade people from writing Swift frameworks. Obviously, if you need to integrate with C++, use a language that can.

There is still a massive, massive amount of enterprise software (see: everything at Apple) that has millions of lines of code in Objective-C. That code will never be rewritten. If you have millions of dollars riding on a framework/app in Objective-C the business needs outweigh any perceived language niceties you get in swift.

This aside - I also disagree with you, Swift is a worse language in a lot of ways, not to mention the extreme compile times and purely unfinished concepts, as well as bugs related to seemingly foundational things like auto-created initializers for structs not getting picked up properly by sourcekit.

If you already have millions of lines of code, "how to write a framework" is not very relevant in your case. You've already written one, obviously you won't rewrite it. The subject is new frameworks, if you're already using Swift in your app (and thus have paid the bundled frameworks price), why limit yourself to Objective-C because some other developers aren't using it yet?

Because the entire point of writing a framework is for other people to use it, which is a pretty strong pull towards the lowest common denominator.

I don't necessarily agree with that - many people/companies build frameworks for primary use in their own work that they open-source as a courtesy - with benefits of course, more eyes make shallow bugs, advertising, etc.

e.g. Github employees probably (originally) wrote ReactiveCocoa and Carthage because they were useful for developing Github apps, not necessarily to gift fantastic tools to the iOS world.

The macOS Dock and services handling infrastructure has already been rewritten in Swift.

More macOS components will be slowly rewritten in future OS versions.

Likewise some new Sierra APIs like Units are Swift only.

See this year's WWDC talk about Swift 3.0.

NSUnit looks to have an ObjC API?

https://developer.apple.com/reference/foundation/nsdimension...

I wasn't aware of it, thanks for pointing it out.

My point is that you don't sacrifice any of the awesomeness of Swift to the consumer of the SDK if you write a great Swift wrapper around your code.

Your code won't be as fast if your Swift types are copy-on-write wrappers around NSObject subclasses, instead of pure-Swift types.

I agree that you'll get the most coverage of potential developers by supporting both languages, but you're already doing the world a service by releasing open-source software. I don't think putting additional demands on maintainers (you must support CocoaPods, you must support Objective-C) is a reasonable request. If a consumer of the framework wants those features, they can submit a pull request (or just maintain the Podspec independently, as is done with ReactiveCocoa).

Performance is the least compelling reason IMO because if it's slow, you should optimize the slow bits. Otherwise it won't even register as a percentage of total time; looking at it this way is just arguing for premature optimization.

Reply on news.ycombinator.com