7 ms·

Writing your library in Objective-C is silly if you mean to use it from Swift. The languages are incredibly different (value types, powerful protocols, generics

by chris_7 10y ago

Writing your library in Objective-C is silly if you mean to use it from Swift. The languages are incredibly different (value types, powerful protocols, generics vs. just objects and simple C types), so you'll heavily limit yourself by writing in Objective-C. Nullability annotations don't really make up for that. If you're using Swift, don't limit yourself by writing your components in Objective-C.

themartorana 10y ago
I think the point is distributability. For an internal library, use whatever makes sense. If you want to make it available for all iOS developers, write it in ObjC, because many iOS apps are still using ObjC.
lnanek2 10y ago
Maybe he had to deal with C/C++ APIs. He does flat out say the two main modern languages are Swift and Objective-C. I know using OpenCV from iOS is a real nightmare for this reason.
- chris_7 10y ago
  C libraries are fine in Swift, but I feel that dealing with a C++ library (and non-CF/system C libraries) is usually a rare exception when "writing an iOS SDK". Most iOS libraries are just written on top of Foundation and the appropriate platform interface kit (if it's a UI library).
michaelvoz 10y ago
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.
- chris_7 10y ago
  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.
  - michaelvoz 10y ago
    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.
    - chris_7 10y ago
      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?
      - jmgao 10y ago
        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.
        chris_7 10y ago
        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.
    - pjmlp 10y ago
      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.
JamesSwift 10y ago
Using obj-c from swift is easier than using swift from obj-c in my experience. So if your goal is to distribute the project, then doing it in obj-c has real benefits.
dep_b 10y ago
If you use Swift and consume the library in an Objective-C project (which is perfectly possible) you will add the Swift ABI to your project automatically which adds about 10MB to your project. The ABI needs to be added because the ABI isn't stable yet. For mobile apps that's still a big consideration. The other way around is much easier, that's why he proposes Swift wrappers around Objective-C code that allow a Swifty interface with your libraries. But often using generics and nullability will already help a lot.
- chris_7 10y ago
  My presumption is that you're already using Swift in your app when you decide to write/break out a component framework and open-source it. If you're using Objective-C, keep doing that, but then this isn't really a question to begin with.

by chris_7 10y ago

themartorana 10y ago

I think the point is distributability. For an internal library, use whatever makes sense. If you want to make it available for all iOS developers, write it in ObjC, because many iOS apps are still using ObjC.

lnanek2 10y ago

Maybe he had to deal with C/C++ APIs. He does flat out say the two main modern languages are Swift and Objective-C. I know using OpenCV from iOS is a real nightmare for this reason.

chris_7 10y ago
C libraries are fine in Swift, but I feel that dealing with a C++ library (and non-CF/system C libraries) is usually a rare exception when "writing an iOS SDK". Most iOS libraries are just written on top of Foundation and the appropriate platform interface kit (if it's a UI library).

michaelvoz 10y ago

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.

chris_7 10y ago
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.
- michaelvoz 10y ago
  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.
  - chris_7 10y ago
    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?
    - jmgao 10y ago
      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.
      - chris_7 10y ago
        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.
  - pjmlp 10y ago
    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.

JamesSwift 10y ago

Using obj-c from swift is easier than using swift from obj-c in my experience. So if your goal is to distribute the project, then doing it in obj-c has real benefits.

dep_b 10y ago

If you use Swift and consume the library in an Objective-C project (which is perfectly possible) you will add the Swift ABI to your project automatically which adds about 10MB to your project. The ABI needs to be added because the ABI isn't stable yet. For mobile apps that's still a big consideration. The other way around is much easier, that's why he proposes Swift wrappers around Objective-C code that allow a Swifty interface with your libraries. But often using generics and nullability will already help a lot.

chris_7 10y ago
My presumption is that you're already using Swift in your app when you decide to write/break out a component framework and open-source it. If you're using Objective-C, keep doing that, but then this isn't really a question to begin with.