
How (Not) to Write an iOS SDK - astigsen
https://realm.io/news/altconf-conrad-kramer-writing-iOS-sdk/
======
gwbas1c
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
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
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.

~~~
michaelvoz
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
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
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.

~~~
pjmlp
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.

~~~
overcyn
NSUnit looks to have an ObjC API?

[https://developer.apple.com/reference/foundation/nsdimension...](https://developer.apple.com/reference/foundation/nsdimension?language=objc)

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

------
djrogers
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
Another interesting possibility is that when you release the library with your
preferred build system and language, people can contribute additional ones :)

------
spdustin
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
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
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

------
a13n
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!!

------
blahshaw
>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
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
> 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>

------
josh_carterPDX
Good information. Thanks for posting this.

------
carlos22
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
Agree. I closed the tab after reading iOS in the headline.

~~~
vmateixeira
Me too.

