Choosing The Best Mobile App Development Technology

There are many different reasons to create an app: maybe you see a need for a business app, maybe you just have a great idea. But regardless of the reason, you still have to start at the beginning. In recent posts, I’ve addressed the most common questions about getting your app off the ground:

The next step in the process is to understand a bit about the technology choices involved, so you can be more informed when you discuss the options with your mobile app developer.

What are your options when it comes to mobile app development technology? First you have to decide what type of app works best for you: native, hybrid or web.

Native mobile apps

Native mobile apps are likely what come to mind when you think of apps. A native app is one that is developed to be ‘native’ to a specific platform: Apple’s iOS, Google’s Android, Windows Phone or (decreasingly) BlackBerry OS.

The principal advantage of a native app is that it optimizes the user experience; the app will operate more quickly because it’s been designed specifically for that platform.

The principal disadvantage? If you wish to build and launch your app on more than one platform (e.g. a chat messenger) you almost need to start each one from scratch. Let’s look at each platform more closely.

If building for Apple’s iOS, your developer will need to use the Objective-C language—one of the hardest programming languages to master, even for professionals with experience. The good news is that Apple provides its developer community with very good tools. The main one, Xcode, is the tool your developer will use to create your native app.

Building for Android requires Java. Java is a more common language than Objective-C and has less of a learning curve, so it’s not as challenging to find proven developers. However, the tools available to create apps for Android—including the most popular tool, Eclipse—aren’t as good as Xcode; but a new tool called Android Studio could eventually deliver the same quality of development support as Apple’s tool.

Windows Phone, while still more popular than BlackBerry, is back in third place. However, it’s strongly supported by Microsoft and is particularly worth considering if building an enterprise app. Apps for Windows Phone are made using the C# or VB.NET languages. Microsoft’s Visual Studio is a great tool for building an app—it’s probably the most developer-friendly of the three main platforms.

Tip: If a native app is the best option for you, make sure the developer you hire has proven experience specifically in the language(s) you need, not simply experience with programming.

Hybrid mobile apps

What makes an app a hybrid? A hybrid app can be installed on a device like a native app can, but it runs via a web browser. These apps are built using a language called HTML5.

In 2012, HTML5 appeared to be the future of mobile; leading companies like Facebook, LinkedIn and Xero had jumped in and it was getting a lot of attention. The last year, however, has seen many of these companies ditch their existing HTML5 apps and start again with native apps.

The reasons for this are simple—these hybrid apps are not as fast, reliable or smooth as native apps.

Despite these challenges, the debate continues. The potential for HTML5 is certainly enormous as there’s a definite benefit in not having to build and maintain apps for separate native platforms, an endeavor that involves significantly more time and resources. Facebook, for example, employs 300 designers and developers on its iOS team and 300 on its Android team.

So when is hybrid still a good option? If your app will primarily deliver content, and if it’s important to the business outcome for the app to be cross-platform, you should still consider it.

Web apps

There are actually three types of web apps: traditional, responsive and adaptive.

Traditional web apps include any website. But what are responsive and adaptive web apps?

A responsive web app takes on a different design when it’s opened on a mobile device (i.e. phone or tablet), altering its design to suit the device it is viewed on.

A ready example of a responsive web app is the oDesk blog. Below, you can see the tablet view on the left and the mobile view on the right.

oDesk Blog: Tablet view
oDesk Blog: Mobile view

An adaptive web app, in contrast, doesn’t change its design. It will display the same design, but will adjust it to fit the different screen size of a mobile device.

The biggest benefit of web apps is that they are built using the most popular programming languages—so developer talent is readily available. However, a responsive web app has two principal drawbacks:

  • It can’t use any hardware on a device (i.e. an iPhone’s camera)
  • Its “discoverability” will be reduced because it won’t be in any app stores.

To learn more about the app creation process, AppInstruct’s online course explains the technical elements of mobile app development in greater depth.

Introduction to Appium’s Philosophy, Design and Concepts

Appium is an open-source tool you can use to automate mobile native, mobile web, and mobile hybrid applications on iOS and Android platforms. “Mobile native apps” are those written using the iOS or Android SDKs. “Mobile web apps” are web apps accessed using a mobile browser (Appium supports Safari on iOS and Chrome on Android). “Mobile hybrid apps” have a native wrapper around a “webview” — a native control that enables interaction with web content. Projects like Phonegap, for example, make it easy to build apps using web technologies that are then bundled into a native wrapper — these are hybrid apps.

Importantly, Appium is “cross-platform”: it allows you to write tests against multiple platforms (iOS, Android), using the same API. This enables a large or total amount of code reuse between iOS and Android testsuites.

For specific information about what it means for Appium to “support” its platforms, version, and automation modalities, please see the platform support doc.

Appium Philosophy

Appium was designed to meet mobile automation needs according to a certain philosophy. The key points of this philosophy can be stated as 4 requirements:

  1. You shouldn’t have to recompile your app or modify it in any way in order to automate it.
  2. You shouldn’t be locked into a specific language or framework to write and run your tests.
  3. A mobile automation framework shouldn’t reinvent the wheel when it comes to automation APIs.
  4. A mobile automation framework should be open source, in spirit and practice as well as in name!

Appium Design

So how does the structure of the Appium project live out this philosophy? We meet requirement #1 by using vendor-provided automation frameworks under the hood. That way, we don’t need to compile in any Appium-specific or third-party code or frameworks to your app. This means you’re testing the same app you’re shipping. The vendor-provided frameworks we use are:

We meet requirement #2 by wrapping the vendor-provided frameworks in one API, the WebDriver API. WebDriver (aka “Selenium WebDriver”) specifies a client-server protocol (known as the JSON Wire Protocol). Given this client-server architecture, a client written in any language can be used to send the appropriate HTTP requests to the server. There are already clients written in every popular programming language. This also means that you’re free to use whatever test runner and test framework you want; the client libraries are simply HTTP clients and can be mixed into your code any way you please. In other words, Appium & WebDriver clients are not technically “test frameworks” — they are “automation libraries”. You can manage your test environment any way you like!

We meet requirement #3 in the same way: WebDriver has become the de facto standard for automating web browsers, and is a W3C Working Draft. Why do something totally different for mobile? Instead we have extended the protocol with extra API methods useful for mobile automation.

It should be obvious that requirement #4 is a given — you’re reading this because Appium is open source.

Appium Concepts

Client/Server Architecture
Appium is at its heart a webserver that exposes a REST API. It receives connections from a client, listens for commands, executes those commands on a mobile device, and responds with an HTTP response representing the result of the command execution. The fact that we have a client/server architecture opens up a lot of possibilities: we can write our test code in any language that has a client. We can put the server on a different machine than our tests are running on. We can write test code and rely on a cloud service like Sauce Labs to receive and interpret the commands.

Automation is always performed in the context of a session. Clients initiate a session with a server in ways specific to each library, but they all end up sending a POST /session request to the server, with a JSON object called the ‘desired capabilities’ object. At this point the server will start up the automation session and respond with a session ID which can be used in sending further commands.

Desired Capabilities
Desired capabilities are sets of keys and values (i.e., a map or hash) sent to the Appium server to tell the server what kind of automation session we’re interested in starting up. There are also various capabilities which can modify the behavior of the server during automation. For example, we might set the platformName capability to iOS to tell Appium that we want an iOS session, rather than an Android one. Or we might set the safariAllowPopups capability to true in order to ensure that, during a Safari automation session, we’re allowed to use JavaScript to open up new windows. See the capabilities doc for the complete list of capabilities available for Appium.

Appium Server
Appium is a server written in Node.js. It can be built and installed from source or directly from NPM.

Appium Clients
There are client libraries (in Java, Ruby, Python, PHP, JavaScript, and C#) which support Appium’s extensions to the WebDriver protocol. When using Appium, you want to use these client libraries instead of your regular WebDriver client. You can view the full list of libraries here., Appium.exe
There exist GUI wrappers around the Appium server that can be downloaded. These come bundled with everything required to run the Appium server, so you don’t need to worry about Node. They also come with an Inspector, which enables you to check out the hierarchy of your app. This can come in very handy when writing tests!

Getting Started

Congratulations! You are now armed with enough knowledge to begin using Appium. Why not head back to the getting started doc for more detailed requirements and instructions?

AppThwack – Automated testing of iOS and Android apps on real devices in the cloud

AppThwack maintains a remote device lab of hundreds of iOS and Android devices and an automation infrastructure that allows you to run automated test scripts in parallel on real devices, not emulators. AppThwack supports all popular automation frameworks. With AppThwack, you can

  • Execute your tests, in parallel, across 100s of iOS and Android phones and tablets with results available in minutes
  • Initiate tests through a simple web interface or Jenkins Plug-in
  • View results in web-based dashboard or download for offline viewing
  • Analyze reports in real-time that include high-level results, low-level logs, pixel-perfect screenshots, and performance trends (CPU, Memory, Threads, Frame draw time)
  • Integrate report data with CI and other business flow applications

AppThwack offers a free 7-day trial period. Start testing with AppThwack today!

10 Most-Useful Mobile App Testing Tools For Application Developers 2014

For the application developers, it is always recommended to use real world testing instead of simulators and emulators. Actually, most of the companies first test their applications on the desktop browser, and then search for bugs related to a device. If done in a right manner, your testing time and effort can be reduced significantly. At times, small-time developers may wish to make use of mobile app testing tools instead of devoting in an entire lab.

In this article, we will discuss top 10 Mobile App Testing tools which assist in achieving the goals of mobile testing.

1. FoneMonkey 5

This tool is used to record every action with the iPad or iPhone. It plays the action back as a test script at any time. This tool allows interactive creation, editing as well as playback of automation scripts that implements the user interface of an application.

2. iPhoney

iPhoney is considered as a web-browsing environment which is designed for web developers who wish to generate 320 by 480 (or 480 by 320) websites for use with iPhone. iPhoney is powered by Safari. It provides a canvas on which you can test the design’s visual quality.

3. W3C mobileOK Checker

This application assists developers in assessing how mobile-friendly an app actually is. This checker implements numerous tests on a Web Page in order to find out its level of mobile-friendliness. A Web Page is said to be mobileOK if it passes every test.

4. Modify Headers

This tool is helpful for Mobile web development, HTTP testing and privacy. By means of this tool, app developers can verify HTTP privacy and test the efficiency. Also, the use of this add-on improves mobile web development.

5. DotMobi Emulator

The use of this tool allows developers to verify if a particular website appears on a mobile web browser in a correct manner. This tool also includes an additional support which can be sought from the homepage.

6. Google Android Emulator

This tool is considered as a mobile device emulator that helps developers to test as well as generate Android applications without making use of a physical device. The Android SDK assists developers to avoid the purchase of every Android device that is available in the market.

7. Android SDK Emulator

This tool offers developers with API libraries as well as tools that are required to test, build and debug applications. The use of this tool helps developers to begin developing apps in a rapid manner.

8. iPad Peek

This tool can be utilized to see the appearance of a website on an iPad. This useful tool reminds developers that good appearance of an iPhone does not necessarily look good on an iPad. Here, it is required to consider your web-design skills.

9. BlackBerry Simulator

Blackberry simulator allows you to view, test and debug your applications. Nevertheless, most of the people do not wish to generate applications for this platform anymore. People who are particularly interested in the blackberry platform, such as security agencies, require the use of this platform.

10. Apphance and Appgrader

Apphance is a mobile tool that helps developers to distribute applications over-the-air, gather and report crash data automatically. It also features in-app bug reports and user feedback. A tool for Android, known as Appgrader, has been launched which appears to be quite promising.

How to Get Navigation Directions (Even Offline) Without Buying a GPS

Dedicated GPS devices are going the way of the dodo, and for good reason. That smartphone or tablet you have can be a capable GPS with turn-by-turn navigation. This works even if you don’t have a data connection.

Find a way to mount your smartphone or tablet in your car and it can even make a capable in-car GPS solution. This is illegal in some jurisdictions, so check your local laws before mounting anything.

If You Have Mobile Data…

Using a smartphone or tablet as a GPS is very easy if you have mobile data. Google Maps, Apple Maps, and even Nokia’s HERE Maps are capable map apps with turn-by-turn navigation directions. If you have data access, these solutions are better than a dedicated GPS device in many ways. You get a more user-friendly interface, up-to-date search results from the web, links to open websites in your browsers, and real-time traffic data. Some services will even route you around bad traffic on the fly.

On Android, use the Google Maps app to search for directions to your destination. Tap the Start navigation button and you’ll be taken to a GPS navigation-style experience with spoken, turn-by-turn directions.

On an iPhone or iPad, you can also install the Google Maps app and use it in a similar way. You can also use the Apple Maps app included with your device. Tap Directions in Apple Maps to get directions to a location, tap the Route option to view the route, and tap Start. Apple Maps will display turn-by-turn directions.

Windows Phone users can use Nokia’s HERE Maps to get turn-by-turn directions in a similar way.

Offline Turn-By-Turn Navigation

This all works great if you’re paying for mobile data, but you can use your device as a GPS navigation solution even if you don’t have mobile data access.

Dedicated GPS devices include a GPS receiver and an offline map database they can use to display your location, provide directions, and allow you to search for locations. Your modern smartphone or tablet also has a GPS chip so it can determine its location offline — all you need is an app that will provide offline map data and navigation directions.

Google Maps allows you to download map data and view it offline. To do so, zoom to the area you want to cache in Google Maps and type “OK maps” into the search box. You can then open Google Maps and see where you are on the map — the map will work fine even when you’re offline. Unfortunately, Google Maps doesn’t provide a way to get navigation directions offline. You can search for navigation directions before you leave Wi-Fi and continue using the cached navigation directions to get to your destination, but that’s it.

If you’re looking for a free offline GPS navigation app for Android , try Osmand or Navfree. If you’d like something more full-featured and polished, you may want to buy a paid app likeSygic or one of the many other offline navigation apps in Google Play. Sure, they cost money — but they’re cheaper than buying a dedicated GPS device and having to pay for map updates.

On iPhone or iPad, you can use Google Maps to save offline map data in the same way, but it still won’t provide offline navigation. Apple Maps doesn’t provide offline navigation instructions, either. You’ll find a variety of offline navigation apps in the app store, like the paid Sygic and CoPilot GPS.

On Windows Phone, Nokia’s HERE Maps allows you to cache maps for offline use and even get navigation directions offline.

Note that you can’t use an iPod Touch as an offline GPS device. Apple’s iPod Touch doesn’t include GPS hardware, so it can’t use GPS to figure out where it is.

How to remotely install apps on your smartphone

You can download and install apps to your iPhone and Android phone without being anywhere near it. That sorcery is this? It isn’t sorcery. It’s the internet. And it takes almost no effort to set up.

On Android

If you have an Android phone, you can quickly and easily remotely install apps to your phone without having to tinker with any settings. Visit the Google Play store from your computer and log in using the Google account that’s associated with your phone. Next, find the app that you want to install and go to its information page, then press the Install button for that app.

Select the device you want to install the app on, then press Install.

Once you click Install, you’ll be presented with a box that tells you which permissions the app needs (whether it needs to access your contacts or connect to the Internet, for instance), as well as a drop-down list of the devices associated with your Google account. Select the phone or tablet you want to install the app on from this list, then press Install. After a few moments, your phone will begin installing the app.

Pretty easy, right? You betcha.

On iOS

Toggle this switch…

iOS 7 comes with a similar feature, but you need to make sure it’s switched on first. To check, open the Settings app, scroll down, then tap iTunes & App Store. From here, look for the Automatic Downloads section, then toggle the Apps slider to the on position (the toggle switch will turn green). If you want to have updates downloaded to your phone automatically, switch the Updates toggle to the on position as well.

…then download your app. It will appear on your iPhone’s homescreen a few moments after you purchase it on your computer.

Next, open iTunes on your Mac or PC, then go to the iTunes Store, and sign in using the Apple ID associated with your phone. Go to the App Store, then find an app you want to download. Press the Download buttom—it will be labelled with the app’s price—and after a few moments it will be downloaded to both your computer and your phone.

On Windows Phone 8

Setting up your Windows phone for remote app installation is similar to the process for iOS. Start by going to the Settings app on your phone and then select Find My Phone from the list. Next, look for the checkbox labelled Send apps to my phone using push notifications (not SMS) and tap it if it isn’t checked already.

Now go to the Windows Phone store, then mouse over Explore My Phone in the upper-right corner and sign in with the Microsoft account associated with your phone. Find the app you want to install, and press the Buy or Install button (which button label you see will depend on whether the the app is paid or free).

Once you do that, the Windows Phone store will pick your default device and install that app to it after a few moments.

Four Ways To Build A Mobile Application, Part 1: Native iOS

The mobile application development landscape is filled with many ways to build a mobile app. Among the most popular are:

  • native iOS,
  • native Android,
  • PhoneGap,
  • Appcelerator Titanium.

This article marks the start of a series of four articles covering the technologies above. The series will provide an overview of how to build a simple mobile application using each of these four approaches. Because few developers have had the opportunity to develop for mobile using a variety of tools, this series is intended to broaden your scope.

Hopefully, armed with this knowledge, you will be in a better position to choose the right development tools for your mobile application’s needs. In this first article in the series, we’ll start with some background and then dig into iOS.

I’ve built the same simple application with each technology to demonstrate the basic concepts of development and the differences between the platforms and development tools. The purpose of this series is not to convert you to a particular technology, but rather to provide some insight into how applications are created with these various tools, highlighting some of the common terms and concepts in each environment.

FasTip is a simple application to calculate tips. Because this is a simple example, it uses the standard UI controls of each platform:

The screenshots above show the application running as native iOSPhoneGapand native Android applications. Appcelerator Titanium uses native controls, so it looks the same as the native iOS and Android applications. Our application has two screens: a main screen where the tips are calculated, and a settings screen that enables the user to set a tip percentage. To keep things simple and straightforward, we’ll use the default styles of each environment.

The source code for each app is available on GitHub.

Native iOS Development

Most applications in Apple’s App Store are written in the Objective-C programming language, and developers typically use Xcode to develop their applications.


To build an iOS app, you must use Mac OS X; other operating systems are not supported. The development tools that you’ll need, iOS 7 SDK and Xcode 5, are free of charge, and you can run the app that you build in the iOS simulator, which is part of the iOS SDK. To run your app on a real device and make it available in Apple’s App Store, you must pay $99 per year.


Once you have installed Xcode, you’ll want to create a new project. Choose “Create a new Xcode project” from the welcome screen or via File → New Project in the menu.

For a simple application such as this one, “Single View” is appropriate. Upon clicking “Next,” you will be presented with a dialog to enter some basic information about your application:

The value that you enter in the “Class Prefix” option tells Xcode to attach that unique prefix to every class that you generate with Xcode. Because Objective-C does not support “namespacing,” as found in Java, attaching a unique prefix to your classes will avoid naming conflicts. The “Devices” setting lets you restrict your application to run only on an iPhone or an iPad; the “universal” option will enable the application to run on both.


The screen functionality of iOS applications is grouped into what are known asview controllers. Our application will have two view controllers: one for the main screen and one for the settings screen. A view controller contains the logic needed to interact with the controls on a screen. It also interacts with another component called the navigation controller, which in turn provides the mechanism for moving between view controllers. A navigation controller provides the navigation bar, which appears at the top of each screen. The view controllers are pushed onto a stack of views that are managed by the navigation controller as the user moves from screen to screen.


Starting with iOS 5, Xcode has had storyboards, which enable developers to quickly lay out a series of view controllers and define the content for each. Here’s our sample application in a storyboard:

The container on the left represents the navigation controller, which enables the user to move from screen to screen. The two objects on the right represent the two screens, or view controllers, that make up our app. The arrow leading from the main screen to the settings screen is referred to as a segue, and it indicates the transition from screen to screen. A new segue is created by selecting the button in the originating view and then, while the Control key is pressed, dragging the mouse to the destination view controller. Apple’s documentation provides more detail about this process.

In the example above, we can see that a text field has been selected, and the property panel is used to adjust the various attributes of the controls. When this application was created, the “universal” app option was selected, enabling the app to run on both an iPhone and iPad. As a result, two versions of the storyboard file have been created. When the app is running on an iPhone or iPod Touch, the _iPhone version of the file will be used, and the _iPad version will be used for iPads. This allows a different layout to be used for the iPad’s larger display. The view controller will automatically load the appropriate layout. Keep in mind that if your storyboards expose different sets of controls for the iPad and the iPhone, then you must account for this in the code for your view controller.

In addition to directly positioning items at particular coordinates on the screen,you can also use the Auto Layout system that was introduced in iOS 6. This enables you to define constraints in the relationships between controls in the view. The storyboard editor enables you to create and edit these constraints.

The constraints can also be manipulated programmatically. The Auto Layout mechanism is quite sophisticated and a bit daunting to use at first. Apple has anextensive guide on Auto Layout in its documentation.

Associating Storyboards With Your Code

To access the storyboard objects from the code, you must define the relationships between them. Connecting items from the storyboard to your code via Xcode is not obvious if you’re used to other development environments. Before you can do this, you must first create a view controller to hold these associations. This can be done with the following steps:

  1. Choose File → New File.
  2. In the dialog that appears, choose “Objective-C class”:
  3. In the next dialog, give your class a name and ensure that it inherits fromUIViewController:
  4. Upon clicking “Next,” you’ll be asked to confirm where in the project the file should be saved. For a simple project, picking the main directory of the app is fine.
  5. Upon clicking “Next,” you’ll see that a new set of files has been created for your view controller. Now, associate that newly created view controller with the view controller in your storyboard.
  6. With the storyboard open, click on the view controller. In the “Identity Inspector” panel, pick the “Class” that this view controller is to be associated with:
  7. Once this process is completed, the code for your view controller will be properly referenced by the storyboard entry.

To reference the controls that you’ve dragged onto a storyboard from your Objective-C code, you’ll need to define these relationships. The storyboard editor has an “assistant editor” view to help with this. Basically, it’s a split-pane view that shows both the storyboard and your code. In this example, we’ll reference a button that’s already been placed on the storyboard:

  1. First, ensure that you’ve completed the steps above to associate the view controller class with the corresponding view controller in the storyboard.
  2. Choose the assistant editor by clicking the icon that looks like this:
  3. A split-pane view will open, with the storyboard on the left and your view controller class on the right.
  4. Select the button in your storyboard and, while holding down theControl key, drag from the button to the interface area of your code.
  5. The resulting dialog will enable you to create an “outlet” for the button in your code. Simply give the button a name, and click the “Connect” button in the dialog. You may now reference the button in the view controller from your code.
  6. Let’s hook up a method to be invoked when a person taps on the button. Select the button again, and use the same Control-and-drag maneuver to drop a reference into the interface section of your view controller.
  7. This time, in the dialog box that appears, we’ll associate an “action,” rather than an outlet. Choose “Action” from the “Connection” drop-down menu, and enter a name like this:
    For the “Event,” use the default of “Touch Up Inside,” and press the “Connect” button.
  8. Note that your class now has an interface with two entries in it:
@interface FTSettingsViewController ()
@property (weak, nonatomic) IBOutlet UIButton *myButton;
- (IBAction)tappedMyButton:(id)sender;

The IBOutlet item is used to identify anything that you’re referencing from the storyboard, and the IBAction is used to identify actions that come from the storyboard. Notice also that Xcode has an empty method where you can place the code to be run when the user taps on the control:

- (IBAction)tappedMyButton:(id)sender {

The process above does take some getting used to and could certainly be made more intuitive. After some practice, it will get less awkward. You might find it useful to bookmark the section of the Xcode documentation that describes how to “Connect User Interface Objects to Your Code.”

As we’ll see later, you can also add objects to the view and manipulate their properties programmatically. In fact, applications of even moderate complexity typically perform a lot of manipulation in code. For complex apps, some developers eschew the storyboard and use the code-based alternative almost entirely.


For even the most basic of applications to function, some code must be written. So far in the storyboard, we’ve laid out our user interface and the interactions between the view controllers. But no code has been written to perform the calculations, to persist the settings of the tip percentage and so on. That is all done by you, the developer, in Objective-C.

When an application is running, its overall lifecycle is handled by something called an “application delegate.” Various methods in this delegate are called when key events in the application’s lifecycle occur. These events could be any of the following:

  • the application is started,
  • the application is moved to the background,
  • the application is brought to the foreground,
  • the application is about to be terminated,
  • a push notification arrives.

The events above are handled in a file called AppDelegate. For our sample application, the default handling of these events is just fine; we don’t need to take any special action. The documentation has an overview of the application’s lifecycle and of responding to changes in an app’s state.

The next area of attention is the view controller. Just as with the application delegate, the view controller has its own lifecycle. The view controller’s lifecycle includes methods that are invoked when the following happens:

  • the view controller has been loaded;
  • the view controller is about to appear or has appeared on the screen;
  • the view controller is about to disappear or has disappeared from the screen;
  • the bounds of the view have changed (for example, because the device has been rotated) and the view will be laid out again.

The main code for our application is in the FTViewController.m file. Here is the first bit of code that initializes our screen:

- (void)viewWillAppear:(BOOL)animated
    // Restore any default tip percentage if available
    NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
    float tipPercentage = [defaults floatForKey:@"tipPercentage"];
    if (tipPercentage > 0) {
        _tipPercentage = tipPercentage;
    } else {
        _tipPercentage = 15.0;
    self.tipAmountLabel.text = [NSString stringWithFormat:@"%0.2f%%", _tipPercentage];

In this application, we want to use whatever tip percentage value was stored in the past. To do this, we can use NSUserDefaults, which is a persistent data store to hold settings and preferences for an application. Keep in mind thatthese values are not encrypted in any way, so this is not the best place to store sensitive data, such as passwords. A KeyChain API is provided in the iOS SDK to store such data. In the code above, we’re attempting to retrieve thetipPercentage setting. If that’s not found, we’ll just default to 15%.

When the user taps the “Calculate Tip” button, the following code is run:

- (IBAction)didTapCalculate:(id)sender {
    float checkAmount, tipAmount, totalAmount;

    if (self.checkAmountTextField.text.length > 0) {

        checkAmount = [self.checkAmountTextField.text floatValue];
        tipAmount = checkAmount * (_tipPercentage / 100);
        totalAmount = checkAmount + tipAmount;

        self.tipAmountLabel.text = [NSString stringWithFormat:@"$%0.2f", tipAmount];
        self.totalAmountLabel.text = [NSString stringWithFormat:@"$%0.2f", totalAmount];


    [self.checkAmountTextField resignFirstResponder];


We’re simply reading the value that the user has inputted in the “Amount” field and then calculating the tip’s value. Note how the stringWithFormat method is used to display the tipAmount value as a currency value.

When the user taps the “Settings” button in the navigation controller, the segue that we established in the storyboard will push the settings’ view controller onto the stack. A separate view controller file, FTSettingsViewController, will now handle the interactions on this screen. Pressing the “Done” button on this screen will run the following code:

- (IBAction)didTapDone:(id)sender {

    float tipPercentage;
    tipPercentage = [self.tipPercentageTextField.text floatValue];

    if (tipPercentage > 0) {

        NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
        [defaults setFloat:tipPercentage forKey:@"tipPercentage"];
        [defaults synchronize];

        [[self navigationController] popViewControllerAnimated:YES];

    } else {

        [[[UIAlertView alloc] initWithTitle:@"Invalid input"
                                    message:@"Percentage must be a decimal value"
                          otherButtonTitles:nil] show];



Here we’re retrieving the value from the text field and making sure that the inputted value is greater than 0. If it is, then we use NSUserDefaults to persist the setting. Calling the synchronize method is what will actually save the values to storage. After we’ve saved the value, we use thepopViewControllerAnimated method on the navigation controller to remove the settings view and return to the prior screen. Note that if the user does not fill in the percentage correctly, then they will be shown the standard iOS UIAlertViewdialog and will remain on the settings screen.

In the section above on view controllers and storyboards, I mentioned that thecontrols in a view can be manipulated programmatically. While that was not necessary for our application, the following is a snippet of code that creates a button and adds it to a particular location on the screen:

CGRect buttonRect = CGRectMake(100, 75, 150, 80);
UIButton *myButton = [UIButton buttonWithType:UIButtonTypeRoundedRect];
myButton.frame = buttonRect;
[myButton setTitle:@"Click me!" forState:UIControlStateNormal];
[self.view addSubview:myButton];

Generally speaking, all of the controls that you place in a view extend from an ancestor class named UIView. As such, buttons, labels, text-input fields and so on are all UIViews. One instance of a UIView is in the view controller. This can be referenced in your view controller’s code as self.viewThe iOS SDK positions items in a view based on a frame, also referred to as CGRect, which is a structure that contains the x and y coordinates of the item, as well as the width and height of the object. Note in the code above that the button is instantiated and assigned a frame (location and size) and then added to the view controller’s view.


When Xcode and the iOS SDK are installed, so is the iOS simulator, which simulates an iOS device directly on your machine. Xcode has a drop-down menu that allows you to select different device configurations. Pressing the “Run” button in the upper-left corner will build the app and then run it in the chosen simulator.

Using the menu above, you can switch between iPhones and iPads of different sizes, as well as between Retina and non-Retina versions of each device.

Debugging is done simply by clicking in the left margin of the code editor, where the line numbers appear. When the execution of your app reaches the breakpoint, the app will stop and the variable values in effect at that moment in time will appear below the code editor:

Some things, such as push notifications, cannot readily be tested in the simulator. For these things, you will need to test on a device, which requires you to register as an Apple developer for $99 a year. Once you have joined, you can plug in your device with a USB cable. Xcode will prompt you for your credentials and will offer to “provision” the device for you. Once the device is recognized, it will be shown in the same menu that allows you to switch between device simulators.

In Xcode, by going to Window → Organizer in the menu, you can display a tool that enables you to manage all of the devices visible in Xcode and to examine crash logs and more. The Organizer window also lets you take and export screenshots of your application.


Thus far, we’ve seen the basics of developing a simple native iOS application. Most applications are more complex than this, but these are the basic building blocks:

  • Xcode
    The development environment
  • Storyboards
    For laying out and configuring the user interface
  • View controllers
    Provide the basic logic for interacting with each of the views defined in the storyboards
  • Navigation controllers
    Enable the user to navigate between the different views


To get started with iOS development, you might want to consult these useful resources:

This concludes the first segment of our tour of app development. I hope it has given you some insight into the basic concepts behind native app development on iOS. The next article in this series will cover how to build the same application using native Android development tools.