What makes a well-designed app? Is it the colors? The layout? The icons? The flow?

It’s simultaneously none and all of these things combined – and a whole lot more. In this addition to How to Build a Mobile App: The Ultimate Guide, we’re going to go through – step-by-step – how to properly design an app from the ground up.

Step 1: Find the problem

This might be the hundredth time we’ve stated it in our blog, but knowing your users’ pain point will drive every facet of your app’s development – from the logic in the backend to your color scheme and logo.

This is the most important step to take, as it will dictate everything your app does. When searching for a pain point, ask yourself the following questions:

• Is this problem specific to my niche?
• What solution does my niche expect?
• What steps do they need to take in order to solve the problem?
• Where does my app fit in those steps?

For example, let’s pretend you want to make an app for gardeners. Great! Now, what niche of gardeners are you attempting to connect with? Gardeners is much too broad of an audience. What about community gardens? Those are pretty big right now. Still too broad. Okay, how about community garden managers? Now there’s an idea.

What kinds of problems do community garden managers face? Are community gardens often managed by one individual, or a team? Is that team made of employees or volunteers?

Narrow your scope as much as you can, and know as much as you can about your audience. Go to a community garden. Get your hands dirty. Figure out what it’s all about, and put yourself in the shoes of a community garden manager. Then, figure out how to make their life easier.

Step 2: Know the problem – and the steps to solve it

Let’s continue to pretend you’re making an app for community garden managers, and the problem you’re planning to solve isn’t (after your extensive research) necessarily gardening related, but rather gardening adjacent. You found that two big issues community food gardens strive to solve are food waste and food deserts – community gardens tend to reach out to, well, the community, in an effort to get them eating healthier, fresher, and more local produce.

The community garden you’ve reached out to specifically wants to have a system put in place that keeps track of their food production, and how much of the food produced is wasted – but their group of volunteers doesn’t have the time to reach out to fifteen, thirty, or one hundred people every week.

So, your plan is to make an app that gives the community garden manager the tools they need to keep track of food production and food waste. But how do you go about doing that?

They have a limited budget, and since they’re volunteers, limited time. Because of this, they need a system that gives them the necessary data to effectively run the garden in the shortest amount of time possible. This is also a two step process – the community garden manager needs to know what’s happening in their garden, as well as what’s happening at their members’ dining room tables.

Your app needs to allow the community manager to collect data from remote locations – the community garden members’ kitchens, as well as the garden itself. So, you now know this app will be designed with two types of users in mind:

1. The community manager keeping track of the different plots in the garden
2. and the members who self report on their food consumption

Notice that both of these categories of users are organized by the role they play in solving the main paint point – secondary pain points are solved (like how to share and analyze data remotely) in the process of solving the main pain point – giving the manager the tools they need to adapt with members’ tastes, and grow more food that will actually be eaten.

Everyone’s brains work differently, so we won’t tell you to specifically sketch out your ideas, make wireframes, or write a list of steps users would take. Do whatever works for you – but it’s necessary for you to know the expected steps the people using your app will take. These are called your use case scenarios, or user stories.

So let’s map out the main use case scenario for this app. From now on, for brevity’s sake, we’ll call this app “Growr”:

1. The community garden manager adds in the current produce to a selectable list on Growr
2. A community garden member selects the types (and amounts) of produce they brought home from the garden from that list
3. The member then reports on the types and amounts of produce they actually ate
4. The data is sent to the community garden manager, who then uses that data to optimize the amounts and types of food grown in the garden

Step 3 – Build your brand

Whether you’re doing it DIY or by partnering with a dev shop, this is the time to figure out what your app is going to look like. By this point, you know the audience you’re trying to connect with, the problem they face, and the steps your app will take to help them solve that problem.

An app’s brand is determined by your audience, and measured by how well it solves their problem – not by its icon in the App Store. But, it doesn’t hurt to make your solution look pretty. This is where you’ll figure out Growr’s color palette, fonts, logo, and icons.

After you’ve created these individual elements that comprise your visual brand, and with a map of your use case scenarios, you can start to layout your app. This is a step in the process where we will advise the use of wireframes – this is to help you get a feel for the flow of your app, and save both time and money.

The next step is to add in all the individual elements you made previously (like the logo, and button styles), and fill in the wireframe layouts with final versions. When that’s done, it’s time to move on to the prototyping phase.

Step 4 – Make it work

You don’t need to know Swift or JAVA – there are plenty of prototyping apps available to use. Before we begin coding, our lead designer will create a prototype of the app in InVision, and we’ll all sit down in our conference room to test the build against the pain point. We get the whole company together for these meetings – the more eyes on your prototype the better.

Doing this will allow you to iron out any bumps in your app’s flow, UX, and design all before writing a single line of code. It will also give you an idea of what your app will really look like when it’s complete – it’s the difference between looking at a photo and watching a video – prototyping your app, while adding another step into the design process, will always give you more information that screenshots of your app’s layout.

After this, your design phase is complete! It’s on to coding for you!

Some other prototyping tools you can use:

• Balsamiq
• Adobe XD
• proto.io
• Axure
• Justinmind
• Fluidui
• Lucidchart

Platforms, themes, and user expectations

Major decisions about your app’s design will be made by which platform you build your app for – either Android or iOS. Both have different style guidelines, as well as over-arching layout themes. Android and iOS users expect the same functionality to be interacted with in very different ways; Android users, for instance, will look for a “hamburger” style navigation menu, while iOS users will look for a bottom navigation bar.

Android design principles

Create. Unify. Customize. These are the ideals of Android, and specifically, Material design. Material design focuses on typography, grids, space, scale, color, and imagery, and a meaningful, focused hierarchy that immerses users in the UX of the app.

Click here for the full list of Android core design principles.

iOS design principles

Clarity. Deference. Depth. These are the themes that separate iOS from other platforms. Some other words that pop up a lot in Apple’s iOS design guide are understand, familiar, subtle, and functionality. iOS guidelines dictate apps with an esthetic that fits the brand of the app, consistency of theme with iOS as a whole, and fluid manipulation and feedback.

Click here for the iOS style guide.

General app design principles

Whether it’s print, web, or mobile, good design is more than making something look pretty – design is understanding both the project and the problem – and knowing how to present that information in a pleasing way.

An important thing to keep in mind when designing your app is that any interaction should provide a user with some sort of feedback. Think of the difference between a website that features scrolling parallax versus one that doesn’t. Which one feels like the better, more responsive UX?

Smartphones are much more intimate than a desktop – they spend most of their time right next to us – and because of this, we expect our inputs when using them to have a sort of visual conversation with us.

You want your app to feel like it belongs on the users device, and for iOS and Android users, this will mean different things. While Android apps tend to be more customized than iOS apps, both feature libraries of visual elements available to all UI/UX designers. Don’t be afraid to use these – in fact, Apple encourages it. Your app should feel as native to the user as their native texting app.

This is why we believe native development is always the best choice in the long run – even if that means increasing the time and money spent in the development stage. While building multiple apps for different platforms can be more expensive in the beginning, having two native apps that perform better with users than a single hybrid app is a more sustainable and scalable business model. For more reasons why we believe native is the better choice, visit our blog on the topic.

Another thing to consider is not only the hierarchal flow of your app, but the visual flow as well. For example, when an iOS user sees a screen come in from the bottom of their device (known as a presentation), they intuitively expect a step that must be completed before moving back to the previous screen. If a screen comes in from the side (known as a push), they intuitively know they’ve moved on to the next step.

It’s choices like this that may be small on their own, but the summation of their parts as a whole create a consistent visual language and flow throughout your app – which is one of the main hallmarks of good design.

Nitpick the details

Details matter – an app should never have to come with a set of instructions in order for a user to know how to properly interact with it. It’s the small details that will provide your users with the hints and visual cues they need to navigate your app.

Subtly is key to mobile app design. Something as simple as a highlighted or muted color can imply a button’s functionality – if a button is a bright color, your users will expect it to accomplish something. If a button is a muted color, like grey, they will intuitively expect it to perform an action analog to a canceling function.

There’s a balance to these fine details, however. Keep your design as simple as possible – if the people you present your prototype to can’t figure out how to navigate your app in a few minutes (or ideally, 30 seconds), it’s time to go back to the drawing board and figure out how you can simplify things.

Understand the problem

That’s the most important part of mobile app design. It doesn’t matter if you’re not a designer yourself – knowing what your app needs to accomplish will dictate everything about it. It’s a quote I’ve used before, but I feel Frank Lloyd Wright’s words fit perfectly in reference to mobile design:

Form follows function – that has been misunderstood. Form and function should be one, joined in a spiritual union.

For the past couple of months we’ve been going over both the basic theory of, and different strategies for the implementation of a successful ASO campaign. But one (very important) part we haven’t covered is how to actually measure your app’s growth.

There are many different ways to go about measuring your app’s success, but we’re going do a virtual tour of our favorite app analytics platform – Kumulos.

Before we do, we’re (really quickly) going to go over the absolute basics of ASO, and why it’s just as important to keep track of your ASO campaign as it is to come up with one.

ASO: Just the facts

• ASO stands for App Store Optimization, and is the process of improving the visibility of an app through the means provided in the App Store or Google Play
• Keywords are the basis of ASO – just like SEO
• ASO isn’t just limited to the App Store or Google Play – it ties in with your SEO, as well as the UX of your app itself
• The rules and trends of ASO are ever changing – just like SEO

Why you need to keep track of your app’s performance

Just because a keyword works well one week doesn’t mean it will perform well the next – staying on top of keyword trends requires close observation of your install rates when changes occur. Also, a powerful tool, A/B testing, can provide a big boost to your app’s rankings – but only if you analyze the data your changes bring.

Keeping track of your competitors performance is just as important as analyzing your own app’s success, and we’ll cover how to do just that a little bit later in this blog. To put it simply, if you’re not analyzing your app’s (and your competitors’) performance, you’re flying blind – and your ASO efforts will eventually hit a wall.

Measuring your app’s success – with Kumulos

There’s a lot you can do through Kumulos:

Keep track of your ASO campaigns on both the App Store and Google Play – from your app’s description to when you last updated it, and everything in between

1. Analyze (and create) reports on user acquisition and retention, as well as audience engagement, conversion rates, and your API performance
2. Explore and analyze events
3. Keep track of your backend: API use, current SDKs, tables, and more
4. View reports that are updated every 5 minutes covering app issues, crashes, and other monitoring checks
5. Last but not least- schedule, implement, and analyze push notifications

Managing your ASO with Kumulos



This is the screen you will see after opening your app’s ASO tab. From here you can view all of the information your app displays on the App Store and Google play.

From the ASO tab, you can compare both your App Store and Google Play efforts. This keeps the access of this information in one place, making it easy for developers to keep track of both campaigns – and allows for simple synchronization, or differentiation, depending on how users on both platforms respond to your ASO campaign implementations.



When you click on a specific tab under ASO, Kumulos will give you a detailed breakdown of all pertinent data

Not only does Kumulos keep track of your keyword rankings, it also helps you figure out how your competitors are doing as well:



By clicking the gear highlighted above, you can find a lot of information on your own keywords, and your competition’s:



Knowing what keywords your competition is ranking for can help you decide where to focus – consider the following when strategizing your keywords:

• Just because everyone else is competing for a certain keyword or phrase, doesn’t mean it’s the best
• Try putting high-competition keywords in the title of your app. For example, “Brew Trader – Trade Beer Better”
• Mix in low-competition keywords to catch potential users, such as “Beer Trader” versus the more popular “Beer Swap”
• Make sure most of your keywords and phrases are as specific as possible – while it is important to rank for generic keywords like “beer,” you’ll achieve higher rankings by getting specific with your keywords

Kumulos also keeps track of your app’s user ranking and user reviews, so you never have to leave the Kumulos portal to analyze the entirety of your ASO.

Tracking analytics with Kumulos



This is where things start to get really cool – as you can see above, there’s a lot you can do with the analytics tab.

1. Acquisition



By clicking the menu button highlighted above, you can select specific items to visualize

Some things to keep in mind when looking at your app’s acquisition:

• Retention is an important stat if you app has a demand for daily use – if it doesn’t, you don’t need to worry about it too much
• Daily users and monthly installs are key metrics to keep track of
• Look for power users (users who log in continually and daily)

Your acquisition report is your key to A/B testing – this is where you’ll find out if the change you made (such as switching your app’s icon or swapping a keyword) had a positive or negative impact on your conversion rates.

Under acquisition, you’ll also find:



How your rankings have changed over time, compared to your competitors.

2. Audience



You’ll use this tab to figure out where you users are coming from, as well as:



Breakdowns of which users are using which platform (sorted by version), and which version of your app they are using.

Use this section to help plan your acquisition campaigns, and keep track of the OS users are on – if a large portion of your users are on older versions of an OS, you’ll want to make sure your updates don’t ruin their UX (such as reducing the compatibility with smaller screen resolutions).

3. Engagement

The first thing you’ll see under engagement is this:



By studying your session distribution chart, you can figure out the best times to send out push notifications. There are two ways to go about scheduling push notifications:

1. Send notifications on a busy day right before a peak usage time (in order to maximize the number of users in a given span of time)
2. Or, send notifications on slower days to boost retention on low volume days

You can always mix and match to get the most from your push notifications, but we’ll get more into that later.

Reports via Kumulos

My favorite Kumulos feature is the report tab. You can generate an interactive PDF based on a range of dates that will provide a breakdown of all the information you’ll need to make strategic decisions for your ASO campaign.



Push



Under the push tab, you can keep track of who is subscribing to your push notifications. You can also schedule and automate notifications, as well as target specific groups of users, and analyze who’s opening what.



Kumulos does a fantastic job of organizing a facet of ASO that is difficult to keep track of, especially with the “sent” tab. Here, you can look back through your app’s history of campaign-driven and event-driven notifications in order to keep track of where you are within a campaign.

Backend



Here you can find everything you need to keep track of your app’s backend: API use, SDKs, API performance, Hookup connection, and all of your application’s details.

Diagnostics



This is a tab you should visit at least once a day – the effects of crashes or app issues on your app’s ASO can quickly spiral out of control. Kumulos helps you keep track by continuously updating this tab every five minutes, so you know as soon as something happens.

Kumulos is an all-in-one app analytics platform

Not only does Kumulos provide a complete hub of all your ASO information, it’s very user friendly – this is especially due to the report feature, which allows you to send all the analytics of a campaign in an auto-populated PDF for easy dissemination of information. We love sending these reports to clients, as the data breakdowns are simple enough for anyone to digest – whether or not they know the theory behind ASO.

The push feature is great as well – not only does Kumulos keep track of all your analytics, it actually provides an actionable service. This is a powerful inclusion in the platform, as it gives you the ability to directly analyze user opening trends, and create a new push campaign based on your analytics, all without ever leaving their service!

Anyway, I just want to say a thank you to the folks over at Kumulos for their help with this blog – and if you’re interested in getting started with Kumulos, drop by and give them a ring! They’re all fantastic people!

Every business has a process, just like every recipe has a set order of steps – and, just like a recipe, if a business’ process is out of order or incomplete, the final product can end up tasting pretty bad.

Developing a mobile app is no different – missing (or incorrectly implementing) a single step of development can throw a wrench in the process, causing days or sometimes even weeks of delays and re-structuring code.

Every developer has their own tweaks and differences in their development process, but the overarching steps are generally universal in their order. You wouldn’t bake a cake and then put in the flour, after all.

The mobile development cycle

1. Research
2. Design
3. Prototype
4. Determine feasibility
5. Program
6. Test
7. Publish
8. ASO & app marketing

These steps, while ultimately implemented in this order, do share some give and take, especially between steps 5 and 6; a dev team will program and then test – and after finding bugs, may return to any point of the process depending on the problem that was discovered.

This method of coding, testing, and then coding again is what’s called agile development. Dev teams that work within an agile development cycle work in sprints – coders will build a feature or feature set usually over a period of one to two weeks (we like to work in one week sprints to really take advantage of agile’s full potential), test the build, debug, and then implement their current branch into the master branch of code.

But, before we get more into steps five and six, let’s talk about step one…

Research

This is possibly the most important step of any business venture – without properly researching your target market, audience, and the competition you will face, there’s no foundation to build a solid structure upon. The story about the three little piggies? Yeah, it’s like that – but it’s your money being blown away, not straw. As we’ve gone over before, there are a few questions to ask that can help guide your research:

• What do I want my app to accomplish?
• What platform(s) do I want my app to be on?
• What is my competition?
• What is my time table?
• What is my budget?

Some of these questions will lead the direction of your research, and others will be answered by your research. For instance, your findings about your target audience will dictate what platform(s) you will publish your app on, while knowing what you want your app to accomplish will determine the target audience you will want to tap into. If you want to build a productivity app, for example, your target audience will mostly be persons over the age of 25, while a mobile game might go after a target audience in their teens.

Other times, finding an untapped market might dictate what you want your app to accomplish – there’s a lot of research methodologies out there – but no matter what, every step you take should be to figure out the best way to solve your intended audience’s pain point.

What’s a pain point? Let’s pretend our target audience is… squirrels. Yeah, squirrels. You’ve seen a lot of the furry critters complaining on social media about always losing the acorns they’ve buried, and you’ve decided your going to build an app that helps them keep track of their acorn haul.

The pain point is squirrels are constantly losing acorns – your app, and everything it does, is intended to solve it.

Design

Good design is the blending of both form and function to create a simultaneously visually pleasing and useful tool that provides the functions necessary to solving your users’ pain point.

In other words, don’t just make something that’s pretty – make it work for your users. A good way to go about getting into your users’ heads is to come up with user stories; a helpful tool for figuring out what design choices you should make, and how the functions of your app will flow together.

For example, our squirrel-based acorn finder app (which from now on will be referred to as Nutsapp) should have a pretty simple design, as it really only needs to accomplish a few functions to solve the squirrels’ pain point:

1. Provide users with a map of the surrounding area using GPS
2. Allow users to place geotags where they’ve buried acorns using location services
3. Store the geotags in searchable lists – e.g. “acorns by proximity” or “acorns by date buried”

So, we have our user story; a squirrel buries an acorn, opens Nutsapp, places a geotag on their map, and eventually, searches a list to find it again. Based on that, we can create wireframes to determine how the information will be displayed on the squirrel’s mobile device, and based on those wireframes, we can build the UI of the app itself in a program like Sketch.

Then it’s on to the next step…

Prototyping

During this next phase of development, the designer of Nutsapp would build the prototype in a program like Invision. This is where UX is the main focus – prototyping is used to determine whether or not a design makes sense when actually used to solve the pain point of an app.

The development team should always keep in mind use case scenarios during this step – if the app’s flow doesn’t make sense, it’s time to go back to the design phase.

There’s a lot of back and forth between prototyping and design – and that’s a good thing. This is the first step that designers and programmers work with each other, and together, they can determine the next step of the development phase.

Feasibility

Once the programmers for Nutsapp have looked at the prototype, they can then determine the feasibility of its functionality. The programmers will look into whether the necessary back end integration is achievable or not, and determine what APIs will be used to provide users with the functions Nutsapp needs to work.

If a part of Nutsapp’s design isn’t feasible, the programmers will usually work with the designer to figure out a good way to achieve the necessary UX and functionality while still working within the realm of what’s possible to code.

Programming

Speaking of code, this is where the magic happens. Programmers will take the designed UI/UX and build based on the prototype provided (which is why it’s so important to nail down look, feel, and feasibility of the prototype before moving to this step).

Usually, devs will:

1. Build the UI
2. Connect the UI to the code that makes it actually function
3. Define the data model (the structure of information in the app)

If the dev team is working within the agile method, after each sprint, the team would meet up, discuss their progress, test the functionality, and determine the goal of the next sprint based on the findings of the testing. This cycle is repeated until the app is completely built.

Testing

While Nutsapp’s dev team has been testing after each sprint, after the app has been fully coded, it’s time to move on to beta testing. This is an important step, because it gives you the chance to see how someone who has no knowledge of the inner workings of Nutsapp interacts with and navigates the functions within the app.

It might feel a little disheartening, but do your best to try to break your app. Push every button you can faster than a squirrel normally would, attempt to complete steps out of order, and see what happens when information is input incorrectly.

When you find bugs – and most likely, you will – go back to the programming phase, and fix them. It’s always better to find and fix bugs before launch, even if this delays the launch of your app. Squirrels, just like users, are skittish, and any hiccup in the UX of an app can cause your target audience to abandon your service.

Publishing

After (throughly) testing and de-bugging your app, it’s time to move on to publishing. Both the App Store and Google Play have different publishing rules, and if you’re searching for a quick rundown, look no further than our How much does it cost to make an app? blog.

ASO & app marketing

We’ve gone over ASO and app marketing before (multiple times, in fact), so if you want to go over both the basics and the nitty gritty, visit all three of those blogs.

Your ASO and app marketing campaign are mostly based off of your findings from the first step of the development process – research, and as such, your ASO and marketing campaign should be developed over the course of the entire process. The reason we’ve listed this step last is because ASO and app marketing never end.

Your competition is constantly changing, along with the needs of your users and the trends they expect to be followed. A few ASO rules to always follow are:

• Update your app frequently, but not unnecessarily
• Use A/B testing on your app’s page on the App Store (or Google Play) to determine what works best to capture your audience’s attention
• Keywords, keywords, keywords – look at what keywords your competitors are using, see what you can do to beat them, and figure out keywords they aren’t using to their full advantage to capture an untapped segment of potential users

Your ASO and app marketing efforts should work in tandem – people generally use the search feature of both the App Store and search engines like Google in the same way. If a squirrel is searching for “acorn finder” in Google, they’re most likely going to search for the same thing on the App Store.

Some sections of your app’s page on the App Store don’t rank for keywords, so consider putting your most important and strategic keywords in your app’s title, after the actual name of your app. In the case of Nutsapp, this would look like: “Nutsapp – Acorn Finder.”

Agile development fits its namesake

It’s called agile, because that’s what app development needs to be – adaptive to the issues every development cycle will face, and quick to respond and fix those problems.

Everyone knows the two major players on the mobile platform market – Apple and Android – but what makes these platforms tick?

If you’re an iPhone user, your phone runs on iOS, which utilizes the programming language Swift. Swift was released in October of 2014, and is currently in its fourth iteration, aptly named Swift4. As our third installment of How to Build a Mobile App: the Ultimate Guide, we’ll go over what you need to know in order to make informed decisions about iOS development, and key terminology that will help you better communicate with (and understand) Swift developers.

Disclaimer: If you’re a developer or software engineer, there might not be any new information for you to find here. For a more in-depth discussion about app development, check out our addition to the native vs. hybrid debate.

If you’re a CFO, business developer, or appreneur who’s trying to figure out what a software engineer is talking about when they say “back-end integration,” or want to know just what exactly is an API, you’ve come to the right place.

As of June 2018, iOS accounts for 44.5% of the worldwide mobile market – a growth of 15% since January of 2012. In the US, iOS boasted a market share of 63% in 2018. With over 2.1 million apps on the App Store, Swift can be used to create programs on all of Apple’s platforms – iOS, macOS, watchOS, and tvOS.

Swift is based on and emulates the functionality of the C family of programming languages, including Objective C and C++, with an open source community of developers at swift.org. Swift’s open source code is hosted on Github, an online community of over 28 million developers for hosting and reviewing code.

Due to the open source nature of Swift, the Swift community has compiled libraries to share with other developers. These libraries are resources of generic, useful code that can run on all platforms supported by Swift, and include character sets, support for dates and times, interaction with the file system, and many more functionalities. Swift comes with a default library, but these extended libraries, named the Swift Core Libraries, are continuously updated by the open source Swift community – allowing developers to utilize the newest innovations in Swift code (without writing it themselves). This code can then be customized to fit any need.

Swift can also be used on a Linux distro to build both libraries and applications, and the open source community is currently working together to bring Swift to other computer platforms.

The tools available to developers

While coding, Swift developers use XCode to write, and can use playgrounds to view their code’s outcome in real time. While working collaboratively, developers will use organizational tools such as beanstalk, which are used to keep track of code and current projects. These organizational tools are especially important when collaborating on a project, as any difference in a line of code between two workspaces will result in a merge conflict. When this happens, both lines of code must be compared in order to identify the merge conflict, adding extra time to the debugging process.

Coding best practices dictate it’s always better for a software engineer to work in an isolated branch to avoid merge conflicts altogether.

Developers can use a git client such as Sourcetree to check code in and out of collaborative databases. Think of it like Google Drive – it’s a shared workspace for multiple developers to remotely access code from the same database.

The Swift process

The overarching structure of a simplistic app designed in Swift is:

• View Controller – Think of this as the frame of a painting. The view controller, which is aptly named, controls what you see on the screen of your mobile device.
• View – Within the view controller is the view. Think of this as the canvas of a painting – the view makes up the sum of all visual aspects of the app. Each screen of an app is a different view.
• Subview – Subviews are the individual sections that collectively make up the view. Think of a subview as specific sections of a painting, such as how the subject matter is distinguishable from the background. More specifically, a subview would be the keyboard section of iMessage, or the section where text messages display.
• Buttons – Buttons are… well, buttons. Within subviews, buttons are the interactive elements of apps. Think of the individual letters of the keyboard section of iMessage.
• Images – Also within subviews, images are used to display specific pieces of visual information, and range from photos to logos and icons. An image can function as a button.

In order to do this, developers:

• Start with building the basic UI (user interface)
• Connect the UI to their code
• Work within the view controllers (different screens will have different views)
• Define the data model (the structure of information in the app)

First, a software engineer will layout the screens of an app in a storyboard. This acts as the roadmap for what the completed app should look like, and individual elements on the screen are then connected to code. These elements are referred to as classes, and the code inside these classes controls everything that element does, and how it behaves. For example, a class could be set to darken whenever an element is interacted with by the user, or set to cycle through images at specific time intervals. Classes can be coded to act in almost any way the software engineer can imagine. As classes are built, the UI is connected to the code.

Next, the de-bugging process starts. This is where pull requests come into play. When individual software engineers write code, they work on a branch (a section of the apps’ code) separate from the master branch, in order to minimize the risk of depleting the robustness of the app’s original code. Before implementing the code they are working on into the master branch, a software engineer will make a pull request based on their individual branch versus the master branch. This pull request is in essence a review process – having a second pair of eyes look over code is a great way to catch bugs before they are implemented. The branch is tested, and after its final iteration, is implemented into the master branch.

Developers will repeat this process for every view controller until the app is completed.

The next step in development is beta testing, which we will cover in detail later down the road. After the app is thoroughly tested, the app is submitted to the App Store for review by Apple. During this step, you set your app’s availability (what regions it is available for purchase in) and pricing, and then after approval from Apple, the app goes to the marketplace.

Adding an app to the App Store costs $99 per year, and Apple keeps 30% of each sale. For more information about how much it costs to build an app, check out our blog post on this topic.

Down the line, we’ll go over Android development, so if you’re looking forward to that, don’t worry.

Glossary of developer jargon:

• Adaptive interface: An app that adapts to the available screen resolution. Essentially the same idea as a responsive web page.
• API: An Application Programming Interface is a set of functions, classes, and protocols that define how pieces of software interact with each other. They facilitate code creation by providing tools and building blocks that help companies connect their software with another set of software, or even other companies’ code.
• API calls: Sometimes referred to as an API request, an API call is essentially a piece of software in an app connecting to a server, and requesting a data transfer.
• Back end development: This forms the logic and data structure of the app.
• Back end integration: This allows an enterprise system to connect to an app – for example, connecting the database of a website to an app, in order for users to access the database through the app rather than the website. The information is hosted on the website’s server, but is still accessible through the app itself.
• Control: This is a type of view that responds to a user’s input, like our example of a button turning dark after interaction.
• Enumeration: Referred to by developers as “enums,” an enumeration defines a common type for a group of related values, and allows you to work on these values in a safe way within the code.
• Front end: This is the layer of the app that users interact with.
• Adaptive interface: An app that adapts to the available screen resolution. Essentially the same idea as a responsive web page.
• Function: A function is a reusable (and named) piece of code that can be referenced from many places in a program.
• Iterate: To perform a certain task or function repeatedly.
• Method: Like a function, a method is a reusable, named piece of code that’s associated with a particular class, structure, or enumeration.
• On demand app: These are apps that allow users to find, connect with, and book a professional service.
• SDK: A Software Development Kit is a pre-made software tool that can be used for a variety of functions. Some SDKs help with analytics, others provide debugging and maintenance utilities, and a whole host of other functions.
• Structure: When written in Swift, structures are designated by the keyword “struct.” Structs allow developers to store data in the form of properties and functions.
• Tokens: A token is a software based security tag that produces a single-use login password or PIN.
• UI/UX: User Interface and User Experience are intrinsically tied to each other. UI is the layout and design of the front end of an app. UX is how the app flows, functions, and responds to the user’s inputs.