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 many 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?

I Quit the Company I Cofounded

I recently quit working at Grapes ‘n’ Berries, the company I cofounded almost 2 years earlier.

I’ve always heard that quitting your own company is a very hard thing to do, and that was exactly right. My decision to quit though came from the realization that Grapes ‘n’ Berries has precisely turned into the company I never wanted to create, and that I have no control to change it.

I bet you’ve heard a million times that picking your partner(s) is the most important step of starting a company. I’ve unfortunately failed to do so. I found myself in a commitment with a partner that does not share any of the values I believe in, comes from a completely different background, and does not have the same vision of where the company should be heading.

If I had to give some advice to 2-years-ago me, my advice would be:

  1. Spend lots of time to know your partners very well, why they want to start the company you are starting and what’s their vision for it in the future.
  2. Non-full-time founders are a no-no. If someone wants to invest money in a startup but doesn’t want to risk quitting their full-time job, they should simply be investors, not cofounders, and certainly not CEOs.
  3. Before jumping in and starting to do any work, agree on (and document) the equity split, the amount of money each partner is putting in, if any, and what happens to a cofounder’s equity when they leave. I recommend a standard 4-year vesting period for the latter.
  4. If any of the cofounders is putting money into the company, make sure that this money will be available in the company’s bank account in its entirety from day one.
  5. Set up a board of directors with an odd number of members as early as you can. The odd number will prevent tie votes.
  6. Stay away from cofounders whose sole purpose of starting a company is to make money. Maybe recommend real estate to them.

While it makes me sad that I no longer get to work with the great team of developers I assembled since we started Grapes ‘n’ Berries, I was at a point where I could no longer stay in a partnership that’s not aligned with what I want to do.

The Joy of Programming

I’ve seen many tech companies where people on the business side have a complete lack of understanding of what motivates software developers or makes them do the work they do. This results in dissatisfied and demotivated developers that are eventually going to quit and move on to work on something more exciting somewhere else.

While it’s usually hard to put the joy we get out of programming into words, The Mythical Man-Month by Fred Brooks does a very good job with that.

Here is a quote from the book’s first chapter:

Why is programming fun? What delights may its practitioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God’s delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and find it helpful. in this respect, the programming system is not essentially different from the child’s first clay pencil holder “for Daddy’s office.”

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of the principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism carried to the ultimate.

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another, the problem is always new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.

Finally there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

I believe that there’s a balance that can be struck between work that engaging, challenging and fulfilling, and work that is financially rewarding. Focusing on either side and ignoring the other results in dysfunctional companies that are bound to drive employees away.

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.

Focus List

I’m heavy user of to-do apps, specially Wunderlist, but recently my to-do list started to be a place I dread looking at it. I have too many lists, overdue tasks, things that I need to work on today, things that I need to take care of a week from now, groceries shopping lists, and a plethora of other things.

Simply it was just too distracting for me. Just like the 1000+ unread messages in your inbox right now that makes it impossible to read a message without being distracted by all that noise.

My primitive solution to the problem was to grab a piece of paper everyday, write only the important tasks that I need to focus on today, and ignore the rest of my to-do list for the rest of the day. By the end of the day, I throw away that piece of paper and start the next day with a fresh set of tasks. That approach worked quite well for me, so naturally the next thing for me to do as a software engineer was to turn it into an app.

Focus List does just that. It’s a very minimal to-do list with only a place for tasks you need to focus on today. The list is wiped out clean by the end of the day so you always start with a clean slate next day in the morning (or whenever you tend to start your workday).

Even though Focus List is very simple, I’ve been working on it for quite some time now. Since my goal wasn’t just to ship it, but rather to do some experiments in both the UI and the code along the way, I’ve changed the UI a couple of times and rewritten the majority of the code every time.

FocusListIcon

Download from the App Store

Focus List is available on the App Store for free with no ads or in-app purchases. Go grab it now, and I hope it helps you be more productive.