Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

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:

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.

Further Reading on SmashingMag: Link

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 iOS, PhoneGap and 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 GitHub8.

Native iOS Development Link

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


Obtaining the Tools Link

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.

Creating a New Project Link

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 Prefix14” 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 as view controllers15. 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 controller16, which in turn provides the mechanism for moving between view controllers. A navigation controller provides the navigation bar17, 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.

Storyboards: Building the User Experience Visually Link

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 an extensive guide on Auto Layout in its documentation.

Associating Storyboards With Your Code Link

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 from UIViewController:
  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 the Control 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.

Getting Into the Code Link

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 NSUserDefaults27, which is a persistent data store to hold settings and preferences for an application. Keep in mind that these 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 the tipPercentage 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 the popViewControllerAnimated 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 UIAlertView dialog and will remain on the settings screen.

In the section above on view controllers and storyboards, I mentioned that the controls 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.view. The 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.

Running and Debugging an iOS Application Link

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.

Summary Link

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

Learning Resources Link

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 series37 will cover how to build the same application using native Android development tools.

(al, ea)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37

↑ Back to top Tweet itShare on Facebook

Peter Traeg is a Solutions Architect at Universal Mind where he brings his broad base of technical and business consulting skills to work for our clients. With 25+ years of experience in the application development field, Peter has worked on a wide range of applications from data warehousing to online photo sharing sites. At the Eastman Kodak Company he made extensive use of Flex, AIR, HTML5, iOS, and Android technologies to help Kodak customers share their memories across a wide range of devices.

Peter is active in several development user groups where he regularly speaks on web and mobile application development technologies. When he is not experimenting with his seemingly ever growing list of mobile devices, you can find him engaging in activities such as photography, cycling, and spending time with his family in Rochester, NY.

  1. 1

    Funny that this article doesn’t mention the next generation of mobile development. Unless you want to target only on platform (which I doubt but it’s up to you), I advise to ignore this article and check

    Development for all major platforms using the same code-base.

    • 2

      I also started using Xamarin recently, and it is super nice to have cross-over native code. However, when you get into logic in controllers and visual development in views, you still work separately on each platform. Despite that, it is nice to only really use one programming language and to share models. The Xamarin documentation could definitely use more fleshing out on advanced topics, but it’s getting better all the time.

  2. 3

    I somewhat agree with John here. To only focus on these four does a disservice to the dozens of alternatives out on the market that offer cross platform solutions. At RareWire we offer a unique solution for native app development that we have had a lot of success with. Where’s the love?

  3. 4

    Great article. Looking forward to the rest of the series, particularly Appcelerator.

    Delphi’s RAD Studio XE5 is another dev tool that takes advantage of the single-codebase, native compile (iOS/Android) route. It wouldn’t be a bad idea to mention this, Xamarin, and others in a follow up post:

  4. 5

    First, John really I think this kind of aggressive marketing speech doesn’t have its place here.
    Second, I really doubt Xamarin / Windows Azure will be the “next gen of mobile development”…

  5. 6

    creativecrunk .com

    November 22, 2013 7:50 pm

    It’s nice !!! Please post the part 2 as soon as as possible!

  6. 7

    Interesting article: I developed apps using both Obj-C (iOS only) and PhoneGap in the past, and I was evaluating Titanium as an alternative so I’ll look forward to read the next parts!

    I believe that offering two native options and two options based on javascript+html code is a wise idea, since it allows the reader to (1) understand the basic workflow of native apps development that in my opinion is an unavoidable step (2) to propose the two main alternatives for mobile development using Javascript and HTML, since they are the main focus of many SM readers (many of us have web development backgrounds).

    Thank you :)

    • 8

      Hi Stefano, I’m curious what your experience with PhoneGap was after developing in obj-c? Could you share some thoughts?

  7. 9

    Sad to see the third platform (Windows Phone) left out.

    • 10

      PhoneGap supports it AFAIK, and Appcelerator staff promised to support Win8 on 2014 releases. However you are right, a full native Windows Phone example may be the ideal fifth part of these articles.

  8. 11

    The truth is, in today’s world there are numerous options one has to develop mobile applications. Besides full native, and the options of PhoneGap, AppCellerator Titanium, and Xamarin that were already mentioned, you also have Corona using the Lua language, Adobe AIR using Flash and Flex to name just a couple more. One of the important factors to consider is what you are looking to do. If your application going to be very visually intensive, you need an option that can use the hardware GPU acceleration, so in many cases a JavaScript option like PhoneGap or Titanium probably won’t do it for you. Each technology stack has its own strengths and weaknesses, and I think that is the original point that the author is getting at, and evaluating a selection of options one at a time. For an app like this, any option will do, but for something like an Angry Birds, you’ll need the GPU, which will mean native, AIR on Stage3D, or Corona.

    • 12

      Alberto Torres

      May 8, 2014 2:40 am

      Hi Nick.

      Do you have any experience building iOS apps in Flash? Im looking into this option but I wanted to see examples of real apps that were built on Flash or opinions of developers that have used it. Any help if appreciated.


  9. 13

    Nice article thanks for taking the time to write it. Lots of useful advice for beginning iOS development, looking forward to seeing the future Android article. Keep them coming.

  10. 14

    Very good article!!! Can’t wait for the rest. As far as the other comments above about not featuring there platforms. I don’t think they even feature in Enterprise World. So the ones you chose is good !!!

  11. 15

    If you are looking for an inexpensive way to create iOS,Android and HTML5 web apps you will probably find the cloud-based platform Snappii helpful and easy to use. Even if you are not a programmer this app building platform will allow making custom native apps in hours.

  12. 16

    Great! Article. and totally agree with Vlad.

    Jeff Jones

  13. 17

    I would also mention Icenium ( by Telerik. It uses Cordova as it’s rendering engine. You can develop iOS and Android (soon Windows Phone 8) hybrid apps WITHOUT the need for a Mac. They provide a really nice app that takes your build to their cloud and then puts it on your iOS device.

    I have been using that. We have used Xamarin for a few project, really nice porting program. PhoneGap is nice but I do think Icenium has surpassed the PhoneGap in the way they allow multiple ways to develop your hybrid app. They have a web GUI, a native desktop app and a plugin for Visual Studio to develop your apps with. And the code automatically gets saved to the Cloud after every CTRL + S (Apple + S).

    I would look at that too as an option for developing mobile apps.

  14. 18

    Juan José de la Torre

    December 11, 2013 9:09 am

    Great article ! .Thanks

    btw Standford U course about iOS Dev is updated to iOS 7 now ::

  15. 19

    If you want to make an app and maintain it easily and quickly there are many cloud based services which allow to do it. Most of them even support drag-n-drop functionality that works for non-programmers too. I am using snappii platform that offers lots of helpful features and allows creating really feature-rich and complex native apps.

  16. 20

    Where’s part 2?! :)

  17. 22

    According to me, the future of mobile is not in the native appstores, even if they’re thriving at the moment. In the long run, they are doomed. I wrote a short essay about it: Would love to tell you more about the way we see the future of mobile, on the open web. Cheers.

  18. 23

    +1 for Telerik Icenium. I have been using it for the last month and i must say i am really impressed. I have tried all three options, the browser version (which only works in Chrome), the desktop version, but i chose to stick with the VS extension, because i am using VS for all my projects.

    • 24

      I’ve used Icenium as well and it’s covered in the PhoneGap portion of this series. It’s pretty cool to be able to edit an app on a Windows machine in a browser and moments later have the changes appear on an iOS device ! You certainly can’t do that with traditional iOS development tools.

  19. 25

    Brandon Holliday

    January 10, 2014 12:14 pm

    Great article! Also, very nice to hear feedback from the development community regarding the exciting new tools available for cross-platform development.

    My thoughts: If you’re a web developer, the easiest transition to native mobile app development, in my opinion, is Titanium Alloy, by Appcelerator. Components are created using XML; so, if you’re familiar with HTML, you can pick this up in no time. Components are styled using TSS (Titanium Style Sheet); so if you’re familiar with CSS, you can pick this up in not time. And all scripting is handled using javascript. So, if you’re familiar with javascript, there really isn’t much to learn.

    If you’re a web developer with no native app dev experience, but are looking to learn how to develop native apps, I’d suggest checking out Jeff Batt’s quick tutorials on YouTube (Kinetic Media). Grab a cup of espresso, watch a few videos, and you’ll have your first app in no time.

    • 26

      Brandon, Glad you enjoyed the article. I’ll be covering Appcelerator Titanium in the last article in this series. I agree that it’s a quick way for Javascript developers to get going with fully native apps.

  20. 27

    Is the tutorial meant to be built from scratch or by using a sample project? I’ve tried to go along with it from scratch but got stuck rather quickly.

  21. 28

    Waiting for the android & phone gap articles, please post those next! This article is good if your developing IOS app with a mac. I am downloading and testing now the other suggestions here!

  22. 29

    is native ios release build application? sent the source code of the application of the test team can see you? sent the application binary or source code open?Thank you very much for your response …

  23. 30

    Ehsan Tahzeeb

    March 21, 2014 12:40 pm

    What do you think so why not we use app building platform which helps us to develop app without a deep knowledge of programming. I find some great app building platform, you may check them here

    Please tell me what are advantages and disadvantage of using these app building platform ?


  24. 31

    mobile application development company

    May 10, 2014 7:17 am

    Great! Its a nice step to step guide to build a mobile applications. But to buils a mobile application by this way it is must that you have some knowledge of programming and designing tools. You can also search a good mobile application development company who have created some good mobile apps. If you are interested than you can visit here

  25. 32

    These days it seems like everyone is building apps — not just consumer apps, but apps for the enterprise, too.
    The problem is how you go about creating an app. It wasn’t long ago when you needed to be a programmer to create an app, now there are tools for you to be able to get your mobile app launched without the technical knowledge you thought you needed. I tried loads of them but Snappii seems to be the best among such tools.

  26. 33

    Many business owners struggle with an idea whether they should have a responsive website that works across devices or focus only on building a native mobile app.

    It’s a difficult choice to make since both options present advantages and disadvantages that must be taken into consideration when moving forward. Learn more here

  27. 34

    Will Colson

    July 9, 2014 5:27 am

    This is a wonderful article to four way to build a mobile application, this is very helpful for mobile app develop, But i Suggest that’s create high quality mobile application for small business.

  28. 35

    Bill Paquette

    July 28, 2014 4:07 pm

    This article is very good, and the comments have been informative as well. I’ve developed apps using Conduit Mobile (which is now Como) and recently PhoneGap. At first Como was flexible enough for me to write some JS to allow a callback from my webserver. They have a lot of “drop-and-drag” which was ok for the non-C++/C#/Java users. But when they took away the ability to add code for the callback I knew I would have to find another avenue to produce the app for the company. The latest app I built with PhoneGap, using HTML5, JQuery (JavaScript) and CSS. The nice thing about it is that I was able to release the app on Android, Windows, Amazon and Blackberry rather quickly. PRS Corp went live on those platforms in the last 2 weeks; with Windows being the latest (yesterday). Windows took the longest only because I was trying to get my Dev Account set up. I have an iOS app ready through PhoneGap as well, however I’m waiting on my Mac (just bought one should be arriving soon). I found PhoneGap very easy to use, probably because I’ve mainly created websites. It would be great to find a reasonably priced program or service to write native apps though, without having to learn 3 new languages.

  29. 36

    How do you add the ViewController-FastTip and the SettingsViewController and the Segue from the NavigationController to the ViewController-FastTip and from there to the SettingsViewController?

  30. 37

    Informative ! There is always a war between mobile application developers to choose between a storyboard, nibs and code. But as a team of mobile app developers @contus, we always prefer storyboard to make the controllers like View Controllers, Nav Controllers, TabBar Controllers etc communicate and respond to each other. Where using NIB we need to locate the files in broken view, so it would be better to manage NIB’s and Storyboard to communicate with the fellow developers in an easy way.

    Read for more information
    This is a blog which made me understand better about storyboard.

  31. 38

    This is a very good article for those who developing a new mobile app. This is very helpful for mobile app programmers, I also suggest which is a trusted name in creating high quality mobile application development for small to large business.

  32. 39

    Fred Kabogoza

    October 7, 2014 2:33 pm

    Hey guys whats up nice work done and I am real happy that you are displaying exactly what I want because me personally I never went to school for these things but I do them and through this I learn them, master them then I do my own app.

  33. 40

    I’d like to suggest CppCode. It’s the first and the only offline C/C++ IDE & Compiler on iOS! No jailbreak required, no internet connection required, no ads, free(mium) app.

    App feature list, screenshots and video on Vimeo/Youtube and even quick start at



  34. 41

    I am completely new to iOS development and rather a person who’s does business from it but not the actual development.

    This article really helped me know the basic functional flow how things start in iOS app development. Its written in such a simple language that anyone even a non technical person can understand the basic elements and flow of iOS App development.

    Great article and now finding part 2 of it..


  35. 42

    nice work,im new to native app development,been trying to create an app that can run on multiple platform bt ur article n comments has enligthened me.thanks


↑ Back to top