Skip to content

Developer Expectations for 3rd Party SDKs/Libraries/Frameworks

November 18, 2012

I recently joined Apigee ( to become an SDK Engineer, and I thought that it would be a good idea to gather up and document my expectations of all 3rd party SDK/Library/Frameworks (in general) before I set out working with Apigee’s mobile SDKs. This is to serve as my own objective baseline for how things should and should not be done.

(1) Keep the runtime footprint lightweight (minimal overhead for memory, CPU, network, battery usage, etc.)
(2) Keep the distribution footprint lightweight (should not double or triple size of app)
(3) Make the API clear, concise, and predictable
(4) Ensure that your SDK/Library/Framework is well-documented (API reference, developer guides, sample code, tutorials, etc.); developer docs should be devoid of hyperbole and marketing terminology
(5) Require minimal changes to IDE project
(6) Require minimal changes to existing source code
(7) Keep 3rd party library/framework dependencies minimal
(8) Make sure that your product is stable and predictable
(9) Don’t force me to target really old or really new versions of a platform; ideally, support them all (within reason)
(10) Don’t add noticeable time to my startup time
(11) Fail gracefully (don’t take down my product/service just because your SDK/Library/Framework ran into a problem)
(12) Make it easy to troubleshoot
(13) Be very clear about the things that your SDK/Library/Framework does and doesn’t do
(14) Do not violate any terms of service for platform, app store, etc. (nor any laws!)
(15) Do not violate user’s privacy; if you collect anything about my users, be very clear about what’s being collected and why
(16) Stay out of my way and out of my sight unless you really have something valuable to add to my efforts
(17) I may be excited, ambivalent, offended, or angry at your license; don’t make me change my product/service license
(18) Don’t make it difficult for me to report bugs or enhancement requests (e.g., Apple’s Radar)
(19) Never give cryptic error messages (i.e., “System Error: -537″)
(20) Don’t show my users any UI messages, unless: (a) it makes sense, and (b) you provide me a way to customize the message
(21) Don’t use black t-shirt/133t h4x0r speak with me or my users (my users probably won’t get it, and it’ll just annoy them)
(22) Don’t introduce proprietary or weird technologies (use standard and/or built-in technologies where possible)
(23) Don’t make me jump through hoops to build or install my prodcut/service as a result of your SDK/Library/Framework
(24) Don’t introduce any new security vulnerabilities to my product/service (exploits, DOS attacks, MITM attacks, etc.)
(25) Don’t make it any easier for others to learn about any proprietary technologies that may already be baked into my product/service
(26) Never force me to release an update of my product/service because of some problem in your SDK/Library/Framework
(27) Let me try before I buy
(28) Don’t make me or my end users look at 80 pages of EULA
(29) Never make me or my product/service look bad
(30) Don’t be incompatible with other SDK/Library/Frameworks that I may be likely to use
(31) Don’t force me to buy specific types of servers and server software (I like choices)
(32) Don’t force me to use XML, JSON, or any other formats that I might not be using
(33) Don’t make me have to manually edit XML configuration files, ever
(34) Have sane and reasonable default settings
(35) For server side stuff, give me UI, command-line access (where sensible), and an API
(36) I like flexibility and simplicity — keep simple things simple, but allow me to do obtuse things if I have to
(37) Don’t spam me or my users
(38) Ensure that your SDK/Library/Framework is thoroughly tested before you ask me to try it; ideally, include your test cases
(39) If you support multiple platforms or operating systems, be consistent with your terminology where it makes sense to do so
(40) Don’t try any ‘bait-and-switch’ tactics — I keep my eyes peeled for them
(41) Support multiple languages and platforms if it makes sense; I might want (or need) to use your SDK/Library/Framework across multiple platforms and/or languages
(42) Strive for a balance between brevity and verbosity; sbrk is too terse, and delegateTitleForDeleteConfirmationButtonForRowAtIndexPath is too verbose

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: