How to build a MVP iOS app

Building an app is never a simple process – but there are steps you can take to make your app’s development as smooth as possible. In a follow up to our Which is the better platform for a MVP? blog, we’re going to go step-by-step through the development of a MVP iOS app – from ideation, through development and testing, and onto publishing, launch, and post-launch development.

If you’d like a refresher on MVP development, check out our blog post on Clutch.

But first…

We need to reiterate why we’re specifically going over iOS MVP app development, and not Android. While there’s a lot of reasons as to why iOS is the ideal platform for a MVP, there’s one aspect that we will be covering in detail throughout this blog – user engagement:

  • iOS users engage apps for nearly twice as long as their Android counterparts
  • iOS apps have a higher retention rate than Android apps
  • iOS users download more purchasable apps than Android users and spend more money on in-app purchases:

  • Gaming app average revenue per user: $1.99 (iOS) versus $1.56 (Android)
  • Shopping app average revenue per user: $19.64 (iOS) versus $11.49 (Android)
  • Travel app average revenue per user: $32.29 (iOS) versus $20.47 (Android)

It’s stats like these that make up a market better suited for a MVP – not to mention the faster development and testing time for iOS apps, which compliments (as well as keeps up with) the already quick development cycle that makes a MVP a MVP.

The steps to (quick) iOS development

It’s important to note that there is no shortcut to development – if you want to make a good app, at least. The trick to achieving the speed of development that an MVP is known for is to build an app that works with as little features as possible.

To a service-minded company or appreneur, this can sound counter-productive, or even go against mission statements that boil down to “providing the best service possible.”

But a MVPs end goal isn’t to remain as a minimum viable product – once a MVP has had a successful launch on the App Store, the development cycle continues in the form of updating the code base of your app to include more features.

The efficiency of a MVP comes from those aforementioned iOS user metrics; user engagement, in the form of constructive criticism and requests, will serve as your market research and your app’s beta test. This is one of the deciding factors in the lower cost of developing a MVP app – that, and the shorter amount of time actually spent in development and testing.

Let’s look a little deeper into things.

Step 1: MVP ideation

All apps should stick to features sets that help solve their pain point – but a MVP, by definition, must so. A simple way to make sure your app is only utilizing features that play a role in solving your pain point is to write a list of everything you want your app to do.

Then, take your idea and start trimming the fat – let’s take a look at an example:

Let’s pretend that it’s a few years back, and we’re currently in the process of ideation for Brew Trader. Brew Trader is an app that connects craft beer enthusiasts by providing them with a platform that serves as a medium through which to trade craft brews with others in their area.

So, we write out a list of everything we want it to do:

  • A map that shows the locations of bottles up for trade, and is updated continuously so users can see the latest offers, as well as the ability to move the locations of trade beacons
  • A user profile that contains information the user wishes to share, as well as the user’s entire collection of craft brews
  • A messenger so users can DM each other
  • A trade history so users can find other users based on past interactions
  • A bar-code scanner to populate information about bottles available for trade

Then, we edit that list down to what Brew Trader needs in order to function properly:

    A map that shows the locations of bottles up for trade, and is updated every 10 minutes so users can see up-to-date offers

  • A user profile that shows their bottles available for trade
  • A messenger so users can DM each other (while a significant feature set, this is necessary, so users are able to communicate meet-up times and locations)

All in all, that boils down to three different screens, which are built out in the next step.

Step 2: MVP UI/UX

Let’s take those three feature sets and break them down into the visual elements that will make up Brew Trader’s UI. First of all, just like 99% of iOS apps, we’re going to need a bottom menu navigation bar.

This is utilized in UI design so a user can quickly switch between the screens that contain the feature sets listed above. This bar will contain three icons, which will each signify one of the three screens – those being the map screen, the user profile screen, and the messenger.

The next thing to do is layout your different screens.

The map will be hooked up to a mapping API, such as Google Maps. Google Maps is free, as long as your app is free. If you’re looking for other options, check out our blog about how much it costs to implement a GPS & mapping API.

The next element of the map screen to design would be the trade beacons, as well as the sub view that would pop up when selecting a beacon – this sub view would present the name of the bottle up for trade, as well as the user whom it belongs to.

The next screen to design is the user profile section. For a MVP, this should be done in the simplest way possible – a section to add a thumbnail profile photo, and fields to add and view bottles that are up for trade.

The final screen, the messenger, can utilize a messaging API – many of these can be tweaked to match your app’s branding and color schemes.

That’s all you need to design if your making a MVP. Next in line is…

Step 3: Coding a MVP

iOS apps are built using Swift, which uses the following components to create an app’s architecture:

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.

When it comes to coding, there really isn’t any difference between programing a MVP, versus programming a fully-fledged app. The shorter development time of a MVP comes from the smaller number of features to implement, which means less UI to build out, and less backend logic to program.

If you’re looking for tips on how to avoid costly mistakes, check out our blog on app development pitfalls.

Step 4: MVP testing

While one of the upsides of a MVP is your early adopters serving as your beta test, you still do need to test your app before you send it off to the App Store. This is especially true for iOS apps, as they face a rigorous review process before they are officially published on the App Store.

Not only will your app be rejected if it isn’t robust enough for Apple’s standards, a buggy app will only serve to weigh your growth efforts down. Users are more likely to abandon an app than stick with it.

Because of this, you must iron out the kinks of your app before it launches. For tips on conducting app testing, check out our blog on the topic.

Step 5: Publishing

After your app has been thoroughly tested, it’s time to send it off to Apple for review and approval.

In order to publish your app to the App Store, you must pay a annual fee of $99. If your app costs money to download, or goes by a subscription model, Apple will take 30% of each sale.

That’s really all there is to publishing your MVP app – the publishing process doesn’t differ depending on what type of app you’re making. All apps on the App Store go through the same review process.

Step 6: Launch

Launching a MVP is largely the same as launching an other app, but there is one very important factor to note.

Users will make snap decision based on the first impression of your app. Users do, however, make exceptions for small hiccups if they are made aware of the possibility up front. The nature of a MVP app isn’t to be perfect, but rather to provide the best current solution to an unaddressed, or under-addressed pain point in your user’s lives.

In your App Store listing (which we’ll cover in detail below), you’ll want to include a section that explains three things:

  1. You understand that your app isn’t perfect, but you’re working on making it better
  2. Users can directly contact you to provide criticism or make requests for features
  3. Users can expect regular updates

Remember – users are more likely to delete your app from their phone than they are to keep it. This is why communication is important with your users – but doubly so with a MVP. Your users need to know from the start what they are downloading. They’ll be understanding if you’re upfront and transparent about your app. They’ll ignore, or even worse, spread bad word-of-mouth about your app if they are kept in the dark about what you’re doing.

Step 7: ASO

There are two fronts to your app’s ASO – User acquisition, and user retention. These can then be broken down into sub-categories:

User acquisition:

  • Keywords
  • The app’s build and compatibility
  • The app’s page on the App Store

User retention:

  • User reviews and ratings
  • Time users spend engaging with your app
  • In-app purchases (if applicable)

For a MVP, when it comes to a keyword campaign, focus on one main keyword, and derive from there until you have 5 keywords to work with. To continue with our example of Brew Trader, we’d use:

  • Beer
  • Beer Trade
  • Beer Swap
  • Beer App
  • Beer Finder

There’s a lot more to planning out and implementing a successful ASO campaign. For more information, visit our ASO: 101 blog post.

Step 8: MVP post-launch

This is the most important step of a MVPs development, as your execution here will determine the trajectory of your app’s future.

Start with both keeping track of analytics, and engaging with your users. Use every channel available to you to engage with your users – social media, push notifications, and responding to user reviews in the App Store itself.

For more information about tracking your app’s analytics, visit our guide to measuring your app’s success with Kumulos.

Next, you’ll want to start updating your app. In order to do this, start from step one – ideation. This time, however, use the requests and criticism, as well as your findings from your analytics to direct where you should be investing your time.

What are the steps to creating an app?

Do you want to create an app, but have no idea where to start? That’s okay! It’s actually not that complicated, as long as you have a roadmap to guide you.

Naturally, just like any idea or business venture, the first step is:

Ideation

Whether your idea comes from inspiration from your daily life, or from finding a need due to market research, or even because your business needs an app; the strength of an idea isn’t based off of color schemes, names, or packing in trending feature sets to impress investors.

It’s all about how well your app helps solve the pain point your intended users face. It doesn’t matter what your app does, or what type of app it is – your app’s value will be judged by the solution it provides.

Gaming apps solve boredom, fitness apps help solve either lack of motivation or help keep track of goals, navigation apps help users find their way, banking apps help users answer the important questions like “Do I have enough money in my checking account for this coffee?”

You get the idea.

At this point, don’t sweat the small stuff – don’t even worry about what your app will look like. Only focus on the solution it can provide, and the most logical and practical way to facilitate that solution.

Market research

If you didn’t initially start with this step, you’ll want to do it now. You don’t even need a prototype of your app by this point – all that you need is your idea. Take that idea, and bring it to your target market. Talk with them about what they want. Go to networking events, conventions, local businesses, check out blogs, google “your idea + problems,” and most importantly, research your competition.

There’s 2 million apps on the App Store, and 2.6 million on Google Play – mathematically, it’s pretty likely someone has built an app that at least touches on the basis of your idea.

Your job isn’t to come up with an original idea – it’s coming up with the most optimal solution to that idea. If you’re worried about originality, don’t be – Homer’s The Iliad and The Odyssey covered every narrative trope imaginable – writers today just come up with ways to repackage those ideas.

Uber wasn’t an original idea – people had been flagging down taxis for a hundred years by the time Uber came along. When you boil Uber down to its core idea, all that it is is replacing a hand wave with an app – everything else is secondary. Instagram didn’t invent filters, it just made it easier to use filters to make your photos look better.

When you’re researching your competition, pay close attention to three things:

  • The UI/UX
  • The features it uses to solve the problem
  • The app’s ASO

Take from those three things the aspects you do like, and keep them. Replace what you don’t like with your own spin on things. Then, come up with how you can create a unique package for your branding. Remember – your idea, and even the features used to facilitate your idea, don’t need to be original. If you’re making an app that requires GPS and mapping, you’re inevitably going to implement location services during development – coding languages (and the methods for building app functionalities) were designed to be systematic and logical – not unique.

One more important aspect concerning market research – this is when you’ll want to decide what platform(s) you’ll use to build your app. Knowing which platform you’re building for will dictate every following step in the process of creating an app – and if you are building both an Android and iOS app version, you’ll need two dedicated development teams.

More about deciding which platform is best for your app:

Gather your resources

For you, this means finalizing your concept and your market research, and then finding a developer. Once you’ve settled on a developer, it’s their responsibility to determine your app’s feature set and the SDKs and APIs it utilizes to achieve your desired functionality.

Your feature set will be based upon user stories. User stories are detailed, step-by-step use cases of what a user will do during a session in your app in order to accomplish solving your pain point.

This is when it’s time to start planning out the design of your app. Some dev shops have their own UI/UX designers, some don’t. If they don’t you’ll need to do it yourself, or find a freelance designer.

App design usually begins with wireframes and color options (usually starting with the home screen and moving on from there), as well as planning out the UX of the main functionalities your app provides. Think of the inverted pyramid – start with the overarching themes, and slowly work your way down to the nitty gritty details. If your app has graphics, this is the step you’ll implement those – anything visual that your app requires should be complete before coding begins (if your app requires heavy backend infrastructure, start building that out as soon as possible).

For more information about proper app design, visit our blog on covering the topic.

From these designs, you can build out a prototype, which is actually much easier than you’d expect, via help from different prototyping applications:

Once you’ve signed off on a prototype, your development team can get down to actually building your app. A good developer will be able to take your plan and run with it from here – they’ll obviously check in to provide you with updates, and to make sure you’re happy with what they’re producing, but they won’t be asking you technical questions – that’s why you hired them, after all.

Testing

This is a step that begins after the first lines of code of your app are implemented, and after that, testing never ends. It might sound disheartening, but that’s the nature of the beast.

To efficiently test, lay out every step of your user stories (which you and your development team came up with in the previous step) in a spreadsheet, and identify the features that aren’t working properly. Take the time to make sure your app feels smooth and attentive to inputs as well. Users are likely to abandon slow apps in favor of faster ones.

Record every bug you discover while testing. Fix the issues, and test again. Repeat this step until testing is complete.

Then, it’s time for testing round two… beta testing!

Beta testing will open up your app to a small segment of the public – one that you, or a marketing agency (or your developer) will find. The purpose of a beta test is to increase the likelihood of catching bugs due to increased entropy. Beta testers, while not as detail oriented as a dedicated internal testing team, will use your app in the way they expect it to work – not the use case you have imagined. You’ll find out during this step if the two align, and iron out the kinks if they don’t.

Beta tests are important for another reason – it opens up your app to more devices and usage environments. Your app needs to work the same in a cornfield as it does on the subway. The text and font you used in your app may be legible in an office environment, but the sun’s glare might make it difficult to read. These are the kinds of details beta testing will pick up on, and improve upon.

For more information and tips about running a beta test, visit our blog covering the topic.

ASO

Before you launch your app, you’ll want to plan out your ASO. There are two fronts to your ASO campaign: user acquisition, and user retention, in that order. These can be broken down into sub-categories:

User acquisition:

  • Keywords
  • The app’s build and compatibility
  • The app’s actual page on the App Store (you can think of this as your app’s storefront)

User retention:

  • User reviews and ratings
  • Time users actually engage with the app
  • In-app purchases (if applicable)

Keywords are the bread-and-butter of any ASO campaign. The App Store’s search option functions in largely the same manner as a search engine like Google: users input a phrase or word, and the App Store displays apps based upon relevance and ranking.

Keywords are the foundation from which to build your ASO efforts, and effectively implementing them is crucial to your app’s success on the App Store. The most important steps you can take to ensure your keywords are working for you is to:

  1. Know your competition and
  2. Start with 2-3 keywords (as your campaign matures, consider utilizing up to five main keywords)

For more information about ASO, visit our blog on the topic. For more information about keyword research, check out our guide on the topic.

Launch

Congratulations! You’re almost there. The next steps are publishing your app, which will mean different things depending on what platform you want to release on. Both the App Store and Google Play have different approval processes and standards for apps to pass before they can be published, as well as publishing fees.

Apple has strict guidelines that must be met for your app to be approved – Android does not.

To publish an App on the App Store, you must pay a yearly fee of $99, and Apple takes 30% of profits from downloads (that 30% is only applied to paid app and in-app purchases). In order to publish to Google Play, you must pay a one-time fee of $25, and Android also takes 30% of profits from paid an in-app purchases.

Update

As soon as your app is launched, you’ll want to start analyzing your user data. In order to do this, you’ll need to find an analytics platform. This is a very detailed and intricate process, so for accessibility, we won’t include that information on this particular blog – but you can find all the information you need about measuring analytics here.

Based off of your analytics, user reviews, and user ratings, you’ll want to start coming up with ideas for how to enhance your app. From here, you’ll begin again at step one: ideation.

Android or iOS – which is the better MVP platform?

If you’re planning on making a MVP (minimum viable product) app, there’s a good chance your reasoning fits one or both of these criteria – time is of the essence, and/or you have a limited budget. No matter what your reasoning is, however, the benefits of a MVP app’s model of development boil down to one thing: efficiency.

So, other than the generalized buzzword of “efficiency,” what makes a successful MVP app?

  • Lower development cost
  • Shortened development time
  • Consistent, user-driven, and targeted updates
  • Reduced business development cost
  • Streamlined market release
  • Discovering and refining your revenue model through user engagement

Something to keep in mind when developing a MVP app – a MVP is not a prototype. A prototype, by definition, is a preliminary model of something; a MVP is everything (nothing more, and nothing less) that a product needs to both achieve the solution to a pain point, and simultaneously satisfy customers.

Or you can think of it this way; a prototype is what it will do. A MVP is what it does.

Now that we’ve got that out of the way, let’s get to the main question of this blog post – which is the better platform for a MVP app: Android, or iOS? It stands to reason that if you’re developing a MVP, you want to make sure the development and release of your product are as efficient as possible – and with that comes the need to know which market will be the most efficient for your MVP to live in.

Which is the better MVP platform – Android, or iOS?

When it comes to overall development costs, iOS wins every category other than publication costs and investment in infrastructure – the latter of the two categories is determined by your extant infrastructure (if you already own Apple products, iOS will cost less, and vice versa). While both Google Play and the App Store will skim 30% of profits made from paid app and in-app purchases, the App Store’s publishing fee is annual, whereas Google Play’s is a one time deal.

But there’s much more to efficiency than just reducing costs – this is about the best platform for a MVP after all – not the cheapest.

Development time

Development time is determined by two factors: ease of programming, and ease of testing. Again, when it comes to the time it takes to develop an app, iOS wins the round. Why?

Android is mainly programmed using JAVA – a computer language that saw its release in 1996. While this does mean there are more Android programmers available to hire, it doesn’t equate to faster development. JAVA was written to build websites, and was later adopted by the Android platform as its de facto programming language. Due to this, Android is highly customizable – but leaves room for development inconsistencies that tend to pop up because there aren’t strict standards.

iOS apps, on the other hand, are written with Swift. Swift was made specifically for the development of apps, as well as being designed to run on Apple products only. While this does limit apps built using Swift to devices that start with the letter “i,” it does ensure a much more stable development environment. With Swift, there’s usually a right way and a wrong way to implement a functionality – meaning there’s a lot less time spent trying out different iterations of code.

The same is also true for the time it takes to successfully test your app – again, iOS comes out ahead of Android. This is for two reasons: it is simpler to produce robust code with Swift, and there are less iOS devices than Android devices (this is the main reason for the discrepancy in testing time between the two platforms).

Between the currently used iPhone, iPad, and even Apple Watch and TV, there are about ten iOS devices to test your app on (and that’s if it’s used on their entire range of products). To achieve the same level of quality assurance for an Android app, you’d have to test on 24,000 different devices.

With easier to write and more robust code, paired with a smaller number of available devices to test on, iOS apps will almost invariably take less time to develop than Android.

User engagement

While user engagement is an important metric for any app, when it comes to the development of a MVP, high quality user engagement is essential to your success. This is because MVP apps are basically a shortened version of classic app lifecycle management – rather than building out every feature, testing, and then releasing, a MVPs necessary features are implemented, then the bare bones (minimal, but still very much functional) app is sent to market. After users begin using the app and asking for extra features, the development team then works to implement the requested additions to the app.

It makes sense as to why this method of development is so cost effective and efficient – rather than guessing what features your intended audience will expect from your app, you build the main idea, and give your users the power to fill in the cracks. This saves money and time on two different fronts: you don’t waste resources implementing unwanted features, and you spend less time and money conducting market research. Your users act as both your focus group and your test bed.

The caveat here is that in order for that to happen, your user base must be highly engaged with your app – much more so than the average app user. And this is where, hands down, iOS is the stand-out platform:

  • iOS users engage apps for nearly twice as long as their Android counterparts
  • iOS apps have a higher retention rate than Android apps
  • iOS users download more purchasable apps than Android users and spend more money on in-app purchases:

  • Gaming app average revenue per user: $1.99 (iOS) versus $1.56 (Android)
  • Shopping app average revenue per user: $19.64 (iOS) versus $11.49 (Android)
  • Travel app average revenue per user: $32.29 (iOS) versus $20.47 (Android)

It’s metrics like these that put iOS ahead of Android for the best MVP platform. Without high quality, consistent user engagement (as well as two-way communication between your development team and your users), your MVP will face a much longer road to achieving your goals. This isn’t to say MVP apps don’t work on Android, just rather that iOS lends itself better to MVP development.

We hope you’ve found this guide useful. If you’d like more information about deciding between Android or iOS, check out our blogs about how to decided which platform is best for your app, and which platform costs more to develop for.

How to build a mobile app: App lifecycle Management

App lifecycle management, which we’ll be referring to as ALM from now on, is the totality of managing the processes, systems, and people that make your app: market research, ideation, coding and design, testing, launch, analytics, and updating your app throughout its time on the App Store or Google Play.

Let’s explore ALM:

ALM

Step 1: Ideation

There’s two ways ideation can come about; from inspiration after being presented with a pain point in your own life, or from conducting market research which exposes a niche market with an unsolved pain point of their own. If it’s the former, make sure to conduct your own market research to determine just who exactly your niche is.

If you’re looking for ideas and methods for coming up with marketable apps, visit our blog on the topic.

Step 2: Requirements gathering

After solidifying your concept, you’ll want to develop out the requirements of your app – basically, what it does and how you want it to achieve those things. This covers everything from your app’s feature set to the SDKs and APIs it utilizes. Then, break those down sets and systems into individual, detailed tasks, so you and your PM can easily manage and track the progress of these tasks.

Your feature set will be based upon user stories. User stories are detailed, step-by-step use cases of what a user will do during a session in your app in order to accomplish solving your pain point.

You’ll also want to plan out which platform(s) your app will launch on, if you haven’t already. This should be partly influenced by your market research. Knowing which platform you’re building for will dictate every following step – and if you are building both an Android and iOS app version, you’ll need two dedicated development teams.

If you’re looking for more info about planning your app’s feature set, visit our blog covering the topic.

Step 3: Design

When you have a plan solidified for what your app will actually do, you can move onto design. Start with wireframes and color options on your home screen, and after settling on the right layout for your app, begin designing the other screens and how your users will actually interact with the functionality your app provides.

If your app has graphics, this is the step you’ll implement those – anything visual that your app requires should be complete before coding begins (if your app requires heavy backend infrastructure, start building that out as soon as possible). Make sure to build out a prototype so your software engineers have something to reference while they code.

For more information about proper app design methods, visit our blog covering the topic.

Step 4: Develop

This is where the actual coding begins. Your programmers should build the UI based on the prototype to ensure all of the requirements are met. Assign those requirements, incidents, and tasks to your team. For every incident that is completed, run tests to check for errors and vulnerabilities. After that iteration has passed a code review, add it on to your master branch.

For a lot more tips on avoiding development mistakes, visit our blog about common development pitfalls. For a guide covering iOS development, click here. For a guide on Android app development, click here.

Step 5: Testing

Create your test cases, which should be based on the user stories you came up with during step 2, requirements gathering. To efficiently test, lay out every step of your user stories in a spreadsheet, and identify the features that aren’t working properly. Take the time to make sure your app feels smooth and attentive to inputs as well. Users are likely to abandon slow apps in favor of faster ones.

Record every bug you discover while testing. Fix the issues, and test again. Repeat this step until testing is complete.

Step 6: Soft launch (quality assurance)

Sometimes referred to as a beta test, your soft launch will open up your app to a small segment of the public – one that you, or a marketing agency (or your developer) will find. They’ll use your app out in the field, so to speak. A soft launch can be thought of as the second step of testing, because it will inevitably uncover bugs and errors your first rounds of testing didn’t.

Optimally, you’ll have caught most of the bugs by this point, so your testers will have a high opinion about your app before it’s published (which gives you a significant boost to your app store rankings when they rate it after launch). They won’t be surprised, however, if they do find bugs – they understand that it’s a soft launch, after all.

You’ll bounce between steps five and six until all of your app’s bugs have been identified, fixed, and tested again. For more information and tips about running a beta test, visit our blog covering the topic.

Step 7: Deploy

Congratulations! It’s time to publish your app. Both the App Store and Google Play have different approval processes and standards for apps to pass before they can be published, as well as publishing fees.

If you’re looking for more information about the cost of publishing an app (and the other costs associated with development) visit our blog covering the topic. If you need help planning out your ASO campaign (which you should do before launch), visit our blog on the topic.

Step 8: Analytical review

Now it’s time to watch (and then react to) the data coming in. There are a lot of app analytics platforms, but we prefer Kumulos.

For a step-by-step, detailed guide to measuring your app’s success, visit our blog about measuring your app’s analytics.

For more information about coming up with ASO strategies, visit our blog on the topic.

Step 9: Enhancements

Based off of your analytics, it’s time to start updating your app with enhancements; enhancing your app’s UX by updating it’s design, security, and compatibility with other devices.

This is the step that glues the whole process together, and based upon the analytical data you’re receiving, you’ll ideate solutions for the aspects of your app that need to be enhanced.

The effects of not updating your app

Updating your app is the most important step you can take to ensure the time you spent developing your app (which in some cases can take years) doesn’t go to waste.

Updating your app is important for the following reasons:

App Trends

What’s cool is always changing, along with what’s possible. Updating how a feature looks or functions almost invariably results in a positive boost to your users’ experience using your app, which in turn leads to higher user retention, ratings, and reviews. Your update doesn’t always have to be centered around functionality either – sometimes it can be as simple as a background color change, which could be part of an A/B test you’re running.

Security

We all know there’s always someone looking for a vulnerability to exploit. Code that was once air-tight slowly loses it’s edge with time, and the longer your app goes without a security update, the more likely it is that someone with ill intentions will use that to their advantage.

This is an exceedingly important aspect to consider when updating your app. If a user is ever exposed to any security risk due to your app, they are virtually guaranteed to at least stop using your app, and are more likely to outright delete it from their device.

They’ll also be much more likely to give your app a bad review and rating, which can cause a huge dip in your conversion rates as your app plummets in its rankings on the App Store and Google Play. This can very quickly spiral into a downward trend that will be out of your control. Users who feel violated by your app will be sure to warn others about an app that is a security risk.

Bug Fixing

Even when you’ve tested your app throughly as outlined in the steps above, you’re bound to see bugs in your app over time. A major cause of these bugs popping up throughout the lifecycle of your app are due to new devices and updates to the OS your app runs on. As screen resolutions change, so to must your app – or at least, account for those changes.

In the same vein as security issues, bugs will also deter users from continuing to use your app. If you don’t care enough to update it, why should they care to use it?

Android development: What you need to know

Continuing from a previous installment of How to Build a Mobile App: The Ultimate Guide, we’re on to the next major player of the mobile market; Android!

If you own anything other than an iPhone, it most likely runs on the Android Platform. Mainly programmed using JAVA, Kotlin, and C++, Android boasted a global market share of 88% in 2018 (a growth of over 85% since 2009), and currently holds 36% of the US market. Just like our blog on iOS development, we’ll go over the information you need to know to make pragmatic decisions about Android development, and key terms to better communicate with developers.

Disclaimer: If you’re a developer or software engineer, there might not be any new information for you here. For a look into inventive strategies to boost your ASO, check out our featured piece on The Manifest.

If you’re a business owner, CTO, or marketing director, and you’re looking to hone your Android dev knowledge, or want to brush up on your developer jargon, you’ve come to the right place.

The Android platform has seen a meteoric rise in popularity since its inception – when Google Play first came on the scene in 2008 under the name “Android Market,” the platform was facing an uphill battle against tech giants Apple and Microsoft, who in 2009 both retained about 9% more market share than Android, which entered Q1 of 2009 with a market share of 1.6%, compared to the 88% it now holds globally.

Google Play now hosts over 2.6 million apps, and in 2016, Google Play announced users had downloaded over 65 billion apps in eight years.

The tools available to developers

Written using the programming languages JAVA, Kotlin, and C++ (among others), the Android Open Source Project (AOSP) is hosted on GitHub, and provides developers with access to 99 (and counting) open source repositories. A repository is like DropBox, but for code – it gives software developers remote access to different libraries of useful functionalities (which can also be called features). In the case of GitHub, these repositories are open and free to any member of the AOSP, but most developers will use their own private repositories as well.

A functionality is – in the simplest of terms – anything the app can accomplish. Does the app provide users with a map? That’s a feature. The map is GPS enabled? That’s another feature. The app provides users with next-step-directions in the form of push notifications when running in the background? That’s another feature.

If you’d like to learn more about feature sets and proper app ideation, check out our post on the topic.

Repositories are used to speed up the programming process by providing generic code structures that can be tweaked to fit an app’s specific branding and design.

A massive upside to Android development is its ease of access to software engineers – primarily due to JAVA acting as the flagship programming language when developing Android apps.

JAVA was first thought of in 1991, after all, and saw its first public release as JAVA 1.0 in 1996. As of 2016, it has been hailed as one of the most popular programming languages in use today, with 9 million developers reporting in, and is currently on its 11th version.

Kotlin, on the other hand, made its public debut in 2017, and is currently on version 1.3, which was released in October of 2018. Very new and relatively untested, Kotlin was designed to fully integrate with JAVA, and like JAVA, is an object-oriented language (meaning important information is stored in individual classes in the code itself), and seems to be a direct rebuttal to iOS’ Swift language. For an example of a class, check out our iOS development page.

With a new language emerging like Kotlin, it’s always fun to stay up to date on what’s coming down the pipeline; luckily, the Kotlin community makes it easy to stay in the loop.

Android developers, unlike those who work with iOS, have multiple compilers to choose from. A compiler is a program that software engineers use to write programs, and developers can choose from a number of compilers in which to write their code. For example, an Android developer could use Android Studio to write their code, or Intellij IDEA, or Eclipse (and many others).

The hierarchy of Android

There are four layers to the Android OS:

  1. Applications – This is where the native apps on your device, like your camera or text messenger, as well as any apps that have been download from Google Play, live in the OS. When an app is installed, it is stored in the aptly-named Application layer.
  2. Android Framework – This is layer that provides the tools developers use to make apps work – service functions live here: activity manager, package manager, NFC (near field communication) services, location services, windows manager, content providers, and view the system manager.
  3. Android Runtime – This is the layer that consists of the Android core libraries (the tools developers use to hook up JAVA with the Android OS), as well as the Dalvik Virtual Machine (DVM), a register-based virtual machine. For someone who speaks English, and not code, it’s basically a computer that lives in the OS itself, and ensures that the device the OS is on can run multiple instances simultaneously. Android Runtime is the foundation for the previous layer, Android Framework.
  4. Platform Libraries – Containing various C/C++ and JAVA libraries, this layer provides support for Android development. This layer contains functionalities like the media player, libraries for graphics, font support, and browser support – among many others (no one wants to read a list that long).
  5. Linux Kernel – This is the lizard brain of the Android OS. It manages drivers on the device, (think camera, audio, Bluetooth, memory), as well as memory management, power management, and other base-level management systems.

Those are the layers on the Android OS that provide the foundation, functions and space for your app to live and interact with. Now that we’ve got that out of the way, let’s move on to the building blocks of an Android app.

The building blocks of an Android App

There are five main components that make up an Android app:

  1. Activities
  2. Intents
  3. Services
  4. Broadcast receivers
  5. Content providers

Activities

Activities are how your users interact with your app. When a developer speaks about an activity in Android, they are usually referring to the multiple points of interaction on a single screen through the app’s UI (single screens in Android are referred to as view models, and they dictate the “box” that visual information fits into). Take, for instance, a device’s native phone app – there are separate activities to dial a number, view recent and missed calls, and voicemail. All of these activities are separate from each other, and are considered distinct activities unto themselves – but they all work together as a whole to help the user achieve their goal.

Activities in Android are designed to keep track of what the user is currently doing, the processes that keep track of the features users are engaging with, and “killing” the processes that are no longer necessary for the user at the moment.

When an activity is killed, its current state is saved, in case the user comes back to that activity. This ensures that memory is both freed up for current processes, but the processes in the background remain quickly accessible to the user.

Within activities are fragments, which can be thought of as sub-activities. Fragments can be interacted with just like an activity, but they are specialized – they give your app’s UI the ability to adapt to different device screen sizes, as well as the ability to produce a more dynamic layout. If you know HTML, it’s basically the same idea as building a responsive website.

Intents

Intents function as the messengers between the components that make apps work. They are used to take the necessary information from one component of an app to the next, in order for that component to do it’s job.

If that was a little confusing (which it is, I don’t blame you), think of them as an alarm clock. An alarm clock wakes you up and tells you what the current time is – the information you need in order to start acting to get out of bed and get on with your day. Intents “wake up” app components, and let them know it’s time to get out of bed.

The most important part of intents is making sure your code uses clear naming conventions – an intent needs to match with the names of components it needs to interact with, and if the names don’t match, it won’t be able to find the component it needs to deliver the message to.

For an example of naming conventions, let’s pretend there’s a turtle. The turtle sees a coyote. An intent is sent from TURTLE_CRAWL to TURTLE_HIDE. This changes the action the turtle is taking, just as an intent will change what action the app is taking in order to properly interact with the user.

There are two types of intents: implicit and explicit. Implicit intents are used to send information from one component of one app to another component of a separate app. Explicit intents are the direct opposite – and are used to take information from one component of an app and use it to invoke another component of that same app.

Services

Services are what keep the functions of apps running in the background, and are broken down into two categories: started services and bound services. A started service, for example, is used to run some sort of function in the background, until the user stops the function; this would be used to allow a user to listen to music from one app, while engaging another app at the same time.

A bound service is kind of like one app giving another app a helping hand – these basically tell the system to not kill the function the two apps are sharing, and as soon as the function has been completed, it can be killed.

Broadcast receivers

Broadcast receivers are aptly named, and serve as the proverbial loudspeaker for a device. Probably the most well-known (and dreaded) broadcast receiver is the “low battery” notification.

When a user downloads an app onto an Android device, the OS will assign that app a unique Linux user ID (Android’s foundation is a Linux kernel), and all apps run on a virtual machine (a simulated computer that exists as its own entity on the OS), so each app runs in an isolated environment from all other apps on the device.

This is called the principle of least privilege. This means that each app can only access the functionalities and data it needs to complete a task, and nothing more. This provides an extra layer of security, as apps are unable to share data with each other, and can only access the systems they need to work.

Broadcast receivers usually function with the help of the previously-mentioned intents.

Content providers

Just as the Android OS has libraries that help it function, so to does an individual app. The libraries, named content providers, house the information of that app, so other apps can access that information in order to function properly.

Think about how when someone texts you an address, you can click on that address to open it in Google Maps. In order for your map to display the address that was texted to you, your text messenger app stores that information in a content provider, which Google Maps can then access and display.

The manifest file

After you’ve made your app, all of the components of your app (activities, intents, services, broadcast receivers, and content providers) must be stored in what’s called the manifest file. The manifest file is the folder the Android OS searches through in order to find the components that make your app run. In short, for a device to know that an app component exists, that component must be stored in the manifest file.

Think of it as the roadmap the system uses to run an app – it tells the OS where to go and what to interact with. It also identifies permissions the user has set within the device, declares the hardware features an app needs to run, and the APIs it needs to be hooked up to.

Where to go from here?

The next steps to take are beta testing and then publishing, which comes with its own costs (a one time fee of $25 for Google Play) in addition to the other costs that can be expected while developing a mobile app.

We hope you’ve found this guide to Android development helpful! Below, you’ll find a glossary of commonly used words regarding app development.

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.
  • Front end: This is the layer of the app that users interact with.
  • Iterate: To perform a certain task or function repeatedly.
  • 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.
  • 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.

App development pitfalls

When you’re building an app, it’s much more important to know what not to do than it is to follow a step-by-step checklist that lays out the path to success.

There’s a good reason for this – every app’s path to success is different, and something that’s right for one app could be completely wrong for another. The number one rule to successful branding is to differentiate yourself, and apps are no different. If you’re doing the exact same thing as a competing app, there’s no reason for users to try out your own.

That’s why this blog isn’t going to focus on what to do, but rather what not to do when developing your app.

Development pitfalls

Here’s what you shouldn’t do when building your app:

Make on-boarding difficult

When a user opens up your app for the first time, you want to make a good impression. The home screen of your app should instantly display the value of the app to the user – this can be achieved through obvious symbology in your navigation bar, or a quick, quippy, and enticing sentence that sums up what the app does.

Always make on-boarding achievable in the least possible amount of steps – you want users interacting with your app’s actual features, not spending time setting up accounts. Speaking of accounts…

No alternate options for logging in

If your app requires users to sign in, give them multiple options to do so. Some users will prefer to sign in through a social account, as it’s usually quicker than setting up a native account through the app.

Other users, however, prefer to set up a native account through your app, for many different reasons – some of those being security-minded users that don’t want your app to access their social data, or users who don’t have social media accounts.

Those who sign in with social media and those who don’t are both significant groups, so you want to make sure everyone has access to the option they prefer. Also, make sure you have enough social media options to link to.

Asking for payment info too soon

If your app requires access to a bank account, credit card, or online payment service like Stripe, don’t ask your users to input that info immediately after opening your app. Only request this info right before a payment must be processed. If you give users a chance to navigate through your app and figure out its value and the services it offers before asking for personal payment information, they’re much more likely to stick with your app.

For more info about asking for payment info and the effects it has on user retention, check out our blog on the topic.

Not conducting market research

Remember: just because you like your idea, it doesn’t mean everyone else will. Just like any product, apps must be based on market research – if there’s no one interested in your app, there’s no market to grow into.

More specifically about market research…

Not finding a niche

Like we stated above, the number one rule to branding is to differentiate, and it’s no different for apps. To quote Marty Neumeier’s Brand Gap, “when they zig, you zag.”

Conducting market research to determine what type of app people would be interested in isn’t enough – plenty of people are interested in ridesharing – but there’s already plenty of apps that have saturated this market. Think about how Spotify differentiated itself from Pandora – it’s a music streaming service, but while Pandora brings the music to you based on one band, with Spotify, (at least originally) you find the music you want to listen to.

These differences in design appeal to different audiences, which is exactly what you want to do. Lyft didn’t try to take away satisfied Uber customers, they researched the segments of users that were dissatisfied with Uber’s service, and then found out what they wanted. Then they did that.

Find a niche, and cater your app to their needs and wants.

Copying competition

As Nick Jones, NS804 CEO says, “Do your one thing and do it well.”

While it’s extremely important to keep track of what your competition is up to and how they’re doing it, it’s so you can take what works and then mold it to your own brand. If you’re outright copying, users will notice, and they’ll ask themselves “why don’t I just use the original app?”

Know what your competition is doing so you can capitalize on their good ideas and then head in your own direction. Stick to your tribe.

Trying to accomplish everything

To reiterate the point from above – it’s always better to do one thing well than it is to do multiple things mediocrely. Find your niche’s pain point, and then focus on solving that, and nothing else. Figure out ways to streamline the solution you provide. Every feature your app utilizes should in some way provide a benefit to solving your niche’s pain point.

By allowing your app’s scope to creep past your original idea, you can spell the doom of your business – for each feature you add, you add to both your time and cost invested into your app. When first starting out, provide the minimum amount possible to truly solve your niche’s pain point, and nothing else. Once your app is gaining traction, then you can go back to the drawing board and figure out what to add (but make sure the features you add still revolve around the main purpose of your app.)

For more tips on avoiding scope creep, check out our blog on the topic.

Not considering the use case

It’s easy to say “I want to make an app that helps connect people,” but what’s difficult to imagine is the way they will actually use it. When you have a vision or a brainchild, it’s not only difficult to throughly communicate your idea to other people, it’s also challenging for them to use it exactly the way you imagined they would. Everyone’s a little different, and because of this, use things in different ways.

There’s a few things you can ask yourself to help figure out what your app’s use case will be:

  1. When will the user open the app?
  2. Where will the user be when engaging with the app?
  3. What solution will they expect?
  4. How much time will it take to complete a session in the app?
  5. What problems will they run into while using the app?
  6. What corners will they try to cut while engaging with the app?

The more specific and narrow you can get with these questions, the better. Figuring out the answers to these questions can be achieved by through testing.

Multi-platform launch

If you’re making a hybrid or progressive web app (which we don’t recommend), this won’t really matter – but if you’re investing the time and money into native development (which is the more substantial option for long-term app growth), it’s much better to focus on one platform. This is for a few reasons:

  1. Android and iOS apps are built using different coding languages
  2. Each platform requires its own dev team, as well as its own round of beta testing
  3. For every platform you release your app on, you increase your post-launch costs
  4. Each native app requires significant time to build

Choose one platform to focus on in the beginning – once you have a substantial user base, and have a steady stream of income, then think about venturing to the other platform.

Not considering different markets on different platforms

This is another reason natively-developed apps are better than hybrid – Android and iOS users expect and interact with apps in different ways. From style guides to user culture, Android and iOS apps are very different in their methodology and feel. The market research findings you make about iOS users will most likely be different than the insights you make when speaking with Android users – even when your app ultimately functions the same on both.

If you’re having trouble figuring out what platform would be best for your app to launch on, check out our blog about deciding which is best for you.

Insufficient beta testing

While testing adds more time and cost to your initial development cycle, it ultimately saves you time, money, and headaches in the long run. Testing should be conducted continuously throughout your development cycle – test your app after every new build and iteration.

Users are fickle and will abandon an app for almost any reason – you don’t want to end up dealing with low user retention because you skipped this important step.

For more information about conducting beta testing on your app, check out our blog about it.

Ignoring A/B testing

Yup, there’s more testing you should be doing! If you’re unfamiliar with what A/B testing means, it refers to switching out one piece of data with another to see how it performs with users. For example, what happens if you switch the color of interactive buttons from blue to green? What if you switch the icon of your app in the app store to a different one?

To successfully conduct a round of A/B testing, you need to have a firm grasp of your analytics both before and after the change – then compare the two values to figure out which version is more effective.

Speaking of…

Not checking analytics

There’s nothing glamorous about analyzing data, but if you’re not, it’s like driving a car, down a mountain, with no brakes all while blindfolded.

That might seem like a bit of a hyperbole, but analytics is more than your conversion rate – platforms like Kumulos provide information about errors and crashing, what types of devices and platforms users are accessing your app from, what time of day they’re engaging with your app, and even what country or state they live in.

Knowing how your app is functioning among it’s niche is crucial and necessary to its continued growth and retention.

Putting user acquisition over user retention

It’s easy to get excited over your download rate – after all, if users aren’t downloading your app, how will they interact with it? While acquisition is incredibly important, retention is even more so. It’s the same rule as in sales: it’s always cheaper to retain a client than it is to find a new one.

Your efforts should always focus on keeping your returning users happy – if they’re happy, they’ll provide your app with positive reviews and scores, which will boost its rank on the app store, which in turn will lead to a higher conversion rate. Remember – word of mouth is the most powerful and effective marketing tool.

When you make your current users happy, they’ll do your marketing for you.

Not interacting/engaging/updating

There’s nothing creepier than a ghost town, and your users will notice if your app becomes one. Regularly update your app – this shows your users that you care about their experience with you app, and it also serves as a reminder that your app exists, and there’s something new to check out.

If a user leaves a review, respond. People like being heard. Use push notifications and proximity marketing to add different channels of user engagement to your app’s repertoire.

No post development plan

App lifecycle management is crucial to your app’s growth and success. To properly manage your app’s lifecycle, you need to focus on:

  • Keeping track of your competition
  • Providing major updates to UI and security
  • Offering additional solutions through your app
  • Adapting to current trends

When it comes to anything that works on code, development is never truly over. For your app to stay relevant, you need to show your users you’re ready to adapt to our ever-changing world. Those who stay still get left behind.

Expecting immediate ROI

Your app won’t immediately start making money after it’s published to the app store. Plan in advance for this – the first phase after launch is implementing your ASO campaign. It’s when users are engaging with your app that you’ll begin to see a profit, and no earlier.

Not considering hidden costs

Remember – publishing to the App Store and Google Play requires a publisher’s fee. The App Store’s fee recurs annually, and Google Play’s is a one time deal.

Hosting the backend of your app will have recurring costs (usually monthly) and your analytics platform will also be a recurring cost (usually monthly as well).

For more information about the hidden costs of developing an app, check out our blog on the topic.

Follow your own path

We hope you’ve found this list of what not to be helpful. But always remember one thing – if it works for your app, it works. Don’t worry about fitting the mold – be different, and be daring.

How to build a mobile app: App design

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:

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.

How to communicate with developers

We are recognized as a top App Design & Development Company on DesignRush.

The wind blew across the blue waves, and set the tone of the day: blue. There is a downed tree in their yard, I wonder when they’re going to take care of it? Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.

Language is an imprecise tool – especially when you’re attempting to communicate abstract, involved ideas and concepts. Language barriers aren’t just limited to foreign languages – they’re present amongst different professions as well.

Take, for example, the muddy waters of acronyms (which tech is rife with): A chemical engineer is talking to a software engineer about APIs. The chemical engineer thinks they’re speaking about Active Pharmaceutical Ingredients, and the software engineer is thinking Application Programming Interfaces – they’re both engineers (admittedly in very different fields) but they’re talking about completely different subjects, all while using the exact same acronym.

This game of telephone is compounded when two (or more) people who work within completely different schools of thought are communicating the intentions of their ideas. We’ve all been trained to think in different ways, depending on our type of profession: writers live and die by the five w’s and the upside down pyramid, while graphic designers think in the rule of thirds and adhere to visual hierarchy. Mechanical engineers live and breathe f=ma and deal with safety regulations while physicists work with… well, who really knows? You get the idea.

Okay, okay… just one more. A software engineer is sent to the grocery store with a set of instructions: “Buy a carton of milk, and if they have eggs, get six.” The engineer comes back with six cartons of milk. The person who sent them to the store asks, “why did you buy six cartons of milk?” The engineer replies, “They had eggs.”

How to break through the barrier

The first thing to keep in mind (and this is very important) is that software engineers are people too. As much fun as it is to pretend like they’re robots, they have feelings just like you and me – and communicating with them as such is crucial to a successful development cycle.

The easiest way to get around miscommunication is to accept it will happen – and plan for it in your development schedule. There’s a lot going on during mobile app development – a UI designer will look at a project one way, while a programmer will look at it from a different lens, and a project manager will have a unique perspective as well.

Treat your people like people, and you’ll already be miles ahead.

Be organized

It doesn’t matter what tools your team uses to communicate with each other and keep tasks organized – all that matters is you do it. There’s a bunch of project management platforms out there for you to choose from, but it’s important to pick the one that fits your team’s needs and preferences the best.

We like to use Trello, as we can keep track of an entire sprint and the tasks that make up the sprint in an easily digestible format. Our project manager will break these tasks down into individual features that need to be implemented, with specific details of what the final product should be – the flow, the visuals, and the information that must be included.

It’s important to make a distinction here – a project manager doesn’t tell the software engineers how to implement a feature – just what features need to be implemented where. A good project manager can admit they aren’t as technically savvy as the software engineers (unless they were originally a programmer), and will communicate that to their dev team. A good project manager should also know every use case scenario, every step of the app’s process and it’s flow, and it’s entire feature set.

Our project manager rarely fields technical questions – most of the questions software engineers will ask are more about clarification than “how do I do this?” Questions you can expect from developers will be:

“Where should I place the quotations in the text field?” Or, “What font should I use?”

It’s best to provide every piece of information every time. Don’t worry about making your lists pretty – software engineers aren’t worried about that. What they’re concerned with is getting things to their exact specifications. If your project uses multiple fonts, denote which fonts should be used where for each and every task. If you need an to turn 50% opaque after being interacted with, include that information in the task.

There’s no such thing as “over describing” when it comes to code. Say what you mean in the simplest terms possible, repeat information whenever necessary, and communicate exactly what you want and expect. The less wiggle room, the better – be direct.

Code iterations can become repetitive – if you have a sneaking suspicion that you and a software developer are speaking about two different features, clarify. Programmers love clarification.

A picture is worth a thousand words

A prototype is worth a million. If your software engineers can actually analyze what the final product should look like, and how it should act, they’re much more likely to implement your concept correctly. Just like project management tools, there’s a lot of prototyping platforms out there. We prefer to use Invision.

It’s good practice to keep track of your assets by assigning a universal naming convention, i.e. “homescreen_header.svg” rather than just “header.svg”. This will help your developers keep track of what goes where. Checklists are a big help here.

Don’t be afraid to use sketches either – they don’t have to be pretty to get the idea across. Use every medium available to you to express your idea before development gets into the swing of things. Use flowcharts to help software engineers keep track of the flow of the app.

Know your project

Top to bottom, front to back. The more you know about your project – the better. Software engineers don’t have the answer to everything. The work they do might seem like magic, but a lot of programmers are very specialized – a front end developer might even have less knowledge about backend logic than you!

The key to good development is to build a good relationship with your software engineers – and this is achieved by clear and concise communication.

Measuring your app’s success – with Kumulos

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
  6. Managing your ASO with Kumulos

    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.

    Kumulos

    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:

    Kumulos

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

    Kumulos

    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

    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

    Kumulos

    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:

      Kumulos

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

      2. Audience

      Kumulos

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

      Kumulos

      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:

      Kumulos

      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.

      Kumulos

      Push

      Kumulos

      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

      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

      Kumulos

      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

      Kumulos

      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!

All about beta testing: When, why, and how

There’s no harsher reality than facing criticism about something you call your own, especially after investing time and resources into your brainchild. This is, however, a crucial step to the success of any business venture, and doubly so when it comes to the app development cycle – and by facing the music before launch, you can jumpstart your app on its path to success.

Marketing companies use focus groups, manufacturers meet standards with quality assurance, and software developers rely on beta testing.

What is beta testing?

There comes a time in every app’s cycle of development where it’s mostly put together, and it’s ready to test its wings. Before its inaugural flight, however, it’s a smart move to have a dress rehearsal in order to identify bugs. This is the purpose of a beta test; it’s a limited release of your app (as its most current, nearly-complete version) among a select audience, with the expectation of receiving constructive criticism about your app from that audience.

It’s an integral but over-looked facet of software development, and while this does add another step to the app development cycle, it ultimately reduces cost, cuts time spent debugging, and serves as a testing ground for future user acquisition and retention strategies.

Below, you’ll find a bunch of reasons detailing why beta testing is important, what you need to know in order to successfully run a beta test, and who to include in your app’s beta test.

Improve your app’s quality

Most developers have their own app testers, and software engineers and project managers will also test builds after every sprint, but there is one major issue when it comes to a dev team testing their own app: they know the ins and outs of the build, the exact specifications of the app’s intended use, and every aspect of the app’s flow. While it’s important to have the team test their own work, it’s virtually essential to bring in outside perspectives in order to catch every snag and bug.

Different testing environments: When you open your app to beta testing, you gain access to a wide variety of devices and usage environments through which to test your app. This is important because your app might not work or display the same way on a Galaxy when compared to a Pixel, just like how a website can look different depending on what browser you’re viewing it in. The actual environment a user is in can also affect the functionality of an app – especially if it requires a wi-fi connection. Your app must work the same everywhere, regardless if the user is in a sub way or a corn field.

Bug detection: The more people that are involved in testing, the greater a chance of a bug being caught. This is because the user base involved in the beta test won’t follow intended user paths as readily as your own dev team, due to lacking the familiarity your team has with the app from actually building it. Its like the difference between an artist explaining their work, versus someone else describing how it makes them feel – while the artist might have a more intimate connection to their piece, what really matters is how their audience feels about it.

There’s something to be said about making something yourself, whether it be a meal or piece of art. There’s nothing like coming up with an idea and executing it from inception to completion, all on your own.

A lot of developers will pay to have a dedicated tester for this very reason, and launching a beta test of your app is essentially adding hundreds (sometimes even thousands) of testers for free.

Improve user friendliness: Not everyone thinks the same way – and that’s a good thing when it comes to beta testing. By bringing in extra pairs of eyes into the testing of your app, you get a clearer picture about how your users will actually interact with your app. Steps in your apps flow might have seemed clear to your development team, but might not be to your beta test users, and it’s always better to rework your app’s flow before its true launch. Users are naturally more forgiving during beta tests than they are with finished products, so they are more likely to give feedback when confused, rather than just abandoning your app for another.

App performance (tech stack): During your beta test, you can analyze different aspects of your app’s performance, the first being the technical side of your app. By looking through multiple user scenarios, you can see what functionalities are used, and which are ignored. If possible, either take these ignored features out of your app entirely, or reduce them to the aspects that are actually being used. Reducing the overall size of your app is important, as 25% of smartphone users have deleted an app from their device solely to free up storage space.

You can also test for crashes and other app-breaking bugs, another big detractor from your app’s user retention.

App performance (user behavior): The second aspect of app performance you can analyze is your app’s user behavior. Despite mapping out the obvious aspects, like user flow within your app, you can analyze other trends, such as the daily, weekly, and monthly patterns of user retention. By figuring out the rate of engagement within your app, you can set a schedule of push notifications, and try it out, all during the beta testing. This will take away some of the burden of creating your ASO campaign.

Reduce cost

It might seem a little backwards, but adding in the extra step and taking the extra hours to conduct beta testing actually reduces the overall cost of making an app. This is for two main reasons:

  1. Speeds up the publishing and app launch process
  2. Reduces overall testing time

Both the App Store and Google Play have rules for publishing your app, and the App Store has an actual app review process. If your app doesn’t meet certain guidelines, it will be denied, and you’ll have to go through the process all over again, which delays your app’s launch, therefore increasing the chances of a competing app getting to market before yours does.

Beta testing also reduces your time spent testing your app – this is because you iron out all the kinks in one fell swoop – rather than testing being staggered and dispersed over the course of weeks, or sometimes even months. When you have your entire team (as well as a dedicated user base) focused on the testing of your app, you can dedicate more resources and developers to identifying and fixing issues before launch – rather than launching first, and then attempting to fix issues that are hurting your app’s reputation, all while working on the development of another app.

Increase your potential for growth

Beta testing can increase your app’s growth potential in two ways:

  1. Word of mouth advertising
  2. Boosting your app’s ASO by building a dedicated user base before its actual launch

When users are included in a beta test, it makes them feel special – it is exclusive, early access to the app, after all. Early adopters tend to be more engaged with apps than regular users, and are more likely to view your app favorably, as they will witness the app grow to accommodate their criticisms. If you listen carefully, and implement changes based off of your beta testers’ feedback, they’ll form a strong bond with your app, and are much more likely to advocate your app to their friends than if they found it naturally. Beta testers will sometimes tell their friends about a new app they get to use before everyone else, instilling feelings of envy among potential users. When your app is actually published, those users will immediately jump on board.

A huge portion of your app’s ranking on the App Store and Google Play is determined by user ratings and reviews. While users can’t review or rate your app during its beta testing phase, they’ll be ready to review and rate it on day one of its actual release. Rather than slowly building up ratings and reviews after launch, you’ll have multiple from the beginning, giving you an extra boost, and helping to differentiate your app from competitors. New users are much more likely to download an app if it already has ratings and reviews, giving you another leg up on increasing your user acquisition – which increases your app’s rank, and provides the foundation for an upward trend of growth.

You can also pay attention to the language beta testers use, and implement popular phrases or words as keywords for your ASO campaign.

Who you need

It’s important to include the right people in your beta test – you’ll want a mix of users who are well-versed with your app and those who are new to it, as well as technically proficient users, and not-so-technically savvy users. The most important audience to include, however, is the community you intend to engage the most with.

From your own development team, you’ll want to include:

  • Product managers
  • Sales staff
  • UX/UI designers (preferably those who haven’t worked on you app)
  • Quality managers
  • The developer’s dedicated app tester(s)

Externally, you’ll want to find:

  • Early adopters
  • The community your app is intended to engage with

Social media is a fantastic way to find (and engage) your app’s intended audience. Reddit is, perhaps, the best place to find your tribe, however. Say, for example, you want to run a beta test for AnswersNow, an app that connects autism experts with caretakers, and helps the caretakers provide better care by answering their questions in real-time.

By going to Reddit and searching “autism,” you can find r/autism, a ten-year-old community with a user base of over 40,000 subscribers. When you directly engage with a community like this, you’ll usually find more people signing up for your beta test than you have spots to fill, and the community will be especially forthcoming if you’re giving them early access to an app that provides a solution to a pain point in their daily lives like AnswersNow does.

When to beta test

There’s definitely a right and wrong time to beta test. Too early, and your testers will abandon your app due to lack of functionality. Too late, and there’s hardly any benefit to the actual testing – the more complete an app is, the more difficult it is to implement changes to its code, UI, and UX.

You’ll want to implement your beta testing when your app has enough functionality to test 90% of scenarios from start to completion. For example, if you’re running the beta test for AnswersNow, you’ll definitely want to make sure the chat functionality of your app works, as that’s the backbone of the app. Quality of life features and elements like graphic icons don’t necessarily have to be there yet – but your app should at least have a logo. Think about a dress rehearsal versus an actual play; during the dress rehearsal, costumes aren’t used, and every actor knows their lines, but they can always ask for help if they forget. During the actual play, everyone is dressed up and 100% ready to go.