One Man Army Guide of App Development

App development is a task that involves several roles, product managers, UX, UI, IxD, Developers, Testers, etc. But once in a while you have to wear the cap for more than one role. This guide is for the times when you have to be the one man army either because a team member left or budget constraints.

Recently I was contacted by Expensify to start a recruitment process, the first step in the process was to build a mobile app with minor functionality (they already have an app and is amazing, with functionality like scanning receipts that automatically fill the expense info). I’m going to describe the process I followed to solve the challenge.

DISCLAIMER: I DO NOT CLAIM any relation with Expensify by any mean, this guide is solely for education purposes. All logos are Expensify Copyright.

Three years ago I read about Goal Directed-Design a methodology to focus on user goals and how the software should adapt to those, learning and responding as it’s used. I thought it was the best approach I have ever seen, many times in the past I wrote software for the stake holders not for the people that was going to use it, as you may guess, I had to rewrite software more than once. After all, the software is a tool to solve a problem not a goal per se. I will follow this methodology.

Define intent and constraint of a project.

The first thing to do is understand the context and which is the problem you are hired to solve.

Expensify is about managing, register expenses, make reimburse reports, etc. I must understand first what they do and how they do it, I read about the problems associated to managing expenses. Some of my findings were (among many):

  1. Every company has it’s own expense policies.
  2. For employees is hard to track expenses because you have to keep receipts and make a spreadsheet for management (with dates, merchants, amounts).
  3. Receipts and dates are very important.
  4. Employees could submit expenses non related to the work, overcharge for a service or duplicate expenses.
  5. Business has to approve the spreadsheets, for small companies this may not be a problem, but when you have to approve for more than 20 employees this becomes a nightmare.

We could deduce that the problem to solve is #2 how to simplify the process of tracking expenses in a business trip. Why during a trip?, because is easier to track things as happens instead of waiting at the end of the trip when you may have losen receipts.

And maybe that’s why they asked to build an app with the following functionality:

  • Login.
  • Register an expense.
  • List current expenses.

Now we have to find out who will use our product. We are tempted to say that everybody, but if you say you are solving a problem to everybody then you are not solving a problem to anybody at all, find who will be your users and you will get the info to provide a suitable solution. You must understand whom are the persons you are solving their problems.

Define typical users.

After some research I find out that users are consultants and sales people, the average consultant age is from 28-40 and for sales people is 35-45, with at least one business trip every week.

Now that you know your audience you have to create your “Personas”, Personas are fictional people representing specific groups of your target audience.

The purpose of creating personas that represents your target audience it’s because is easier to talk about an imaginary person, than is to talk about a “market segment”, also help you focus your product and empathize with them.

Deduce what user needs.

For this guide I will make two personas, one for each user segment.


Image courtesy of stockimages at
Jacob Colin
30 years old.
Location. NYC
Job. IT Solutions Consultant at a Cloud Computing Company
Has a good level of knowledge of computers and smartphones.
Would like to be able to spend less time making the expenses report after each business trip. He would like to add expenses as he pays for services.

Jacob studied a BS in Computer Science at Carnegie Mellon University, since he was young he was skilled in programming, after he graduates he got an internship at a cloud computing Company, he also likes to write a blog about technical challenges in cloud computing.

He quickly became the company’s star because of his ability to solve problems quickly, he is the one that his company send to its customer when they need help.

When he is not traveling in the country or abroad he likes to go to the movies and jazz concerts.

He does at least one business travel each week, 50% of the time is near NYC, 40% is within mainland USA and only 10% is abroad. After returning he needs to deal with several customer reports, expense reimburse and prepare the next travel. He is methodic and keeps his receipts in a special bag (so he doesn’t loose them), but as he needs to focus on providing solutions to the company’s customers, he would like to spend more time doing it than in reimburse expense reports.

Image courtesy of stockimages at
Emilia Jorie
35 years old.
Location. San Francisco
Job. Sales representative at a Startup.
Good user-level knowledge of computers and smartphones.
Would like to keep track of her expenses during a business trip, to avoid reviewing later. Would like to be aware of which expenses are reimbursable.

Emilia is a sales representative at a video streaming startup in Silicon Valley, California. She received her B.S from UCLA.

She knows that the startup environment is really demanding, so many tasks to do, and things grows really fast, she is traveling half a time all over the country and closing huge deals.

Besides sales she enjoys biking with her kids, she is part of a bike team that goes out each weekend.


Personas are useful because you focus on the product and became empathetic with them, instead of talking to “customers” you will end up thinking how this aligns to Emilia goals.

For creating personas you could use:
Create random names
Select a picture

Now is time to design something that satisfies Emilia and Jacob goals and aligns to Expensify business model. We know that Expensify users are consultants and sales people, they are between 28-45 years old, for them, tracking expenses are boring and tedious, they need an easy way to register expenses while in a trip and be able to review (so they don’t spend time when they return form a trip).

Tell stories about using the system.

Let’s think how our personas are going to use our app.
Use case: Register a cab expense.
I have created this storyboard (please do in paper, is easier and you don’t have to spend too much time creating “nice” drawings).


  1. Emilia is in a taxi cab going back to her hotel after a meeting.
  2. She grabs her phone and opens the app because she needs to review the expenses in order to know how much money she could expense for a dinner without getting over her daily expense restriction.
  3. The app shows her the expenses list, with the ones for today atop the app.
  4. While she is reviewing the expenses, the taxi driver interrupts her because they arrive to the hotel and informs her how much money is for the ride.
  5. While the driver is charging her card, she adds a new expense.
  6. She register the info and adds a new expense to the list. End.



Finding some inspiration.

Once I have imagined how our users will use the app, I must figure out the UI design that fits the needs, for doing so also I would find some inspiration:

Login screen inspiration. what I like about this is that you have someone in the background riding a bike in a sunny day with the logo in the middle for me evoked a feeling of joy.

The colors in this scheme are bright and joyful, I don’t want to be too serious but some color will evoke feelings in the users, maybe something cool even tho is a boring task.

List view inspiration. Something that I wanted to highlight was the amount and the day so you can see at a glance how much you spend.

UI Design.

Create a mockup with your thoughts FIRST! then sit in front of a computer and work with Sketch App (or whatever you feel comfortable).

I decided to focus the design in a person that is happy doing the expense reports and add some bright colors to avoid being too formal and add some fun. The copy text is also a little bit informal, like if it was a friend who was giving you advice. I selected Sans Serifs for readability and clearness. Lato for most of the text, Roboto for Merchant label and Museo Sans because I like how the numbers looks :D (all free to use).

Login In this screen I highlighted Expensify moto, telling the user that this is going to be fun, I used an image of a smiling business woman, no too formal dressed, looking at her phone like reviewing her expenses.
Expenses This screen highlights the amount (to keep track of limits), the merchant (to know where it was), the date background is in grey because this expense is not categorized (I think this is important for companies) if you add a category you see a blue background (the brighter color may cause the users to add the categories because looks good). I used a layout to evoke a “ticket”.
Add_Expense This screen is minimum to avoid distracting the user, from an expense point of view what you need? my hypothesis is Merchant, Amount, Comment and Date (and the image of the expense).

We could create several prototypes and try to focus on specific actions that align to “personas” goals. Everything else is irrelevant, we would need delete or modify but for now the goals are only track and register.

Download Sketch app Design File.

Interaction Design.

Once we have our UI the next step is create the interaction concept. A static prototype won’t provide too much context about how the app will behave, using Quartz Composer and Facebook Origami we create a prototype really quickly, as writing this post, Facebook released a new version of Origami with some cool features such as Phone preview, animation export and better integration with Sketchapp.

Creating interaction prototypes is faster and cheaper than coding.
Download Quartz Composer File.


Building an app involves several people, but is not impossible to make one only with yourself. Follow a method and adjust it to your needs. To solve the challenge I used Goal Directed-Design with the following process steps:

Define intent and constraint of a project: Before doing anything you need to know the purpose and the environment in which you will solve a problem.
Define typical users: Who will be using your product.
Deduce what user needs: If is a consumer product, make assumptions and refine as you learn.
Tell stories about using the system: Imagine the situations in which users will use your product.

For UI/UX align with your goals and find some inspiration that helps you fulfil it (but don’t be a copycat). Iterate, you will always have an opportunity to improve the final product.

This is the first part, now that we have defined the problem, a solution and the Interface/Interaction let’s build the app, but that will be my next post.

I have the rights to use for the images used in Sketchapp, please DO NOT use them in your projects.

Further Reading.

Designing For the Digital Age by Kim Goldwin.
Designed for Use by Lukas Mathis
Designing for Emotion by Aarron Walter
Type Matters! by Jim Williams
Layout Workbook by Kristin Cullen
100 Things Every Designer Needs to Know about People by Susan M. Weinschenk
Learn Facebook’s Origami interaction design tool
How to use Sketchapp

Introduction to LLDB Python scripting.

One of the most unknown features of LLDB is that you could extend it’s functionality using Python. LLDB comes with a Python Library you can use through a script bridge interface, wether you call it from lldb command line or add debugging functionality to a Python program.

But why learn to write LLDB Python scripts? after all we could set a breakpoint, inspect data using preview or po command, right?, when comes to debugging, nothing is sufficient and writing your own commands to debug issues in your project will save you time and improve code’s quality. Also you can share scripts to your development team, so all get benefits from a common debugging library.

Suppose you are hired to maintain an existing app, as is usual, you will be provided with the architecture document, class diagrams, user stories or all you need to understand what is going on (please note the sarcasm). A quick look to the project shows you it uses the widely spread Spaghetti Architecture, where you have two or more components doing the same, not clear path to navigate trough the app and you get the sense this will be a nightmare to maintain. Can set tons of breakpoints or you could write a LLDB python script to print the execution’s frame trace to understand what’s going on.

For this blog post I used:

  1. OS X 10.9.2
  2. Xcode 5.1.1
  3. Python 2.7
  4. LLDBTest project

Defining the function.

1. Import the LLDB Python bridge library and define the function.

import lldb 

def command_name(debugger, command, result, internal_dict): 

Parameter description:

debugger: Is the primordial object that creates targets and provides access to them. It also manages the overall debugging experiences.

command:A python string containing all arguments for your command.

result: Represents a container which holds the result from command execution. It works with SBCommandInterpreter.HandleCommand() to encapsulate the result of command execution.

internal_dict: The dictionary for the current embedded script session which contains all variables and functions.

2. Add the code to print the frame trace:

def print_frame(debugger, command, result, internal_dict):
    target = debugger.GetSelectedTarget()
    process = target.GetProcess()
    thread = process.GetSelectedThread()

    for frame in thread:
            print >>result, str(frame)

3. Define how should be used as LLDB command:

def __lldb_init_module(debugger, internal_dict):  
debugger.HandleCommand('command script add -f print_command.print_frame print_frame')  
print 'The "print_frame" python command has been installed and is ready for use.'  

Import description:

command script add -f: LLDB command to import a script.

print_command: file name

print_frame: function name

print_frame: how we will invoke the function in Xcode

4. Save this file as

Importing the command into Xcode.

I have stored my LLDB scripts in ~/lldb folder.

NOTE: Do this every time you start the debugger:
(lldb) command script import ~/lldb/
The "print_frame" python command has been installed and is ready for use.

To print the stack frame every time viewDidload selector is fired:

(lldb) br s -S viewDidLoad  
Breakpoint 3: 18 locations.  

Add our Python LLDB command to breakpoint “3”:

(lldb) br command add 3  
Enter your debugger command(s).  Type 'DONE' to end.  
> print_frame  
> DONE  


Download print_command file.
Import print command.

Adding parameters to the script.

While this is simple, is not quite useful as we will print all frame trace, no matter the class invoked, let’s modify our script to pass a parameter for filtering.

1. Add support libraries:

import commands
import optparse
import shlex

2. Add a command parser function:

    def create_print_frame_options():
        usage = "usage: %prog [options]"
    description='''This command uses two parameters to filter frame printing.
    parser = optparse.OptionParser(description=description, prog='print_frame',usage=usage)
    parser.add_option('-p', '--prefix', type='string', dest='prefix', help='Class prefix to filter.')
    parser.add_option('-m', '--message', type='string', dest='message', help='Message to print at the begining.')

    return parser

Options description:

-p: single char parameter flag.

--prefix: parameter flag description.

type: python variable type.

dest: variable name in python.

help: message to display in help command.

3. Modify print_frame function, add:

command_args = shlex.split(command)
parser = create_print_frame_options()

    (options, args) = parser.parse_args(command_args)

    # if you don't handle exceptions, passing an incorrect argument to the OptionParser will cause LLDB to exit
    result.SetError ("option parsing failed")

if options.message:
    print >>result, "************************** Tracing: %s %s" % (options.message," **************************")

if options.prefix:
  for frame in thread:
    if str(frame.GetFunctionName()).find(options.prefix) != -1:
      print >>result, str(frame)

  for frame in thread:
    print >>result, str(frame)

4. Save the file as, don’t forget to modify __lldb_init_module with the new function file.

5. In Xcode hit a breakpoint and import the new command:

(lldb) command script import ~/lldb/
The "print_frame" python command has been installed and is ready for use.

To print the filtered stack frame every time viewDidload selector is fired:

(lldb) br s -S viewDidLoad
Breakpoint 3: 18 locations.

Add our modified Python LLDB command to breakpoint “3”:

(lldb) br command add 3  
Enter your debugger command(s).  Type 'DONE' to end.  
> print_frame -p FG -m viewDidLoad  
> DONE  

Navigate the app, you will stop each time viewDidLoad gets fired and get the frame trace.


Download print_command_options file.

Importing print command with options.

If you have doubts about how to use LLDB commands, please read my previous post Introduction to iOS Debugging With LLDB.

To definitively import the command into Xcode, create or modify a file called ~/.lldbinit, add this line:
command script import ~/lldb/

LLDB Python scripts is an excellent tool to extend debugging capabilities to your project, found bugs faster and improve code’s quality. Now you know the basis of how to create your own scripts.

Further Learning.

Facebook has released chisel a collection of useful LLDB Python scripts.

RealMac’s Software how to disassemble a block in LLDB.

LLDB’s official python scripts examples.

Python optparse tutorial.

Introduction to iOS Debugging with LLDB.

Being a developer means that many times a day you will end up debugging code, wether is yours or someone else’s. According to this research, we spend 25% of time fixing bugs and 25% making code works, at the end, we spend 50% of our time debugging. But sometimes I found myself spending whole day trying to catch a pesky bug or getting along a new project. More often you will have to debug spaghetti code.

Fortunately Xcode comes with amazing tools to make this task easier: LLDB & Instruments.

LLDB is the default debugger in Xcode (used to be GDB), comes with handy commands, also you can write your own debugging scripts using python and extend it’s functionality.

To help you understand this post I made a test project in github. I’m using Xcode Version 5.1.1 (5B1008).

Start Using LLDB.

Add a breakpoint to FGAppDelegate.

App Delegate breakpoint

Run your app.

Navigate until you reach the breakpoint, you will see the LLDB console.

LLDB Console


Print object values.

The command “po” evaluates C/ObjC/C++ expressions in the current program content, using defined variables and variables that are currently in scope. Which means that you will access solely the variables from the current class.

Add a breakpoint in FGViewController.m:40

Breakpoint in class FGViewController

Run the app.
When you hit the breakpoint type:

(lldb) po _person

You will get: nil (because is not yet initialised, press F6 to continue)

(lldb) po _person
<FGPerson:0xc7762c0, ID:0 Name:John Doe>

po is useful to print objects, but if you need to print scalar values use (personID is an int property):

(lldb) p _person.personID
(int) $2 = 0

Also you can use self:

(lldb)po self.view
<UIView: 0xa08c030; frame = (0 0; 320 568); autoresize = RM+BM; layer = <CALayer: 0xa08c090>>

LLDB Console:

po & p commands

NOTE: You can print all the view elements in current view using:
(lldb) po [[[UIApp delegate] window] recursiveDescription]


Remove previous breakpoint by right click at breakpoint->Delete

Add breakpoints

Add a breakpoint to a class and code line:

(lldb) b FGViewController.m:40

“Breakpoint 2:” = the id for the breakpoint, with this id you can add commands, delete, enable or modify a breakpoint.

Command Options (for more options type “help br” on LLDB prompt):

 s: Sets a breakpoint or set of breakpoints in the executable.
-n: Set the breakpoint by function name.
-S: Set the breakpoint by ObjC selector name.

Add a breakpoint to a class and selector without parameters:

(lldb) br s -n "-[FGViewController setLabels]"

Add a breakpoint to a class and selector with parameters:

(lldb) br s -n "-[FGViewController addPersonHandler:]"

Add a breakpoint to a selector no matter the class:

(lldb) br s -S viewDidLoad

List all current breakpoints; added from LLDB or Xcode:

(lldb) br list

LLDB Console:

Break point command console.


NOTE: All breakpoints added through LLDB will never be reflected in Xcode, if you want to create a Symbolic breakpoint that gets reflected in Debugging tab, then follow this.
  1. Open the Breakpoint Navigator
  2. Click on + button
  3. Add Symbolic Breakpoint
  4. In Symbol text box write: -[FGViewController setLabels]
  5. Uncheck “Automatically continue after evaluating”.


Also you can read more about Xcode breakpoints in the post Xcode Breakpoint Wizardry from Big Nerd Ranch.

Conditional breakpoint

(lldb) b FGResizeViewController.m:53
Breakpoint 2: where = LLDBTest`-[FGResizeViewController resizeSquare:] + 198 at FGResizeViewController.m:53, address = 0x000029d6
(lldb) br mod -c "currentFrame.size.width > 200" 2

Adding a script to a breakpoint

For python scripts you have available these variables:

frame:  a lldb.SBFrame object for the frame which hit breakpoint.
bp_loc: a lldb.SBBreakpointLocation object that represents the breakpoint location that was hit.
dict:   the python session dictionary hit.

Adding a single line Python script that will print the current method for the breakpoint, this is really useful when you get into a new project and you want to trace where you’re passing while using the app:

(lldb) br s -S viewDidLoad
Breakpoint 2: 18 locations.
(lldb) br command add -s python 2 -o "function_name = frame.GetFunctionName(); print '%s' % function_name"

Adding a LLDB script:

(lldb) br command add -s command 2
Enter your debugger command(s). Type 'DONE' to end.
> frame info
frame #0: 0x0034bea5 UIKit`-[UIViewController viewDidLoad]

Debugging is one of the main developer’s activities, using the right tools provided by Xcode will help you easy this often tedious task. Now you know how to inspect data without adding NSLogs to your class files and most important, without stopping the app, which will save you a lot of time. Breakpoints are a powerful feature that you can use to stop conditionally  or print more info about what is going on.

In LLDB type

(lldb) help

for more info about all commands available.

Further Reading.

Apple’s official LLDB quick start guide.

LLDB Tutorial.

Getting Started with LLDB from Apple Developer.