7 ms·

How (Not) to Write an iOS SDK

112 points by astigsen 10y ago

josh_carterPDX 10y ago
Good information. Thanks for posting this.
carlos22 10y ago
The HN title lacks the iOS part of the headline - which is quite important because all the information is useless if you are not interested in iOS.
- matheussampaio 10y ago
  Agree. I closed the tab after reading iOS in the headline.
  - vmateixeira 10y ago
    Me too.
- rnovak 10y ago
  I completely disagree, there is a lot of semantically valid information in the talk, like "make file paths configurable". Is that really only applicable to iOS? I think not.
gwbas1c 10y ago
I made it about 1/3rd of the way through this. Supporting all this guy's demands is probably much more time consuming than writing whatever the library originally intended to do. Seems quite unreasonable to me. Perhaps a better way to write this would be describing how iOS's SDKs have too many variations in deployment to make them truly drop-in for everyone else.
- conradev 10y ago
  I definitely laid out what I consider the "gold standard". Most open source projects hit some, but not all of the items on the list, for various reasons – and that's okay. It's certainly time consuming to work on some of these items, and the cost/benefit of each should be evaluated individually. But there are quite a few developers that work on SDKs as a full time job, so hopefully they'll pick up on some of the items in the talk :^) (as for the fragmentation in the iOS ecosystem in general… that's a topic in and of itself)
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.
duke360 10y ago
very informative, this definitively zeroed my interest in macOS family, I know very little about swift and macos but what I've seen here makes me think that your sdk expires automatically at every new version released by apple. i'm wondering why so many people like to develop for these systems... ok I've found the answer: for money.
djrogers 10y ago
There are a lot of demands/needs/wants in this press that really only make sense to me if I'm writing a commercial SDK. If I've written an SDK as a support library for one of my projects and I want to open-source it or release it in any way, it'll include the language and build system support for my project. If anyone else find that helpful, great - that's why I released it. If you 'require' me to add cocoapod support, when I don't use, now, or understand the intricacies of cocoapods, then that' bad for both of us (I probably can't support you properly when it breaks). If the audience for this is really the Dropbox-types, i.e. their products live and die on integrations and SDKs, then this makes more sense...
- conradev 10y ago
  Another interesting possibility is that when you release the library with your preferred build system and language, people can contribute additional ones :)
spdustin 10y ago
Just wanted to say: This is an excellent way to present this talk. The videos and slides synchronized on the screen, the transcript (looks like a slightly edited one, or perhaps the "shooting script", but still...) with links that jump in the video to the correct time. Really, really well done. Nice shirt, too. :)
spdustin 10y ago
One small nit: Apple really doesn't want people using two-letter prefixes for their components. I know that's a pretty sore subject for a lot of iOS devs, but the example WFOAuth2 (where WF is the "Workflow" prefix) would be frowned upon. The Workflow app itself, however, is spectacular, and I use it all the time. I use it to log arbitrary stuff to HealthKit (like when I drink a caffeinated beverage, for example).
- conradev 10y ago
  You are right! I was considering using WFO, but decided to go with WF (which is what we use for Workflow). Great to hear that you enjoy using Workflow :D
blahshaw 10y ago
>As such, it’s critical that you write your SDK in Objective-C so that the people that don’t ship Swift can actually use your SDK. I'm not an iOS developer but aren't Swift and Objective C files interchangeable?
- mayoff 10y ago
  Almost all Objective-C APIs can be accessed from Swift. (The one exception I know of is that a type which is a class with protocol conformances, e.g. `UIViewController<UIPickerViewDataSource>`, cannot be represented exactly in Swift. You can still use APIs with such a type, but the type will be different in Swift.) So if you implement your API in Objective-C, you're guaranteed that it's usable in Swift (though perhaps not idiomatically). There are multiple Swift constructs that cannot be exposed to Objective-C, such as enums with associated values, structs, and global variables and functions. So if you implement your API in Swift, you have to be careful if you want it to be usable from Objective-C. Another problem with writing your API in Swift is that the Swift ABI isn't stable yet. It changes between compiler versions. This means that your API (if written in Swift) must be compiled with the same Swift compiler as the user's code. If you want to distribute your API as a binary-only library, you'll have to release a new version every time Apple releases a new version of Xcode, and your user will have to be sure to get the correct version of your library for their version of Xcode.
  - chris_7 10y ago
    > The one exception I know of is that a type which is a class with protocol conformances, e.g. `UIViewController<UIPickerViewDataSource>`, cannot be represented exactly in Swift Sort of doable with generics, but only from Swift code: <ViewController: UIViewController where ViewController: UIPickerViewDataSource>
a13n 10y ago
Seriously, thank you for writing this. I just started writing an iOS SDK days ago and had already made the mistake of starting off with Swift rather than Obj-C. Luckily I've only written 250 lines of code, you saved me hours of technical debt!!

112 points by astigsen 10y ago

Good information. Thanks for posting this.

The HN title lacks the iOS part of the headline - which is quite important because all the information is useless if you are not interested in iOS.

matheussampaio 10y ago
Agree. I closed the tab after reading iOS in the headline.
- vmateixeira 10y ago
  Me too.
rnovak 10y ago
I completely disagree, there is a lot of semantically valid information in the talk, like "make file paths configurable". Is that really only applicable to iOS? I think not.

gwbas1c 10y ago

I made it about 1/3rd of the way through this. Supporting all this guy's demands is probably much more time consuming than writing whatever the library originally intended to do. Seems quite unreasonable to me. Perhaps a better way to write this would be describing how iOS's SDKs have too many variations in deployment to make them truly drop-in for everyone else.

conradev 10y ago
I definitely laid out what I consider the "gold standard". Most open source projects hit some, but not all of the items on the list, for various reasons – and that's okay. It's certainly time consuming to work on some of these items, and the cost/benefit of each should be evaluated individually. But there are quite a few developers that work on SDKs as a full time job, so hopefully they'll pick up on some of the items in the talk :^) (as for the fragmentation in the iOS ecosystem in general… that's a topic in and of itself)

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.

duke360 10y ago

very informative, this definitively zeroed my interest in macOS family, I know very little about swift and macos but what I've seen here makes me think that your sdk expires automatically at every new version released by apple. i'm wondering why so many people like to develop for these systems... ok I've found the answer: for money.

djrogers 10y ago

There are a lot of demands/needs/wants in this press that really only make sense to me if I'm writing a commercial SDK. If I've written an SDK as a support library for one of my projects and I want to open-source it or release it in any way, it'll include the language and build system support for my project. If anyone else find that helpful, great - that's why I released it. If you 'require' me to add cocoapod support, when I don't use, now, or understand the intricacies of cocoapods, then that' bad for both of us (I probably can't support you properly when it breaks). If the audience for this is really the Dropbox-types, i.e. their products live and die on integrations and SDKs, then this makes more sense...

conradev 10y ago
Another interesting possibility is that when you release the library with your preferred build system and language, people can contribute additional ones :)

spdustin 10y ago

Just wanted to say: This is an excellent way to present this talk. The videos and slides synchronized on the screen, the transcript (looks like a slightly edited one, or perhaps the "shooting script", but still...) with links that jump in the video to the correct time. Really, really well done. Nice shirt, too. :)

spdustin 10y ago

One small nit: Apple really doesn't want people using two-letter prefixes for their components. I know that's a pretty sore subject for a lot of iOS devs, but the example WFOAuth2 (where WF is the "Workflow" prefix) would be frowned upon. The Workflow app itself, however, is spectacular, and I use it all the time. I use it to log arbitrary stuff to HealthKit (like when I drink a caffeinated beverage, for example).

conradev 10y ago
You are right! I was considering using WFO, but decided to go with WF (which is what we use for Workflow). Great to hear that you enjoy using Workflow :D

blahshaw 10y ago

>As such, it’s critical that you write your SDK in Objective-C so that the people that don’t ship Swift can actually use your SDK. I'm not an iOS developer but aren't Swift and Objective C files interchangeable?

mayoff 10y ago
Almost all Objective-C APIs can be accessed from Swift. (The one exception I know of is that a type which is a class with protocol conformances, e.g. `UIViewController<UIPickerViewDataSource>`, cannot be represented exactly in Swift. You can still use APIs with such a type, but the type will be different in Swift.) So if you implement your API in Objective-C, you're guaranteed that it's usable in Swift (though perhaps not idiomatically). There are multiple Swift constructs that cannot be exposed to Objective-C, such as enums with associated values, structs, and global variables and functions. So if you implement your API in Swift, you have to be careful if you want it to be usable from Objective-C. Another problem with writing your API in Swift is that the Swift ABI isn't stable yet. It changes between compiler versions. This means that your API (if written in Swift) must be compiled with the same Swift compiler as the user's code. If you want to distribute your API as a binary-only library, you'll have to release a new version every time Apple releases a new version of Xcode, and your user will have to be sure to get the correct version of your library for their version of Xcode.
- chris_7 10y ago
  > The one exception I know of is that a type which is a class with protocol conformances, e.g. `UIViewController<UIPickerViewDataSource>`, cannot be represented exactly in Swift Sort of doable with generics, but only from Swift code: <ViewController: UIViewController where ViewController: UIPickerViewDataSource>

a13n 10y ago

Seriously, thank you for writing this. I just started writing an iOS SDK days ago and had already made the mistake of starting off with Swift rather than Obj-C. Luckily I've only written 250 lines of code, you saved me hours of technical debt!!