What it’s Like to Work on an iOS SDK

Ever since I started developing for iOS, I have been working exclusively on mobile apps. I didn’t have any real experience shipping an SDK, other than HMSegmentedControl, which doesn’t really count as an SDK.

I recently joined Instabug’s iOS team where we build an SDK for bug reporting and in-app feedback, and I was reflecting on how the experience of working on an SDK is different from working on an app that ships to the App Store.

Crashes

We all work very hard and use a plethora of tools to make sure our code doesn’t crash, but at the end of the day, you know that when you finally ship your app there are going to be some crashes, which will get reported to you through your crash reporting tool of choice, you’ll fix them, ship an update, and life goes on.

That’s not how you feel though when you work on an SDK, specially one that helps you do bug and crash reporting. It would be very ironic if our SDK is the reason your app crashed. So making sure our code doesn’t crash is usually a much more stressful endeavor that it is with when developing apps.

Debugging Weird Bugs

We’ve all seen that bug that only happens in very specific conditions and only to a small percentage of users. Getting that kind of bugs in your apps is not fun. Getting it in an SDK that’s being used by another app that has code you cannot see or have any knowledge of what it does is a totally different ordeal.

Stricter Constraints

Developing an SDK means we have much more constraints compared to an app. Admittedly, some of these constraints are self-imposed.

Dependencies

One of those biggest constraints is using as little dependencies as possible. This means no third party dependencies at all in our code, and also only using frameworks from Apple that are absolutely essential to what we’re doing to keep our SDK as lightweight as possible.

Integration Steps

We want it to be super easy to start using Instabug, so we make an effort to keep the steps you have to do to integrate our SDK into your project as simple as possible.

For example, we avoid asking developers to add any extra build settings to be able to use Instabug. Since we ship a static framework, this means we can’t do things like using Objective-C categories since that requires adding an additional linker flag.

Supporting Older Versions of iOS

When building apps, we have the luxury of deciding when to drop support for older versions of iOS, or to simply follow the common wisdom of only supporting the current version and one before that.

Things aren’t that simple though when building an SDK. If a big percentage of apps using our SDK are still supporting older versions of iOS, then we have to support them too. We only dropped support for iOS 6 a couple of months ago.

Framework Size

When developing an app, you do an effort to keep the download size at a reasonable number, and the last thing you want is for your download size to double because of an SDK you use.

That means we have to think long and hard about resources we add into our SDK to make sure the size we add to your app is minimal.

Building a UI that Works for All Apps

Every app has a unique UI, and that’s something we have to keep in mind when building Instabug’s SDK UI. Our UI has to be good-looking, yet vanilla enough that it doesn’t have a unique identity that’s different from your app. It also has to be completely customizable so developers could give it a similar feel to their app, and that is sometimes a hard balance to strike.

It’s Freaking Awesome

Working with all those constraints and limitations ends up being a fun challenge. And at the end of the day, we get to ship code that runs on millions of devices everyday. Who would complain?

6 Tips for Better App Designs

I often work on mobile apps with designers that have a web design background. I see the same set of mistakes being made as they transition from being web designers to mobile apps designer.

Here are a few tips from a developer’s point of view that I believe would make you create better designs and would help the developers you’re working with create better apps.

1. Don’t make teeny tiny touch targets.

People don’t use a mouse on their phones, they use their fat squishy fingers, so adjust your touch targets accordingly. Don’t expect people to be able to tap a 20×20 pixel button that is surrounded by a bunch other tappable elements.

2. Understand the proper usage of UI elements.

Both iOS and Android have thorough UI guidelines that talk about the proper usage of each UI element. Don’t consider yourself a mobile designer if you haven’t read those. Also, it’s always useful to look at how existing apps solve problems you’re trying to solve. Pttrns is a great resource for doing that.

3. Don’t design for a platform you haven’t used.

Don’t design apps for iOS or Android if you don’t use them. Reading the interface guidelines and looking at other apps will help a lot but it’s not enough. You won’t get a grasp of what a good app on a certain platform should be like unless you’ve used that platform for some time.

4. Understand the different screen sizes and the impact it has on your designs.

Don’t be one of those designers that just want to know what size they need to export the images assets to. You need to understand how different screen sizes are treated on each platform and how that would impact your design.

5. Designs are not static.

Many designer make the mistake of thinking of their designs in a static way. Those usually end up with pretty designs that aren’t very usable. Think of the animations and interactions of the app. Think of the different states of each view and how views are going to look like when they are empty or full of data.

6. Learn to code.

It’s not as crazy as it sounds, and no one is expecting you to be able to build complete apps on your own, but dipping your toes into coding will give a better perspective on what’s possible and what’s not and will greatly help you build better apps.

Getting Featured on Apps Gone Free

TracKit recently got featured on AppAdvice’s Apps Gone Free. While I knew that this means a nice bump in downloads, I had no idea what numbers to expect.

After the initial launch a year and a half ago, TracKit downloads settled down to a consistent 5 to 10 downloads per day. The day TracKit got featured, I got 8,622 downloads. Apps Gone Free features apps for only one day, but it still created enough exposure for the app to get downloaded 3,032 times the second day, then it dropped significantly during the rest of the week, but still maintaining a higher-than-average number of daily downloads.

Screen Shot 2015-05-17 at 12.59.29 PM

Overall, TracKit got around 12.5k downloads as a result of being featured on Apps Gone Free. While it won’t make your app jump into the top charts, it sure gives a nice, appreciated boost.

Depending on your type of app, you have to either make it free or make the IAPs it offers free to get featured on Apps Gone Free, which means no change on revenue, on the short term at least.

Thanks Apps Gone Free.

TracKit 1.0

I’ve shipped the first version of my new app, TracKit, today. It’s a little tool that I personally love to use.

iOS Simulator Screen shot Sep 11, 2013 10.27.39 PM

I  love tracking things, lots of things. I might even be guilty of overdoing it. I like to track the number of hours I sleep, how many kilometers I manage to get out of each tank of gas, the time I spend commuting and lots of other stuff. If at this point you think I’m weird then this app is definitely not for you.

The reason I track this kind of stuff is to be able to get a quick overview of how I’m doing at anytime, and try to optimise it. I built an iPad app a long time ago that I used for this purpose, but it was far from perfect, even for my own needs. So I never even thought about releasing it. A few weeks before WWDC when iOS 7 was announced, I was seriously considering building a new version which does the same thing with a few extra features. By the time iOS was first previewed I had already made up my mind and started building it as soon as I was able to download the new SDK after the keynote was finished.

The goal was simple. Build an app that would help me track all the crazy things I like to track, visualise my performance with a graph, and show me stats that would give me a quick overview about how I’m doing with what I’m tracking. And the result was TracKit.

I might be the only crazy person that likes to track things happening in their life, or their might be a lot of other people who also need this app. In either cases, I’ll keep building TracKit until I’m personally satisfied about it. So I have a lot of exciting features planned for the next few months. In the mean time, go get it from the App Store and let me know what you think.

button-downloadontheappstore-flat

5 Essential Apps for Every iOS Developer’s Toolbelt

I believe the 5 apps below should be in every serious iOS developer’s toolbelt. They save a lot of time and frustration and help you produce apps with a higher quality. Some of them might be a bit pricy but, trust me, they are worth the investment.

Spark Inspector – $39.99

Debug your app’s interface in a three-dimensional view and change views properties at runtime. This has proven to be an amazing tool to debug complex UIs.

screen_0

 

Kaleidoscope – $ 69.99

Kaleidoscope is a diffing tool on steroids. It compares differences between text, images or folder and lets you merge changes in seconds in an elegant way.

3UP_Fluid

PaintCode – $99.99

PaintCode is a vector drawing app that generates Objective-C code in real time. Use the vector drawing tools to draw your UI components and PaintCode will generate the Objective-C drawing code. Great for writing reusable components.

 

titlescreenshot

 

 

Deploymate – $19.99

Before releasing your app, Deploymate will come in handy in helping you identify unavailable, deprecated and obsolete APIs in your code. Great to prevent embarrassing crashes from using APIs that aren’t available in your deployment target.

ss5

Tokens for Mac – $29

When you’re finally ready to release your app, Tokens for Mac is the easiest way to generate, share and track promo codes. It even makes the redemption easier for people you’re sending out the promo codes to.

2012-11-20_211814-tokensmain

Xcode & Cocoa Tips

This is a set of random Xcode & Cocoa related tips I wrote while doing code reviews for other developers. Some of them might seem trivial or really obvious but you will be surprised by how many developers miss them.

  • Don’t abuse the app delegate: The UIApplicationDelegate has one role: it’s responsible for handling events related to the lifecycle of your application. Don’t abuse it by putting networking code or UI code there.

  • Remove unnecessary boilerplate code: When you create a new file Xcode will add some boilerplate code and method stubs, such as an empty initWithNibName:bundle implementation and unused UIApplicationDelegate methods. If you are not going to use these methods just remove them to keep your code clean.

  • Keep project folder organized: Xcode is messy when it comes to the project folder. You will end up with a big folder that has classes of all sorts, images and other resources all in the same place. To avoid this always organize your folders by creating subfolders manually in Finder and placing your classes/resources in them, then drag the files to Xcode and uncheck Copy items into destination group's folder (if needed).

  • Avoid using preprocessor macros for constant strings: Preprocessor macros have their uses, but using them as static strings isn’t one of them. If you need static strings, the best practice is to declare a static NSString in your header file: extern NSString *const kFoo; and then set its value in the implementation file: NSString *const kFoo = @"foo".

  • Model-specific constants do not belong to a global constants file: If you have a model (i.e User) that has some static strings related to it (i.e kUsername), it’s recommended that you declare them in the model class instead of a global constants file.

  • There’s no need to synthesise properties: Starting from Xcode 4.4 you don’t need to @synthesize properties to create setters and getters. The @property in the header file alone is enough for the compiler to generate setters and getters for you.

  • Don’t copy and paste code: Whenever you find yourself copying and pasting code between different classes you are probably doing something wrong, or not doing it in the best possible way. You should consider subclassing the classes you find yourself copying and pasting code between. If you want all your view controllers to have a red background, don’t copy and paste the code that changes the background to every single view controller. Instead, put that on a UIViewController subclass and use it as a base class for all your view controllers.

  • Write meaningful NSLogs: NSLog is very useful for debugging. If you tend to leave your NSLogs around after committing your code, make sure they are meaningful and that other developers running the app will understand them. Don’t print things like “Hereeeeeeeeee” to the log, chances are even you will forget what those indicated.

  • Commit a lot: Make it a habit to commit your code more often. Don’t work for the entire day then commit the changes you made to 50 different unrelated files at once. Instead, commit each related set of modifications together with a descriptive commit message. This will make it easier for other developers to merge code and for you to track historical changes.