I recently was tasked with changing the deployment target of an iOS app from 5.0 to 4.3. What follows are the trials and tribulations of that exercise.
NSJSONSerialization
This JSON parser was introduced in iOS 5.0, so it cannot be used in iOS 4.3. I opted to use the tried-and-true SBJSON. Since Objective-C doesn’t have the concept of namespaces (shameful!) and the biggest part of this app is a framework that we make available for others to use, we follow the standard technique of adding our own prefix to all of the SBJSON types to prevent linker collisions.
‘weak’ Properties
If you code your Objective-C like all the cool kids, you’re undoubtedly familiar with ’strong’ and ‘weak’ identifiers to use as part of a property’s declaration. Although ARC is supported in iOS 4.3, weak references are not supported in iOS versions below 5.0. All weak attributes must be changed to ‘__unsafe_unretained’ instead. Alternatively, you could also change it to ‘assign’ since that’s how we handled unofficial weak references before ARC came along!
iOS Simulator testing with Xcode
My development work was done using the latest Xcode. Unfortunately, the latest Xcode doesn’t have support for iOS 4.3 simulator. (Apple, you irritate me from time to time as a developer) No problem I thought, I’ll just look up the last version of Xcode that is known to support iOS 4.3 simulator and I’ll download that older version of Xcode to do my simulator testing. I downloaded the old Xcode and then attempted to install it (back when Xcode still had to be installed). My laptop is running Mountain Lion and when the installer started up it gave me a message saying that Xcode could not be installed on this newer version of OSX and that I had to use Lion. (Apple, you need to hear that old ‘Developers! Developers! Developers!’ mantra)
I checked with my colleagues and fortunately one of them has a laptop with Lion — great! I install the older Xcode on Lion and get all my development files installed on it. Now I can test the app in iOS 4.3 simulator.
iOS 4.3 Device Testing
Fortunately, iOS simulators are very good, if not excellent. However, at some point testing needs to be done on a real device to ‘know’ that it really works as intended. My personal phone (iPhone 4S) is running iOS 6.1.1, my company testing iPhone 5 is running 6.1, my company testing iPhone 4S is running 5.1.1, and my company testing iPad is running 6.0. Oh, and my old iPhone 3GS is running iOS 6.1.3. (Btw Apple, iOS 6.1.3 is horrible with the battery usage on my 3GS)
As you’re probably aware, Apple likes to keep iOS, and even OSX to some extent, on a 1-way direction with regards to upgrades/downgrades. Sorry, did I say ‘downgrade’? That word does not exist in the iOS dictionary! I discussed the situation with my boss and he starts looking to find a 3GS running iOS 4.3.
After a day or two, my boss tells me that he’s found an iPhone 3GS on Craigslist that’s running iOS 4.3. Great! The guy with the device comes over to our office and the device’s battery is completely drained. (Figures, I thought to myself — it’s Craigslist. Hopefully, the guy doesn’t try to knife us.) I plug it into one of my iPad chargers to get things moving along more speedily. After having to reassure (a couple of times) boss and dude who owns device that the battery charge must reach a minimal level before the device will actually turn on, the device finally reached the minimum charge level needed to start the device.
The device from Craigslist boots up and I frantically go through Settings->General->About to find out which version of iOS this thing is running. (Dang this screen looks fuzzy!) Yep, it’s running iOS 4.3. Tell boss and dude that it’s got the version we’re looking for. Boss pays dude $102.00, or similar amount, and dude goes away with some proud new cash. (Thankfully, he didn’t try to knife us.)
I wasted no time getting the app installed on this device to do some ‘real’ testing. My app does not work as expected on the device. (See, I told you that you can’t always rely on the simulator!) Then I notice that some of the built-in software doesn’t seem to work as expected either. Oh-oh, I notice some strange icon on the home screen. Dang it — this device is jailbroken. Oh well, I’ll just restore the non-jailbroken version of iOS 4.3 and things will be fine.
So, I spend a little time finding (Apple, I think you really are the new Microsoft) the stock restore file (ipsw) for iOS 4.3 running on this device type. Then I download it. Then I fire up the Organizer window in Xcode to get the ipsw file restored to the ‘new-to-us’ iPhone 3GS. Xcode gives me a delightful “This device isn’t eligible for the requested build.” error message. (Apple, I hate you!) Well, maybe iTunes will be more forgiving. I go through the special key sequence to select the ipsw and attempt restore. Ah, looks like iTunes may do the trick. It spends some time grinding away and just when I think I’m home free I get the same “This device isn’t eligible for the requested build.” message.
Either that same day or the next I report in our daily stand-up meeting where we stand (no pun intended) with our ‘new-to-us’ iPhone 3GS. Boss’ boss says “why don’t you just restore it with the original 4.3 software?” Yay! After reminding colleagues that I don’t actually have any control over (or special insights into ‘why’ Apple does some things), I decide it’s probably best to show them (in person) the actual steps I take from beginning to end. They see it exactly as I did. (Apple, I’m tempted to never buy another iShiny for the rest of my life!)
And we still don’t have a real device running iOS 4.3 to test on! The saga continues. (And I still hate Apple!)
I recently was tasked with moving back the API target level (“uses-sdk”) of an Android app from 14 (Ice Cream Sandwich) to 10 (Gingerbread).
UI Layout
I developed this app and I already knew that I would have some UI layout work ahead of me. In the initial implementation I had decided to use GridLayout. This is what caused me to have the ICS target level to begin with. I consulted a friend of mine who’s far more knowledgable of Android development than I, and he recommended that I fall back to RelativeLayout. He was even kind enough to give me a bare-bones skeleton that was tailored to my screen.
It took a bit of tweaking and experimentation to get things right, but mostly because I’m still pretty new to Android UI layouts — not that it’s that hard to do.
ActionBar
This app was also built with an ActionBar so that the app would have multiple tabs to allow for single-tap navigation to other views. Knowing that this capability was introduced somewhere around Android 3.0, I knew that this would not be as quick or easy as my UI layout re-work.
After concluding that the app would be far too clunky if I abandoned the tabbed views, I wondered “Surely I can’t be the first developer who’s had the need to support tabbed views in Android 2.x”. After a few quick searches, it was clear that ActionBarSherlock (http://actionbarsherlock.com) was the answer to this dilemma. In fact, ActionBarSherlock was written to solve this exact problem.
I downloaded ActionBarSherlock and set up a project for it within Eclipse and then added that project as a dependency. Voila! Next, I had to change the parent classes of my tabbed views to use classes provided by ActionBarSherlock. ActionBarSherlock turned out to be an outstanding solution to this problem — quick, effective, and painless. It turned out to be an excellent drop-in solution to provide the backwards compatibility that I needed without having to drop ActionBar from my app. Nice!
Device Testing
At this point, the app compiled cleanly for Android API level 10 and it’s just a matter of testing. Since I don’t make much use of the Android simulator (real devices for me, thanks), I then started to wonder how I was going to test. All of my existing Android devices were running more recent versions of Android and I needed to keep them intact. After clearing a few cobwebs from my memory, I remembered that I had an ancient Motorola Droid phone tucked away in a drawer. I found the device and charged it up and see that: (a) it’s still in working order, and (b) it’s running Android 2.2.3. Plug it into my laptop and launch the app — it works!
Wrap-Up
ActionBarSherlock kept my tabbed views working properly on an older device where the software had no concept of tabbed views. This lesson also affirmed that it’s sometimes good to be a packrat and store old technology away ‘just in case’.
As you’re probably already aware, RIM will soon (January 30, 2013) be unveiling BlackBerry 10 (BB10). Nearly everyone agrees on this — if they fail in any way, they’re done. It’s also quite possible that even if their execution is perfect (or nearly so), they may still fail. I’m hoping that they succeed and this post explains why.
1.) Choice
Simply put, more options are better. Although I believe that Apple’s iOS solutions are the very best in the marketplace right now, I’m happy that Android is also there. I’m not particularly happy with many aspects of Android (more coming at another time), but competition and choices are both good.
2.) QNX
I have no first-hand knowledge or experience with QNX, but I’ve read enough about it over many years to have a great deal of respect and admiration for it. In a nutshell — it’s a small, real-time, Unix-like operating system. It’s been around for a long time and has survived the test of time (RIM’s business strategy notwithstanding). I would hate to see QNX fade away into oblivion because of a business failure.
3.) Qt
Not to be confused with Apple’s QuickTime (QT), this Qt is a different beast. It’s a mature, full-featured C++ framework that’s been around for a long time. It was started by TrollTech years ago and has been used successfully in many commercial (closed source) and open source projects, with KDE probably being the most high profile. Putting aside my pain points with C++, Qt has made remarkable progress over the years. Like with QNX, it would be very unfortunate to have this technology fade away due to a business failure.
4.) Industrial-Grade Server Infrastructure
I’ve never worked directly with any of the traditional BB server infrastructure, but from what I’ve read, RIM has produced some neat solutions regarding server infrastructure to manage their mobile devices. I think it’s safe to say that neither Apple/iOS nor Google/Android have anything even close to what RIM had available years ago.
RIM still has an uphill and very difficult struggle for survival ahead of it. Their execution has to be nearly perfect on many fronts. If BB10 fails while coming out of the gate, that’s it — it’s all over. However, I think that there’s a fairly large, yet mostly silent, group of mobile device users that really want to see RIM succeed with BB10 and provide an attractive and credible alternative to both iOS and Android. Another way to put it — we need a strong contender to enter the market and give both iOS and Android more competitive pressure.
Dave Brubeck passed away on December 5, one day before his 92 birthday. He was a gifted musician and member of The Dave Brubeck Quartet. Brubeck and his quartet broke new musical ground with ‘Take Five’ and other songs. They dared to reach out beyond the normative standards of the day for Jazz. Of course the classic Jazz masters like John Coltrane and others also made huge contributions, but Brubeck expanded the circle of what Jazz could be. He inspired many other musicians and groups. The beautiful world of music was made more beautiful by him. He will be missed, but not forgotten.
I decided to write this today because I’ve noticed, as is usual, an awful lot of knee-jerk reactions to ‘fix’ this problem once and for all. The standard response is usually one of these: (a) ban all guns, (b) reinstate an assault weapons ban, or (c) add many new regulations on gun ownership including ‘proving’ that you’re ‘fit’ for ownership. My hope is that I can provide perspectives from the ‘gun crowd’ that may cause the knee-jerkers to reconsider hasty decisions.
Today’s Tragedy
Today’s tragedy is terrible beyond words. There were no winners today. It’s senseless, unthinkable, and heart-breaking in the extreme. The families, the children, the school faculty, the first responders, and the entire community have been dealt a blow that no one should have to experience. I pray for all of them, and also for our well-being as a society. I hope that the entire community is lifted up by love, prayers, kindness, and compassion.
Gun Crowd Stereotype
I grew up around guns but I realize that there are many who have never been around them and conclude that anyone who owns a gun must automatically be some kind of nut-job. Unfortunately, there are some gun owners who are indeed nut-jobs, but we also have nut jobs who drink-and-drive and do all sorts of other reckless and foolish things. I can only imagine that many in the anti-gun crowd have a mental image of Joe Six-Pack or Larry the Cable Guy whenever they think of a gun owner. Once more, let’s talk about the average gun owner.
Hobbies or sports related to guns are not inexpensive. Guns, ammunition, cleaning equipment, and other related costs are often substantial. Many of those who are into guns are well-educated, white-collar folks — professional types. These are people who take gun safety and gun ownership very seriously. These are NOT the idiots you see on Youtube firing rifles at propane tanks at night. The average gun owner is a lot like you and me, or your neighbor, coworker, or family member.
Gun Uses
I often see people from the anti-gun crowd saying things like “a gun’s sole purpose is to kill – nothing else”. It is true that many guns are made to kill, but even so, that’s a legitimate use. Let me explain. Lawful game hunting is the ‘killing’ of game. The farmer or rancher who uses a gun to kill a predator (often a coyote, fox, or wolf) that’s coming after their chickens or livestock is ‘killing’ the predator animal with a gun. Both of these killing scenarios are lawful and legitimate uses of guns. Of course there’s also the usage of guns for self defense, and this too is a lawful (assuming one acts within the scope of the law) and legitimate use of guns for killing or wounding a perpetrator.
The non-killing usage of guns that anti-gunners rarely consider is target shooting. This is where I make use of guns. I like to poke holes in paper targets (the ones with concentric circles) as a form of recreation. Shooting shotguns at ‘clay pigeons’ is another form of target shooting that is a huge sport in the gun crowd. As strange and counter-intuitive as this may sound, it’s a fantastic form of relaxation and stress relief. If you don’t believe that this is possible, do a little research, or better yet, go out and watch some target shooting in action and maybe even give it a try yourself. You might be surprised.
My Background With Guns
I’ve been around guns all my life and have had a keen interest in guns since I was a kid. My first gun was a BB gun and then progressed to a pellet gun (air rifle) and learned basic gun safety and proper handling with these. At a later age, I was taught to shoot a .22 single-shot rifle and a single-shot shotgun. When I was about 11 or 12 years old, I started hunting with my dad and older brother. We hunted doves, rabbit, squirrel, ducks, and geese. We ate everything that we killed.
Eventually, I realized that the aspects of hunting that I really enjoyed were: (1) being in the outdoors, and (2) shooting; and that I didn’t particularly like the harvesting of game (the hunting itself). I stopped hunting but still enjoy being outdoors and shooting guns at paper targets.
The Second Amendment
The only point that I’d like to make here is that the United States Supreme Court has ruled that the gun rights protected in this amendment are for the individual and not merely a collective right as interpreted by some. This was a legal case that came to the Supreme Court where one of the big legal issues was interpreting whether the ‘militia’ referred to in the text of the amendment was an individual right or a collective right that would only pertain to something like the National Guard.
The Assault Weapons Fight
The anti-gunners have long recognized that it’s much more difficult to ban all weapons than to ban certain ‘unnecessary’ weapons. So, the anti-gunner thinking is “no one needs to own a military style rifle” (meaning that it’s not needed for hunting, target shooting, or self defense), therefore we should ban them to make our society safer. Here’s where things start to get tricky. I believe that there are 2 prevailing thoughts within the gun community on this one: (a) there are a fair number of gun owners who really view this as a reasonable compromise with the anti-gun movement, but may object to it because of the slippery slope fear; and (b) there are other gun owners who say that their right is absolute and no one can further limit their freedoms (beyond the Class III license/regulation of fully automatic weapons that has been in place since the 1930′s).
The Slippery Slope Fear
The fear is that if gun owners agree to surrender some rights as part of a reasonable compromise, it won’t be long before the anti-gun crowd asks for another round of restrictions, and then another, and then another, and so on. The anti-gun crowd frequently says that this fear is ‘irrational’ or ’misguided’. Is it?
What Exactly Do the Anti-Gun Folks Say
The best measure of true intentions of the anti-gun movement is to examine what they’ve said and try to determine where the real objectives lie. Perhaps the biggest political champion of the anti-gun movement is Senator Dianne Feinstein from California. Some years ago, CBS’ 60 Minutes did a segment on the Assault Weapons Ban and interviewed Senator Feinstein. Let’s have a look at her own words.
“If I could have gotten 51 votes in the Senate of the United States for an out right ban picking up every one of them… ‘Mr. and Mrs. America, turn ‘em all in,’ I would have done it. I could not do that. The votes weren’t here.”
If you’re thinking “that’s just a bunch of NRA propaganda to use as a scare tactic”, have a look and judge for yourself. Here’s the link to the video of the 60 Minutes segment and Senator Feinstein’s statement can be found 3:26 into the video.
http://www.cbsnews.com/video/watch/?id=7380236n
Let’s make sure we got that right: “out right ban picking up every one of them” and “Mr. and Mrs. America, turn ‘em all in”. The intentions are crystal clear. The objective is to ban ALL weapons (no exceptions) from all Americans. Senator Feinstein did not say “ban all military style rifles”. She said “out right ban picking up every one of them” and “turn ‘em all in”. She’s quite clear that the objective is not just to reach a “reasonable” compromise with the gun community of only removing those military style ‘assault’ weapons, but rather to outlaw ALL guns — including those used by hunters, ranchers/farmers, and target shooters.
So is the fear of a slippery slope on gun restrictions “irrational” or “misguided”?
Do you now wonder why the NRA takes such a hard-line stance opposing any form of gun control? Senator Feinstein, the author of the ‘Assault Weapon Ban’ (AWB) enacted under President Clinton’s administration, is on record (please verify this for yourself) and she’s quite clear that her objective is to ban ALL guns.
Deadlock
So we’ve ended up with the pro-gun and anti-gun groups at complete opposite ends of the spectrum, and the only “give” that you can find is for the anti-gun to back-off of a complete ban. I’m sure their take is ”some restrictions are better than no restrictions”.
Quick Revisit of the 2nd Amendment
As mentioned earlier in this article, the Supreme Court has already affirmed the individual right to gun ownership. The Supreme Court has not delved into the question of where those rights may end with respect to different types of guns. Thinking again about what Senator Feinstein said, it sounds to me that she probably doesn’t even really care much about our Constitutional (admittedly, her comments on video were made before the Supreme Court ruling on the individual right) rights.
We have an established process in the United States whereby the Constitution CAN be changed (albeit not easily nor quickly). If enough citizens think that we need to amend the Constitution with respect to gun rights, fine — follow that process and we all (both pro- and anti- gun) follow the same set of laws.
“You Americans and Your Guns”
I’ve heard countless times from immigrants about how the United States is the only country that allows such gun rights. They’re right! But guess what? The United States was not founded to imitate other countries. The United States was founded with an incredible emphasis and concern for individual rights and freedoms — and that pertains to guns as well as other areas. We make no apologies for our freedoms.
Why Have Guns At All?
The anti-gun movement pushes for a total ban and destruction of all guns. Here’s the part that they don’t understand: (1) Gun ownership is a Constitutional right of the individual, and (2) the biggest rationale about why the 2nd Amendment was added was not to safeguard hunter rights, it was to provide the citizens with a means to protect themselves from a tyrannical government. The anti-gunners often argue: “that may have been all well and good back in the 18th century, but with current military technology, an individual has no realistic means of fighting against the military.” The pro-gunners argue back: “that’s part of the reason why we don’t want any restrictions on the type of guns that we’re allowed to own”. To the anti-gunners who say that it’s silly to think that guns could help protect from a tyrannical government, I say “study your history”. See what the Afghan “freedom fighters” did to fight against the Soviet military back in the 1980′s and once again what’s occurred there with the United States military. Never underestimate the effectiveness of guerilla warfare when people are fighting for something that’s worth dying for.
Where Can I Find Level-Headed Gun Owners?
There’s a website called “The High Road” that is probably the best online place to find mature and rational conversation on gun ownership topics.
I’ve been doing iOS development for the past few years and with my new gig I now have Android development as part of my duties. Monday morning (12/3) I started in earnest on making an Android version of an iOS app that I just finished up last week (minus the app icons and splash screens). I’ve been at it full-time since Monday morning and thought that I would share my initial observations (good and bad).
The Good
1. Less Expensive Hardware
I like being able to buy real devices with less cash than what I can do with iOS. I also like that I have more options. My only real Android device (at the moment) is an Asus Nexus 7 tablet and I like it a lot. I’ve read in a number of places where others have complained about the build quality of the Nexus 7, but I don’t have any complaints with the hardware.
2. Open Platform
It’s nice to have an open platform where you have access to more stuff. An open platform also means that you’re more likely to have more options on development tools. Since I’ve never been enthralled with Eclipse, I might even have to exercise this option in the not-too-distant future.
3. Better Debugger
Okay, perhaps this is more of a slam against Xcode, but it’s nice having an IDE that hasn’t crashed on me yet nor forced me to run through a bunch of ‘clean’ hacks to pick up my changes. Bonus points for showing the value of variables without having to type ‘po’ on a debugger command line.
4. Easy Deployment on Real Devices
Deploying the app on a real device is one area that I need to prick myself with a needle to make sure that I’m not dreaming. For those who haven’t had the privilege of deploying an iOS app on real hardware, let me just say that it can be a huge pain in the rear (and has been since the iOS SDK has been around). With Android I keep thinking “so when do I need to start jumping through the hoops just to get the app loaded onto a device?”. With Android, this “just works” — and that makes it much nicer.
5. AsyncTask
I was really impressed when I stumbled upon AsyncTask and how it works. As the name implies, this class is intended to run some background task and then come back to the foreground with updates. It’s pretty slick how it works with this class. I was a bit surprised that nearly all the examples I found of it showed it being used as an inner class, but they may have done that to make the code more compact. I’ve been away from Java development for a while and was equally shocked to see support for variable arguments!
The Bad
1. The Emulator
The emulator seems to be fine in terms of functionality, it’s terrible to use with how slow it is. I suspect that the emulator will burn your battery life if you’re doing Android development on an unplugged laptop.
2. UI Layout
I dipped a toe into the Android development scene several years ago, so I had an idea that UI layout via XML files would not be high on my list. I was surprised (mildly) to see that there now is a ‘Graphical Layout’ option to show you the rendered UI, but it’s still terribly uninspiring. This is an area where Xcode really shines (or at least it did prior to the new constraints based madness). Getting things laid out should not be this hard. I haven’t tried the GridLayout yet, so it’s possible that I haven’t found best practices yet. Still, my hopes aren’t very high on this.
3. ListView vs. UITableView
UITableView is a real workhorse in iOS development and it’s a very powerful and well designed control. ListView is the closest thing that Android has to it, and it’s woefully inadequate. Setting up a plain list works well enough, but all too often the app requires something more sophisticated than a plain list. For example, it’s extremely common to have a list with sections and each section having a titled header with a different background color (usually a nice contrast) to make the section headers stand out. Yes, there are countless examples on the web that show different ways of doing this. The fact that this capability isn’t built-in was shocking. Really? Every app developer out there should code this up themselves every time it’s needed? Uggh!
4. The Fonts
I wouldn’t expect any platform to ever have as many fonts as iOS provides, but to have only 1 or 2 (or whatever the actual count is) is sad. Any developer coming from iOS or Mac cannot help but being unimpressed.
5. Generally Unrefined
I knew that this was going to be a tough area for Android. It’s difficult to match the UI polish provided in iOS. It looks like there are a bunch of areas where the Android community doesn’t make much of an effort to create UIs that are attractive and usable. I can’t help but wonder if it’s not due to Linux folks who take pride in having their toys being rough around the edges — you know, something to wear as a geek’s badge of honor? Maybe if the stock Android UI were more refined the carriers might be less likely to put their own skins on the devices. Then, maybe it would be easier for users to have their devices more up-to-date with Android. Might even help with the ‘fragmentation’ problem too.
The Unanswered
Image-Tiled Background
Taking a small rectangular image file and using it to fill an image view control is something that I did a lot in iOS apps. I have the need to do that in this current Android app, but I haven’t found a straightforward answer on this one yet. This is something that’s extremely easy to do in iOS. Drag a UIImageView onto the view, set its size, set the image property to the image file, and set ‘scale to fill’. My impression is that it’s not quite that easy in Android.
I recently joined Apigee (http://apigee.com/about/) 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
