How (not) to write an iOS SDK

I'll be picking apart what makes an SDK great to work with, and conversely, illustrating some common pitfalls that SDK developers fall into. Everything from the language an SDK is written in, to the build system it uses, to the platforms it supports (hint: all of them) and more. I'll also go over some ways to go that extra mile when building an SDK.

Transcript

1. How (not) to write an iOS SDK Conrad Kramer
2. We consume a lot of SDKs in Workflow We also have to roll our own SDKs for Workflow
3. Don't make assumptions
4. Language
5. Write in Objective-C Use nullability and generics Don't expose C++
6. Write a Swift wrapper All versions of Swift
7. Build System
8. Have an Xcode project Dynamic and static libraries Support Carthage
9. Have a podspec
10. Support Swift Package Manager Package.swift
11. Environment
12. Make file paths configurable App groups are a thing Have reasonable defaults
13. Don't rely on UIApplication If you must, mark APIs with NS_EXTENSION_UNAVAILABLE If you need background time, use NSProcessInfo
14. Handle inter-process coordination This is hard
15. WFNotificationCenter
16. Support all platforms watchOS, tvOS iOS, macOS carOS
17. Deployment Target
18. Dependencies Avoid them
19. Document your API High level overview Method specific documentation
20. Tests Merge with confidence
21. Performance Document expensive API calls Use Grand Central Dispatch queues
22. Performance Monitor memory utilization +load, objc_copyClassList, UIWebView, CGBitmapContext!
23. WFOAuth2 github.com/DeskConnect/WFOAuth2 swift build carthage build pod install
24. Conrad Kramer Workflow @conradev conra.dk