Sam Baumgarten

The Life of a Developer

April 6, 2014

Exploiting NSUserDefaults (and 2048′s high score system) without a jailbreak

A few days ago I was looking at how various apps store data on a users phone.  I was thinking about how Apple sandboxes NSUserDefaults and potential ways to modify the information an app has stored without jailbreaking my device.  It’s commonly known that if a user has jailbroken their device, they have access to pretty much everything including NSUserDefaults; however, if a device isn’t jailbroken (aka. you have no access to its file system), it should be much harder to access this information.

While playing around with this, I was able to exploit the high score system in a game called 2048.  I changed back my high score after I was done and only incrimented my score by 100-200 points so I could legitimately beat it after I was done.

Here’s how I modified the stored score:

So I remembered back to a few months ago when I had 2 apps with the same bundle identifier (accidentally).  The apps “merged.”  The icon was for 1 app while the actual app itself was the other.  The assets were also mixed up.  A quick google search showed me that NSUserDefaults is sandboxed using an apps bundle identifier.  The first thing I did was download the app I wanted to experiment with (2048) from the iTunes store onto my computer so I could obtain the bundle ID.  I then navigated to ~/Music/iTunes/iTunes Media/Mobile Applications/ and duplicated “2048 1.2.ipa.”  I then changed the extension to .zip and unzipped it.  In this folder I navigated to Payload/ and then right clicked on “2048″ and clicked “Show Package Contents.”  I then opened up Info.plist in my text editor (textmate).  I scrolled down until I found “CFBundleIdentifier.”  For 2048, this happens to be “com.ketchapp.2048″.

The next thing I did was create the fake app.  I opened up Xcode and created a new singe view application.  I set the bundle identifier of this app to the one I found from the application bundle.  I added a UITextView and set the text of it to 

I then ran this app on my phone (with 2048 installed) was able to look at the output from that.  I noticed a entry called “highscore.”  I then added the following code to the app delegate to change that variable (I used a much smaller number)

Now that the variable has been changed, all I had to do was put the old app back on my phone.  I did this by going to Xcode Organizer and going to the “Applications” tab under my device.  I clicked add and chose the IPA I downloaded earlier (from iTunes).  I then waited for it to install and restarted my phone.  When I turned it back on, the old app was back and my high score was the one I set with my fake app.

Here’s the thing.  The way 2048 was written, it seems it sets its game center scores based on the NSUserDefaults value.  This means when I went to game center, I was in a very high rank.  While testing this, I didn’t use any absurdly high numbers as to not draw attention to myself.  I also used an alternate account.

Honestly, this isn’t a huge exploit.  The average user doesn’t have the time or knowledge to do this; however, if you want to secure your app against it, here are a few things you can do:
1) Avoid using NSUserDefaults (not always practical; however, you could use the keychain instead)

2) Encrypt data stored in NSUserDefaults (no one will bother to crack your encryption just to get a higher score)

3) Store data on a server as well and then check if the local version and server version are the same

January 4, 2014

How much is too much (aka, me critiquing my own app)

A little while ago, I was thinking and I realized one of my apps, Dismissrr, was due for an update.  I quickly decided to make it from scratch and thought of a fairly good idea for the UI.  I dove right in and started making models and classes for the app.  This was my first mistake, I should have sat down, wrote a features list, made some UI mockups, and strategized how to make it.  In all fairness, the app turned out pretty well; however, it took longer than I would have liked to make.  This was due to the amount of time I spent overdoing things and stupid ideas I didn’t think through.  In this article I will talk about what I over did in the app and what ideas I had that shouldn’t have ever gotten past the drawing board.

Complicated Algorithms for minor issues

IMG_0379The image to the left is a screenshot of the app.  One of the things I spent the most time on was the label in the scanner circle that says, “Smith.”  If you are a developer, you are most likely wondering how in the world I could make a UILabel that complicated.  While I was coding it, I realized that if the user is over a black background, the label is hard to see.  I proceeded to write an algorithm that changed the color of the label to the opposite of the color it was over.  This led to a whole number of memory issues and other problems coming up.  After I was finally done, the color changing didn’t even seem natural and was confusing.  If I had just thought about the time it would take to do this vs the payoff, I would have realized it made no sense to do.  Yes, I could have spent a few more hours getting it to work well; however, it wasn’t worth much so I just scraped it.

Not figuring out transitions

If you look at the bottom of the screen, you can see it says “Slide left to dismiss students.”  As you can imagine, this label wasn’t part of the original design in my head.  After making the whole app, I realized I was missing a whole major feature of the app.  From the beginning, I figured you would tap or swipe somewhere to open up that screen; however, I didn’t think where or how the user would know and just forgot about it.  Eventually, I added it into a UIScrollView.  After I added it, I thought about how logical it would be to swipe.  I concluded it would be logical to swipe to see it.  Luckily, after I did this I made a good decision: I asked 3 people how they would try to get to the “dismiss” screen.  It took them quite a while to figure it out.  I knew I needed to change something hence the label at the bottom.  While it works very efficiently, it looks awful in my opinion.  If I had just taken the time before making the app to think through the UX and UI there would most likely be a far better solution.

Creating unneeded Restrictions

If you look at the screenshot, you will notice that there is a circle in the middle.  The purpose of this circle is to show the user where to position the QR code in the frame.  When I was first writing the code, I tried to restrict where the code could be so it wouldn’t scan if it wasn’t inside the circle.  One of the worst ideas I have ever had.  Let’s take a step back and make a pros vs. cons list.

Pros Cons
No comment Makes the user frustrated because the code won’t scan
Creates complexity in the code
Makes it unclear how the app is supposed to be used if the codes will not scan

as you can see, it’s a pretty one way pros vs cons list.  Obviously it was a bad idea.

I didn’t make a spec

This isn’t quite as major; however, it was a mistake.  Before I make an app I have a protocol that I like to follow.  I also tend to do it when I am working for clients.  I will make a document and call in the vX.x spec.  This document will list all the features and details on what each one should do.  When development starts, I essentially lock this document and it cannot be changed anymore.  I develop what is written and don’t change anything.  Of course, I always end up making small changes; however, nothing major gets changed.  This is nice because it forces you and/or your client to think about exactly what features are needed and second, it keeps you on the right track in terms of feature development.


There were a few things I wanted you to get from this article (besides for that my app had a few UX issues when in the development stage).  The first being never neglect the planning stage (unless you are at a hackathon in which case you should shorten it).  It is just as important if not more important than the coding stage (I know it may be hard for some developers out there to believe that) :).  It will save you many headaches down the road.  Along with that, try to make a spec with a list of features for the release.  This will prevent you from going crazy adding unnecessary features.  The second thing I wanted you to take from this article is think about if what you are doing is actually important to the app or if it would just create confusion.  Part of this whole minimalism thing is removing unnecessary features.  The simplest things are the most complicated; however, you should make everything essential to the app perfect before you go on to add smaller features (such as color changing effects). Lastly, I wanted you to learn all the boring color animation things you learned to do when you were starting iOS development actually may be useful one day.  For more tips and to ask me questions, follow me on Twitter.

November 6, 2013

How to choose a developer for your web app

“Do not hire a man who does your work for money, but him who does it for the love of it.”

- Henry David Thoreau

Recently, someone tweeted at me.  He said:

So I pondered this question and thought about what I look for if I ever need to hire a developer.  True, I am an engineer myself; however, sometimes I need other people to work on my own projects or to help a client find another developer.  Here’s  what you need to know about hiring a developer:

Understand the difference between an Engineer and a Developer

Often, I hear the words engineer and developer used interchangeably, even I sometimes do it. However, there is a very clear and major difference between these two terms.  According to the Merriam Webster dictionary an engineer is, ”a person who has scientific training and who designs and builds complicated products, machines, systems, or structures : a person who specializes in a branch of engineering.”  The definition of an developer is, “a person or company that creates computer software.  The major difference here is a software engineer designs applications (the structure) and a developer codes them.  All software engineers are developers; however, not all developers are engineers.  Developing software is not extremely difficult; however, learning how to design applications is.

 Don’t choose the cheapest developer

In the world of hiring developers, the saying you get what you pay for applies to an extreme extent.  Developers are in high-demand and if you find a developer willing to work for under $20 per hour, run as fast as you can.  There is a reason that developer charges so little.  A engineer with over 6 years of experience will cost you in-between $80 and $250 per hour. (aka, don’t hire a code monkey

Passion is key

You have an extreme passion for your product which is why you spend so much time and effort working on it.  To reference the quote at the top of this post, don’t find the developer just looking for money.  Find a developer that has a vision for your product that aligns with yours.  You can give a developer a billion code tests; yet, you wouldn’t know if he really cares about your project.  The more your developer cares, the harder he will work.

Always conduct a skype or in-person interview

Even if you have no idea on how development works, still talk with the developer before you hire him.  You can talk with him about who he is, what he likes doing, and where he sees your product going.

Tech Advisor

This point connects with my last point a bit.  Try and find a technical advisor to your project.  This tech advisor can help out a lot while hiring people.  First, the developers will know not to tell you BS.  Second, your tech advisor should have a good idea of if this person can actually do what they are promising.  And last, your tech advisor can ask the person technical questions.

That sums up this article.  If you guys have any ideas for articles, tweet me (@baumgartensam) or email me at  A big thank you to Lance Selgo for the idea for this article.  Don’t forget to tweet this article and share it (and vote it up on hacker news) :)

Also, if any of you are interested in having me as a technical advisor to a project, please shoot me an email.

August 24, 2013

Sam’s Objective C Style Guide

A few days ago, I was talking with another developer I’m working with about what styles/format we should use to keep out code constant.  I didn’t really like any of the existing ones because they were to complex or I just didn’t agree; so, I decided to write my own.


The rule

Always indent using 2 spaces

The Reason

It makes your code less cluttered because your lines won’t be as long.




The rule

Camel-case all variables because Obj. C is designed in a way where this will work/look better.

Sometimes Xcode can automatically synthesize variables for you.  If if can, let it.

The Reason

Obj. C is designed in a way that camel-casing variables looks better.


The second looks better, doesn’t it.


Dot Notation

The rule

Dot notation should be used for setting variables; however, don’t use it for calling methods (even if it is possible).

The Reason

It looks way cleaner




Method Definitions

Rule 1

The rule

Define methods with a space between the “+” or “-” and the return type.  Also put a space between every method parameter.  Also, prefix every parameter after the first with “withVariableName:” and the last one with “andVariableName:”.

The Reason

It makes it easier to read and more English like.


Rule 2

The rule

Don’t put line breaks in method definitions

The Reason

It takes up lots of space



If statements/for loops/curly brackets

Rule 1

The rule

Always put the opening curly bracket on the first line and the closing one on the line below the last line.

The Reason

It takes up less space and looks neater


Rule 2

The rule

The else part of if statements should be on their own line, but only 1 line

The Reason

Using 2 lines looks messy and is inconsistent with the way if statements are written.




This was just what I could come up with on the spot.  I plan to update this post with new rules I come up with.

If there are any things you think should be listed, comment below or email me at and I’ll add them.

July 30, 2013

The 5 Rules of Testing (iOS Style)

“I never make stupid mistakes. Only very, very clever ones.” -John Peel

So my last post, The 5 rules of iOS interface design, seemed to do pretty well. In the comments, @graxa said, “Dont forget test, test n’ test your App.” I was going to write a post on the specifics of how I test, but then I realized, dozens of people have already done that. Instead, I decided to write a post on the general methods and practices I use for testing. Ladies, Gentlemen, and Engineers, I present to you, The 5 Rules of Testing.

1. Don’t only use unit tests

I can’t even begin to tell you how many people I talk to who when I ask them if they have tests say, “Yes, we have a lot of unit tests written.” I’m not here to say unit tests have no place, what I am trying to say is only having unit tests isn’t enough in most situations. Unit tests help you ensure your algorithms are working correctly and data is correct; however, in an iOS app, that generally isn’t enough.

2. Use acceptance testing

Acceptance testing is extremely important.  I, like many others, am guilty of not always writing tests right away or sometimes ever.  After a while, I realized I was spending more time fixing bugs that tests would have caught then it would have taken just to write tests in the first place.  Personally I like to use Calabash for automated testing; however, I have also used Frank, Automation UI, and probably a few others I forgot about.  If there are any you like, leave them in the comments.  I’m also working on a calabash tutorial now, follow @baumgartensam on twitter to find out when that goes up.

3. Write tests for every new feature

Whenever you add a new feature, write a test.  Yes, writing features is way more fun than writing tests; however, using working features is way more fun than using broken features.  Instead of making someone you are working with write the test, just write it yourself.  It will take you less time because you know your way around the feature.

4. When ever you find a bug, write a test

Bugs are obnoxious, and more often than not they will reappear; however, rather than forgetting about them, you should have a test to tell you if they ever break again.  Whenever you find a bug, you should write a test for it.

5. Use test driven development, unless it doesn’t work for you

Just recently did I start doing test driven development (TDD).  TDD is great in someways because it makes it so you aren’t constantly checking things in the simulator or on your device.  But, TDD isn’t for everyone or every project.  Sometimes it is easier just to test it on your own.

6 (BONUS). 

Don’t follow the things I said in this article religiously, instead, find something that works for you.  Every person tests differently and every project needs to be tested in different ways.

May 16, 2013

The 5 rules of iOS interface design

Sorry it’s taken me so long to write another post.  It’s been a crazy few months with job interviews, product launches, finals, and much more.  Today, I’m talking about one of the bigest mistakes I see on the app store, people not thinking about their app’s interface.  Even if a app is great, it’s useless without a good interface.  Here are 5 rules you should follow when designing iOS apps.

1. Don’t make your app 100% UIWebView based

Even though coding your app with HTML, CSS, and Javascript may seem like the easiest way to make an app at the time, it will haunt you later. It’s quite obvious when someone bases their app on a UIWebView. It completely ruins the user experience. Also, later on, if you want to add new features that require built in methods or certain hardware, you will have to rewrite your entire app. You are probably thinking, “Sam, what about frameworks like PhoneGap.” My response to that is, “do you want to wait til PhoneGap implements a new feature to use it or do you want to just use it right away, the way Apple intended you too.”

2. Use built in UI components

Apple spent a ton of time writing UIKit and coming up with great UI components. Don’t ignore them and write your own if you don’t need to. That’s not to say you shouldn’t customize them. There’s (almost) nothing worse than an app that doesn’t customize the components at all.

3. Don’t reinvent the wheel, unless you can make a better one

This is kind of similar to the last rule. Before you EVER rewrite some complex code, first check Apple hasn’t done it first. Apple has a ton of classes that help you do a ton of things that would take a lot of time and effort to write. Also check GitHub for libraries and code examples to give you ideas on how to do what you want to do. One example of a library that reinvented the wheel and did it better was Stig JSON Framework. Anyways, just remember, don’t reinvent the wheel, unless you can make a better one.

4. Use Objective C

Just because there are libraries like Ruby Motion and PhoneGap, doesn’t mean you should use them. Most of the time it’s best just to use Obj. C. Even if you don’t know Objective C., learn it. It will end up helping you in the long run for the same reasons mentioned in the first rule.

5. Always make mockups before you start coding

The biggest mistake you can make is diving into code without a plan. Your code will end up messy and unstable and the user experience generally won’t turn out very well. Even if your mockups are just scribbles on paper, it’s better than no plan. I found this awesome website,, it has templates that make it way easier to mockup your app on paper.

March 19, 2013

Why every developer should use Code Climate

I’ve been using Brakeman for a while, and don’t get me wrong, I love it.  However, sometimes using a SaaS product is just better.  I’ve haven’t been using Code Climate for very long; but, in the little time I have used it, I have fallen in love with it.  In this post, I will go over a few of my favorite features in Code Climate.


Ok, this may be the best part about Code Climate.  Right from the homepage, you see a nice visual that shows you the current state of your code:

GPA Viewer

At one glance, I can see a overview of what I should refactor.


The interface is amazing!  It’s super intuitive and well designed.  Enough said.

Home Page


Trends are a feature that is greatly underused in most apps.  I will go into some depth on how they are used correctly in Code Climate.

Any app that has data that changes based off user actions should consider having a trends feature.  The key to designing a trends feature well, is supplying only information a user wants to know.  For the most part, users don’t care about the latency of your server; however, they do care how quickly you can, lets say, send emails. Code Climate only shows you 3 pieces of information; however, it’s pretty much everything you want to know.  There are a few other things I would like to know; however, Code Climate is pretty good at trends.

Another aspect that is commonly disregarded and tabled is the styling of the graphs and trends page.  It’s very important to be able to easily understand what a graph means and that the graphs are ascetically pleasing.  Google Charts are great!  Just try not to use the default styles, make it fit into your apps style.

My last piece of advice in this section is use tooltips, and if possible, also update content on the current page with the current selection.  In Code Climate, when you hover over a data point, all the other data on the page updates with it.  This makes for a great UX.

Trends Page



I got a bit off topic in this post but I think the content will be useful.  If want more posts that talk about how-to implement features like trends or more post that are how-to style, just comment below.  Also, don’t forget to subscribe to my newsletter!  Leave your feedback in the comments :)

February 27, 2013

Woah! This is a complicated app. Where do I start?


“Woah! This is a complicated app.  Where do I start?”  I’m not sure if you ever have had this reaction to a development project, but I definitely have.  In fact, I had it when I started working on ConvertKit.  I dove right it and coded random features. Not a good idea.  The code was very messy and had a TON of bugs.  Luckily, I only wasted around half an hour before realizing I was doing it wrong.  I ended up scraping the code and rewriting it.  Don’t worry, the production code doesn’t have anywhere near as many bugs :).  In this post, I will talk about the correct way to tackle a big project and what we ended up doing with ConvertKit.

Step 1: Planning

Ok, so planning is SUPER important, but when you go to plan a development project, it’s hard to find a good place to start.  Here’s how I do it:

Step 1) Make a list of all the major features in your app

For ConvertKit these were:

  1. User Signup and User Editing
  2. Accounts
  3. Landing Pages
  4. Courses
  5. Lists (ended up removing these)
  6. Email Sending

Step 2) Take the first feature, the first one only, and write down the models you will need to create (if you have a MVC app)

For security reasons, I shouldn’t post ConvertKit’s models on my blog. Sorry :(

Step 3) Start working on feature 1 and finish it before going to feature 2

Work on a feature? What do you mean?

When I say working on a feature, I mean coding the WHOLE feature.  Even the small little details.  Focus on this feature like it is your entire app.  Eventually, once you are done, you can repeat steps 2 and 3 for feature 2 and so on.  A good way of telling if you are done is asking yourself, would you release this to the public if it were your whole app.  If the answer is no, keep working on that feature.  If the answer is yes, congratulations, you finished the first part of your app!


I just realized there are only 2 sections in this post excluding the conclusion and introduction.  Oops! Anyways, reply bellow with your reactions and any other input or methods you may have.  If I like your method(s), I may include it in the post (obviously giving credit to you).

February 26, 2013

Learning a new language, the programming kind

“Naturally, a tool for getting rid of bugs in your program is called a ‘debugger’. Mudanely enough, the corresponding tool for putting bugs into your program is called a ‘programmer’.”
-Simon Cozens


There are 4 main ways to learn a new programming language:

  1. Watching tutorials
  2. Reading a book
  3. Take a course
  4. Hire a developer for your current project and look at his or her code to learn

I ranked those by effectiveness, 1 being the least effective, and 4 being the most effective.  In this post I will be focusing on 4, hire a developer for your current project and look at his or her code to learn.  What’s a better way to learn a new programming language than to see how a expert does it.  If you have questions, no problem, just ask your developer.

Finding a developer

Ok, so this doesn’t only apply to people learning to program but rather everyone looking to hire a developer (more on hiring developers in a later post).  There are 3 things I look for when hiring a developer:

  1. Knowledge
  2. References
  3. Location


Being a client and a contractor myself, I know how to tell when a developer is actually knowledgable about a language or technique.  Here’s one question I ALWAYS ask: “How would you implement (say basic feature of your application here)?”  If the developer doesn’t have a good answer right away and the feature is actually simple, chances are they aren’t the right developer for you.


It’s even more important than ever to talk with the developer’s past employers or clients before hiring him when you plan on learning from the developer.  When talking with the past client, be sure to ask about communication.  If you want to learn from someone, they must have good communication skills.  Also, be sure they are good at programming, use good practices and can explain why good practices are good.


You will want to hire someone in a similar time zone.  Having to talk with your contractor at 3am isn’t fun.  Enough said.

Things to clarify with the developer

This section will be pretty short.  All I have to say is be sure the developer knows you want to learn and be sure they understand you want them to constantly push code to some sort of version control system constantly so you can see what they are doing.


Skype (or some other IM software) will be your best friend.  If you ever have a question, just chat your contractor.  Most of the time, even if it’s very hard for you to figure something out, your dev will be able to figure it out easily.


This post has been a bit random and jumped around a bit; however, the main idea is the best way to learn a programming language, is to learn from a good developer.

Screen Shot 2013-03-20 at 11.47.18 AM
February 14, 2013

Using Pull Requests To Keep Code Safe

One thing you should always do when your app is in production is have another person check your code before it is pushed.  I was looking online for workflows and instructions on how to do this and they were all really vague or were written for contributing to big projects.  In this post, I will go over how I like to use pull requests


Before I create a new branch to put my new code or feature in, I always check to be sure someone else hasn’t already created a branch for it.  Once you have done that, you’re ready to start :)

Creating a Branch

Ok, so now you know no one is working on your code or feature yet, it’s time to create a new branch.  When it comes to naming your branch, I like to make the name a few words that describe the branch separated by underscores.  For example, if the branch added a 2 factor authentication, I would call the branch “two_factor_auth”.  Once you have a name, here’s what to do:

  1. Pull most recent code from master by running git pull origin master
  2. Create and checkout a new branch by running git checkout -b name_of_your_branch(Thanks Dorian Patterson for that tip)
  3. Ok, now you have a branch it’s time to make your changes.  Add, delete and modify everything you need to to make your feature/bug fix/random code complete.

Pushing the Code to Your Branch

  1. Run index commands just like you were pushing to master (ex. git add git rm)
  2. Now commit the code just like you would on master (ex. git commit -m "message_here"). Be sure your commit messages are useful and describes what you did.
  3. Next push your code. This is where you do something a bit different. Rather than just running git push, run git push origin name_of_your_branch

Create the Actual Pull Request on GitHub

  1. Goto your repository on GitHub.
  2. Goto the branch drop-down menu
  3. Choose the branch you created with your code
  4. Click “Pull Request”
  5. Enter a useful title and message that describes exactly what you did
    Photo from
  6. Now your pull request will show up in the pull requests tab.  Have someone else checkout your branch and test it works.  Once they confirm it works, have them click the merge button.


Hopefully pull requests help you as much as they helped me and will help remove bugs from your code.

Older Posts