How to: Get a low cost app developed

What’s the key to low cost mobile app development? Preparedness. But how are you supposed to know how to prepare if you’ve never built an app before?

Well, as soon as it began, your search is over – below, you’ll find a step-by-step guide to the quickest and most affordable model of mobile app development: MVP.

Really quick – before we get into it, let’s go over what a Minimum Viable Product is (when it comes to apps, at least). A MVP is an app that focuses on solving its main pain point, and very little else. All features, design, and graphics focus on helping to provide a solution to the main pain point – hence the term “minimum.”

MVPs do one thing, and they do it well.

Now, here’s how you make one:

Step 1: Research

This is all about how to build an app for the lowest cost possible; and the key to all development costs boils down to one singular ingredient – time.

Your app’s design is crafted through a combination of creative thinking, mouse clicks, and keystrokes; your app’s code is built by process-oriented imagination, and a whole lot of keys being pressed in rapid succession on a keyboard. There’s nothing magical about the development of an app.

Now, this isn’t written with the intention of giving the impression that developing an app is easy – quite the opposite, in fact. Building an app is kind of like writing an interactive choose-your-own-adventure novel, but it’s written in a language computers can understand, while also remaining readable for us humans.

And in order to pull that off in a streamlined, cost-effective manner, you need to complete all of your research before going to a developer with your app.

Find out why we recommend against using services like Appy Pie or app design templates to build your app.

The first step to research is…

Determining your pain point

All apps are beholden to one goal: solving their pain point. For a MVP to be a MVP, however, it must only provide the solution to its pain point. Any feature included in a MVP app must play a role in helping to solve this problem – this is to ensure no time is wasted spent developing out features that aren’t truly needed for users to receive enjoyment and benefit from your app.

The reason this is your first step taken on the road of app development is because everything that you do during the development process will be determined by the pain point of your app – from the market research you conduct to the features your developers implement.

A good pain point is both marketable and actionable – meaning there’s an audience or group of people who want a solution to this particular problem, and are willing to do something about said problem.

Let’s say you’re making an app like BrewTrader – just for some context, it’s an app that gives craft beer enthusiasts a platform to find and trade beers with other users.

Take a second to analyze that sentence. You know you’ve come up with a good pain point when you can explain the whole idea of your app in one sentence. Think of it like a thesis statement; if you can’t construct a grammatically correct sentence that covers the entirety of your app’s functionality, your MVP isn’t focused enough. It should be succinct, but meaty.

After knowing the problem you want to solve, and how you want to help solve it, you can move on to the next step of research:

Competitive analysis

This step serves two purposes – it gives you an idea of what your competitors are currently doing (obviously) – but more importantly, it will serve as a roadmap for ideating your app’s feature set.

If you want your app’s development to be quick, (and therefore low cost), you’ll need to know every feature your app will utilize; this includes knowing details like where in the user flow a feature will exist, how it will interact with the user, and if you’ll need supplemental features or APIs in order to properly implement the original feature.

Download the top three competitors and use their apps for at least one session from start to finish. Get an understanding of what they do correctly, and make a note for later. Then, go find the lowest rated app (be careful about security risks) in the same category, and pay attention to what they did wrong.

Knowing what’s incorrect is just as important as knowing proper UI/UX design. It helps to prevent you from making a decision that might seem like the makings of a previously-unimagined and creative UI/UX solution – but there is more than likely a reason the top performers use the UI/UX flow they already have.

Also, begin your ASO research now – pay attention to keywords the top competitors are using. When starting out with a new app on the App Store or Google Play, pick five keywords, and focus in on those.

Market research and marketing

There’s a million different options for conducting your market research, but some key data to be aware of are:

  • Target age range (different age groups respond to different mobile marketing strategies)
  • Target preferred platform (we recommend iOS if you’re starting with a MVP)
  • Target interests

As soon as you know what your app will be called, you have a logo, and you have a description of what your app will do, build a website. Even if you only have content for one landing page, make it, and make it live.

SEO takes a while to take hold, and having something to link back to within your social campaigns will help to build a solid SEO foundation. Apps on the App Store and Google Play require both SEO and ASO to thrive – so don’t neglect either.

Speaking of social media, you’ll want to make sure you’re putting out as much content as possible. Speak to the voice of your app’s brand, of course, but don’t be afraid to open up a little. Everyone understands that when they’re interacting with a brand’s social media account, they’re talking to an actual human being.

Be open and honest and genuine – know your target audience’s interests, and speak to them. To steal advice from Gary V, if they like the Red Sox, talk about the most recent Sox game. Engage with your followers more than you advertise to them. Then, every once in a while, sprinkle in some native content that speaks about your app’s brand, or the features it will provide, or where you are in development.

People love documentation. You can easily create content for social media by documenting the journey you’re on through the development of your MVP app – take one long-form piece of content, and build a few pieces from it each day. Then cater those pieces to each social platform your brand is on. All of a sudden, you’ll be running a fully-fledged social campaign based on a single piece of content (that you didn’t even have to take time out of your day to make).

MVP development

Whether you’re developing an MVP app or a fully-kitted-out enterprise level app, the actual process of coding remains largely the same – the only difference is the time table, which is shorter with a MVP, due to the limited feature set that needs to be built and implemented.

The importance placed on knowing your feature set in and out comes into play here – the most effective and efficient way to ensure easy, low cost app development is to make sure there’s no unanswered questions between your vision, what you want, and how you want it to work.

The clearer of a picture you can give, the more information, and the more concrete of a user flow you can produce for a developer, the better. It’s always important to take your developer’s advice, but relying on your own research and business acumen can help speed up the process.

One thing to keep in mind with (and this is specific to) MVP development is that everything doesn’t necessarily have to be perfect. Don’t confuse this with the idea that it’s okay to make a sloppy app – but understand that as long as your users know that your app is in a semi-beta stage, they’ll be more forgiving.

This is why a strong, personal, and open social media presence is so crucial to a MVP app’s success; in order to properly distribute the message that your app is starting with humbler-than-most beginnings (but improvements will be coming), you need to be able to have frank, honest, transparent conversations with your followers. And, they need to be willing to listen.

The purpose of a MVP app is fast, efficient development – the efficiency truly begins to shine after a MVP app’s initial development.

The second word in the acronym MVP is viable. It might be the most barebones version of a product, but it’s still viable. What this means for you is that you can charge for it. Whether your app goes with a pay-to-play model, or subscription to a service, or with sales from ad revenue, you can begin to make a profit from your MVP as soon as it takes hold on the App Store or Google Play.

Post MVP development

As soon as your app is launched on the App Store or Google Play, make sure:

  1. Your ASO is in place and ready to go
  2. Your website reflects the launch of your app
  3. Your social media has (and will continue to) promote your app’s launch

Take the revenue you’re making from your live MVP app, and start implementing updates. Make sure updates focus on fixing bugs, fixing security risks, and providing quality of life improvements to the UI and UX flow.

Be vocal and transparent about what your updates will accomplish and feature – use both social media and push notifications to advertise these updates.

Be aware that when you’re advertising, you need to be extremely aware of just who you’re engaging with. Older generations, like generation X, prefer value-based advertising. As your target market gets younger, they will expect more personalized advertising – in order to properly do this, it’s necessary to use an app analytics platform. Our favorite is Kumulos.

Be prepared, but be ready to adapt

Knowing what you’re getting into is the most important step you can take to ensuring low cost development – but, always be ready for something unexpected to pop up.

To learn more about the in’s-and-out’s of MVP app development, check out our blogs on:

And, for more about planning out an ASO campaign, check out our ASO: 101 blog post.

With carefully planned feature sets, a concrete layout and vision, and some well-planned and executed social media, SEO, and ASO, you can both shorten your app’s development schedule, and lessen your need for monetary investment; giving you the ability to make an app now, and capitalize on an untapped market – rather than waiting for outside investment and finding a highly competitive and saturated playing field.

How design impacts mobile cost

Did you know a full service development shop will put, on average, 100 to 120 hours into designing an app’s UI/UX? That’s a significant amount time – and when dealing with large scale apps, such as social media platforms – or even larger design projects, like mobile games, design hours can skyrocket into the thousands of hours.

Let’s look into why this is.

The process of designing an app

There’s a step-by-step process most mobile design teams will follow, starting from even before rough sketches. This process dictates the workflow from the first hours of working on a project all the way to building the UI/US itself in the actual code of the app.

Let’s go over those steps:

Doing your homework

First things first, do your research. Designers will usually spend at least a few hours looking at apps that exist in the same space as the one they’re about to design. This is done for a couple reasons; there’s no point in reinventing the wheel, and it gives designers a good grasp of what app users have already come to expect from apps in the same category.

With this information, designers are able to take what works from those competitors, and after critical analysis, determine what they can improve upon, or what can be changed to fit the brand of the app in order to provide a more meaningful experience. There’s another added benefit to performing a competitor analysis before starting design – it helps the design team avoid stepping on the toes of any IPs.

Logo Design

Unless the design team is working on an enterprise level app for an already existing company, you app is most likely going to need a logo for the App Store or Google Play. A good development shop will have the capability to design you app’s logo – and it’s a good idea to keep this part of the design process in-house.

Designers are specialized, just like any profession – there’s a reason the tech industry distinguishes between web dev and mobile. A print designer will make a good looking magazine, a t-shirt designer will make a cool graphic tee, and a UI/UX designer will design a logo optimized for ASO, user acquisition, and your app’s brand.

Depending on your app’s brand, designing a logo can take anywhere from 5 to 50 hours.

There’s a lot we could talk about when it comes to properly designing a logo for an app. Maybe we’ll cover it, down the road.

Wireframes and layout

If you’re not familiar with the term wireframes, this step starts out as the “sketching on the back of a napkin phase,” and ends with a fully structured (at least visually) app. This step in the design process can take from 20 to 50 hours, and if it’s a large, complex app, even longer than that. While this is a significant amount of time, it’s absolutely necessary, and critical to the success of your app.

I’d go as far as to argue this is the most important step of visually designing an app – building out the wireframes and overall layout of an app is, essentially, deciding the entirety of the app’s UX in a single step of the development process. Sure, during other steps in the design process, you can make topical changes to an app’s UX (such as color schemes to influence certain moods), but changes such as these don’t carry nearly as much weight as the actual flow of the app itself.

A proper wireframe layout will include all the information someone would need to understand how the app will work – while boxes will lack graphics, they will include language that denotes what information will be held within those visual boundaries, as well as how it will interact with the elements around it (aspects such as movement, scrolling, fading, or other interactions).

This step also lays the groundwork for an incredibly important, but often under-appreciated element of your app’s design – its negative space. The space surrounding the individual elements of your app like text, or boxes are called gutters. While their name might not be pretty, if your apps gutters aren’t uniform, users will notice, and be extremely thrown off – and worst of all, they won’t know why – they’ll just have a subconscious feeling that something is off about your app.

Design is a language everyone can implicitly understand, and when there’s a change in the uniformity of a product, especially an interactive one, our brains are wired to pick up on it. We are built to recognize patters, and when those patterns are broken, our brain sends off a warning light that’s incredibly difficult to get rid of.

When there’s a difference in the spacing of your app, even just a few lines of text, users will notice immediately notice.

UI Design

Designers will then take those wireframe layouts and turn them into the finalized interface for the app. This is the step where designers will make your app’s icons, decide and implement font styles, finalize the motion of the UI (the way the app responds to users interactions), and implement the feature set (in the form of interactive visual elements).

Something I believe is important to impart is that designers don’t just make things look pretty – just like there’s a backend to development, so to is there a backend to design. The previous step, building out wireframes, is akin to determining your APIs – and this step, UI design, is the equivalent to connecting the endpoints.

It’s a designers job to translate a tech doc into a visually interactive and stimulating experience that fits on a (relatively) small screen, is compelling, cohesive, and helps them solve a pain point they face in their lives by the most efficient path possible. There’s a lot more to UI design than selecting colors.

A designer’s day is basically one continuously reoccurring A/B test. Questions like “Does the placement of this button add to the overall UX, or detract from it?,” plague a designer’s day.

UI design can take anywhere from 30 to 100 hours, depending on the complexity of your app.

Prototyping

This step in the design process serves as the bridge between designing an app, and actually coding it. While it does add an extra step to the process, it does help to cut down on time spent revising your app after it’s already been coded however.

Development shops use this step as what I like to refer to as an “island of stability.” It serves as the benchmark for all development moving forward, because the prototype is the, after the wireframes, the first real interactive product shown to you, the client.

A prototype is designed to be as close to the imagined finalized app as possible – from UI movement to font sizes. Prototyping tools are used to demo the feature set of the app, and should demonstrate the entirety of the app’s functionality.

This is as such so you, the client, are able to determine what works, and what doesn’t. Once a design and feature set have been agreed upon by everyone, it’s time to move onto the final step of the design process.

You can expect prototyping to take anywhere from 5 to 15 hours, or more for complex apps.

Build out the UI/UX in actual code

This is where developers will take a backseat in the design process, and your developers will step in. While the designers might not be as involved with your app’s development from this point onwards, they aren’t out of the picture entirely.

In order to build out and code the actual app, developers must translate the visual elements of your app’s design into code. In order to do this, they need to develop their own structure to keep everything in its place.

To code the design of an app, programmers must hook up features that need to access servers or other outside data to the backend, as well as create the app’s individual design elements in code. In order to maintain your app’s quality and brand, programmers will make sure your app looks the same, no matter what screen resolution it’s being displayed on.

If your app is being developed for both Android and iOS, this means your developers will need to make sure it looks and works the same, whether it’s on an iPhone or a Samsung. This will, at the very least, double your app’s development time, and why most dev shops will caution appreneures to start out with a single platform.

How much does it cost to implement real-time updates in your app?

We’re on to the next chapter of how much does it cost to make an app?, and this addition we’re covering real-time updates. At their most basic level, real-time updates provide data that allows users to make more pertinent and informed decisions, and to then take action (at the right time) based on that data.

There isn’t one single real-time updating method for apps, however – just like anything that is built through software development. So, how much does real-time implementation cost you? Well, to keep the trend going, it all depends on what you want to achieve.

It’s important to note that for all types of real-time updates, there are two significant factors to their cost – time to build/implement, and the cost of data transfer throughout the lifetime of your app. If you’ve read our blog about how much it costs to implement a GPS/mapping API?, you’ll be familiar with the idea that every request made from a client to an API has a monetary cost associated with it.

The same goes for real-time updates (in fact, GPS and mapping APIs use real-time updating to function), and each data transfer will have a cost that comes along with it (for many reasons).

Let’s get into how these functionalities work:

The mechanisms behind real-time

There’s a lot of tasks real-time updating can accomplish – from detecting fraud at the moment of a transaction, to sending out the latest and greatest offer to a customer near your store’s location via proximity marketing.

Updating a device with data from a server can only be accomplished in a few different ways, however:

Polling

The simplest form of real-time data transfer is called polling. It’s the equivalent to knocking on your neighbor’s door at regular intervals until they answer. Or, for a more real-world example, it’s when a client continuously requests data from a server, based on set intervals of time.

While it is easy to implement, it’s a very inefficient form of data transfer – even if there is no change of state in the server, data will still be transferred every minute, or five minutes, or whatever pre-determined period of time you set. This forces you to play a balancing game against just how close to real-time you want your app to be, versus the cost to do so. The more requests you have, the more servers you need – which comes with higher infrastructure investment requirements, as well as higher maintenance costs.

The more data requests and transfers a server handles, the higher your costs will be. On the other side of the coin, if you don’t allow for enough server requests, your app won’t actually be updating itself in real-time – it’ll be more like what-happened-five-minutes-ago-time.

Long Polling

Long polling is very similar to polling, but with one key difference; rather than visiting your neighbor’s doorstep every minute, it’s like leaving a note on their door that says “come over when you’re ready.” In more realistic terms, it’s when a server only transfers data to a client if a change has been made to the data on the server.

While this does solve the cost issues associated with polling, it still comes with some pretty significant drawbacks:

  • Servers can sometimes be expected to hold on to massive amount of data
  • It is difficult to recover a session if a connection was lost with high reliability

Because of this, long polling has the potential to become a burden to large scale apps that require a high frequency of updates, or utilize segmented campaigns to target specific user groups.

Websockets

Websockets can be thought of as a tool that turns a client into a server – it allows the client to both make and listen for data requests – giving the actual server the ability to very easily update the client.

Websockets function by the client providing what is called a callbackURL. These can be thought of as the phone number the server dials when it wants to transfer data to the client.

What this means is that because a client can actively listen to the server, there is no data transferred until a change has been made to the status of the server, and if connection is lost between the server and the client, it doesn’t matter, because the client will resume its active listening pattern.

It’s the digital version of installing a camera on your neighbor’s front door so you know when they’re home – except less restraining-order-worthy.

Note: “Websockets” and “webhooks” are easily confused terminology. Webhooks are used for server-to-server communication, and tell a server to send data to a specific URL. Websockets are used for server-to-client communication.

Subscription Websockets

These are essentially the previously-mentioned websockets, and function in a very similar manner – the key difference is that they allow the client to determine what changes to data they want to be alerted about. For example, if a package delivery service uses a client-facing app, the client could select different types of data changes to receive alerts for: packed sent, package delayed, package delivered.

Methods of real-time implementation

There’s two pathways you can take towards implementing real-time updates: native development or through a third-party API.

If you’re going down the native development route, the cost of implementation varies depending on a multitude of factors, including: hourly rate, the complexity of the feature, the server infrastructure, and the amount of maintenance that will be required in the future.

Native development of real-time capabilities does come with perks, but its cost will ultimately come down to how much time you spend maintaining your server – while third party APIs come with reoccurring costs in the form of subscription fees – it’s a bit of a toss up as to which costs more. While natively run servers will cost less when everything is running smoothly, if something goes wrong, the maintenance fees fall to you.

Depending on the complexity of the real-time feature you’re implementing, your costs could range anywhere from $10,000 to $25,000.

Let’s go over some of the third-party APIs available:

Apache Kafka

Kafka can be used for messaging, website activity tracking, log aggregation, stream processing, and event sourcing. Like everything under the Apache license, it’s open source, and therefore free API to implement.

PubNub

PubNub can provide real-time integration for chat features, IoT device communication and streaming, mapping, GPS, push notifications, and alerts. PubNub’s services start at $49 per month, plus data transaction fees.

Fanout

Fanout.io serves as a proxy for real-time updates. Fanout also allows you to develop your own APIs alongside their service, so you can provide your own customization based on your app’s specific needs. Fanout costs $25 per month, plus data transaction fees.

Realtime

Realtime.co is a message broker that operates in real time through the cloud. It can be used for cross platform apps – and has SDKs to go with both Android and iOS. Realtime’s pricing starts at $49 per month plus data transactions, and goes up to $250 per month plus data transactions.

AWS AppSync

Amazon Web Services offers their own real-time updating API called AppSync. AppSync can be implemented for almost every use case imaginable. AppSync’s services cost $4.00 per million query and data modification operations, $2.00 per million real-time updates, and $0.08 per million minutes of connection to the AWS AppSync service.

Firebase

Firebase – Google’s comprehensive mobile development platform – has two different real time services: Realtime Database and Cloud Firestore.

Realtime Database stores your data on a single JSON (JavaScript Object Notation) tree. JSON is a “lightweight data-interchange format,” and is easily readable and writeable by people, and quickly parsed and generated by computers.

Cloud Firestore stores data in documents, which are organized and stored in collections. Documents serve as the unit of storage, and are written in a syntax extremely similar to JSON. Documents can be broken into sub-collections and nested objects, which are referred to as maps.

Both Realtime and Firestore are NoSQL databases, which come with their own pros and cons when compared to more traditional SQL databases. While SQL databases are organized to write data in a very efficient manner; NoSQL databases are organized to read data quickly, but due to their structure, require duplicate data in order to access information.

You can think of a SQL database as a collection of tables that hold very specific, uniform sets of information, that link up in a web. NoSQL databases are structured in branches, which lead to other branches, which lead to other branches.

NoSQL

Basically, when data needs to be shared instantaneously across hundreds, thousands, or even millions of devices, NoSQL databases are very efficient because of their data structure. Both Realtime Database and Cloud Firestore offer real-time and offline support with SDKs specifically built for mobile. Both are capable of being implemented for pretty much every real-time use case you can think of – from chat to re-sizing photos, to analytics and machine learning.

If you know your app will only be used by a relatively small audience in a localized area, and your data sets are straight-forward, go with Realtime Database. Cloud Firestore horizontally scalable – meaning it works better than Realtime Database when used across multiple localized areas, as you don’t need to create shards in order to do so. Because of Firestore’s structure, data is very easily split between different servers.

The Firebase payment model starts at a free version, and has two other plans: $25 a month, and a pay-as-you-go option.

Apps that utilize real-time

Sometimes, it’s a bit difficult to imagine what kinds of apps use real-time features in order to work properly, or improve their UX. So, here are some real-world examples of apps that use real-time tech:

Uber

Real-time tech is the backbone of Uber. Without it, users wouldn’t know where their driver was, driver’s wouldn’t know the location of their passengers, and GPS wouldn’t work.

SafeLite Auto

Much in the same way Uber relies on real-time updates to track its drivers, so to does Safelite’s app, which provides users with the location and ETA for a mobile technician.

WhatsApp

WhatsApp uses real-time updates for chat, voice, and video features. This is necessary for low-latency communication, and keeps conversations smooth, with even pacing, and no downtime.

Dominos

Real-time updates are how Dominos keep customers informed about the status of their pizza order – when it’s in the oven, when it’s ready for pick up, or when it’s out for delivery.

Inventory management

Inventory management at scale would be completely impossible without real-time updating capabilities. Keeping accurate track of your company’s stock requires knowing your exact inventory numbers every moment – when you’re working at a national or global scale, conversions can happen at rates that can only be tracked through real-time updates.

Your options for real-time

There’s plenty more services out there – but what’s important to know is that just like most software services, the costs of a real-time APIs increase with the scale of your app. If you’re going the native development route, your costs will largely rely on how much infrastructure investment is required, as well as your servers’ maintenance costs.

How much does it cost to implement login capabilities?

There’s a lot of apps that require a login feature – mostly out of necessity for the app to work properly – but data has shown giving users the ability to personalize their experience within your app is a powerful UX strategy when used to increase your user retention.

There is, however, one major downside to including the requirement that users set up a profile before they can fully utilize your app: app abandonment due to first impressions.

If users are met with a proverbial checklist of requirements to complete before they can actually use your app, they’re much more likely to give up before proceeding. This is where implementing a login through social feature comes into play – it gives your first-time users the ability to create a profile with one tap, rather than filling out forms and fields.

So, how much does this user-retention-saving feature cost?

Honestly, not too much – it all depends on how secure you want it to be. If you use our favorite app analytics platform, Kumulos, it can take anywhere from 1-3 hours to implement a login feature with an app, depending on the complexity.

Implementing a login feature with the lowest form of security (basic authentication) can cost as little as $100 to implement. Apps that want to utilize the highest levels of security can expect a cost of $10,000 for a login feature implementation.

When it comes to the cost of implementing logins with social media, such as Facebook, or Instagram, there is no extra cost – just the addition to the time it takes to actually implement. The price of these social login features comes from labor cost – the APIs themselves are free.

Let’s look into why adding these extra layers of security can cause such a drastic change in total cost, and, if the added security is worth it in the long run.

The costs of security

There’s many different forms of security when it comes to user authentication. The costs of which can vary depending on many different factors – ranging from time to develop to the cost of physical infrastructure.

There is something important to keep in mind in regards to the cost of security: the cost of code only changes if you are implementing third party APIs that come with a price tag or subscription fee – implementing your own code to allow for security that exists in a digital space only comes with different associated costs due to one factor: time to develop.

Let’s cover those:

Basic Authentication

The least complex login method is called basic authentication. Let’s go over how user authentication (at its most basic levels) works:

  1. A user enters their credentials
  2. Those credentials are sent to an authentication server
  3. The server will then attempt to match the credentials together
  4. Upon a match, the server authorizes the user’s attempted access

This process is faster than it sounds – it happens every time you login to a website that requires your username and password, such as your bank. This process is also referred to as “logon” authentication.

Single-Sign-On (SSO)

SSO functions very similarly to logon authentication, but rather than granting access to a single server, it grants access to multiple – a lot of social media and email websites will use this feature.

While SSO is the least secure method (as it gives access to multiple servers), it works well for apps for two reasons – smartphones are generally intimately used devices, so the chances of someone physically accessing your personal information via your smartphone is diminished; and, SSO does wonders for user retention, which is a hard-fought battle for most apps.

IPSec

IPSec is the most secure form of user authentication. IPSec allows data to be encrypted and authenticated over a secure internet protocol network. In order for the user’s device to understand, and then display the correct information based on the encrypted data, a method called mutual authentication is used.

This happens at the first instance of the user logging in, and continues to happen throughout the session as cryptographic keys are exchanged over the secure server. This can be implemented in three types of data transfer: user-to-user, network-to-network, and network-to-user.

Biometrics

Biometric security is largely implemented through physical means, and utilized in mainly on-site locations, rather than remote – therefore, its most common use case is in buildings that require high amounts of security.

Current biometric capabilities include finger print scanners, voice recognition, and retinal and face scanners. These capabilities are rapidly changing and expanding into different realms of biometrics, such as heartbeat and even brain activity.

Biometric security is a high cost investment, as it requires specialized scanning equipment – because of this, its costs can greatly exceed $10,000 – this number depends heavily on the scale and amount of scanning devices required.

Token Authentication

Token authentication requires a user to physically possess a device, such as a dongle, card, or RFID chip (plus a password) in order to access a secure system. While this is a highly robust method of security, due to the requirement of both an actual device and password needed to be used to access a server or system, it mainly only works for organizations that have the infrastructure necessary to implement an extensive system such as this.

Transaction Authentication

Transaction authentication is a pretty straightforward security method. In essence, it boils down to this: If a transaction (via credit card or payment service) seems suspicious, the person making the transaction will be prompted to take extra steps in order to verify that they are indeed the person they claim to be.

While the idea of asking someone “Are you sure you are who you say you are?” Is a simple security measure to wrap your head around, the systems required to make that process possible are intricate and costly – and require a significant amount of investment in infrastructure.

This is largely due to the fact that you must first have significant amounts of data for each customer profile before you can start defining suspicious account activity, and then flagging errant transactions.

Multi-factor Authentication (MFA)

Multi-factor authentication simply means mixing two types of user authentication together into a single authentication process. For instance, the example we used for biometric authentication (requiring bio-data and a password) can be classified as MFA, or, our example of token authentication – requiring a user possess both a device and password.

Out-of-band Authentication (OOB)

Out-of-band authentication validates login requests by requiring the user to provide information that can only be accessed by a device different from the one they are currently using to log on. For example:

When you login to your car insurance website, but before you do, you receive a text message containing an access code that is only valid for a limited amount of time. You then enter that code into the website, and you finish the login process.

This is a method of security that has a very applicable use case for an app that needs a high degree of security.

The costs of not using secure login authentication

First, it’s important to get one thing clear – if your app doesn’t make use of sensitive or highly personal information, go ahead with SSO. There are options you can take to implement extra layers of security on the initial login authentication.

If your app does make use of sensitive info, however, it’s vitally important to your user retention, brand equity, and business in general to use the highest levels of security. When comparing the cost of $10,000 to the cost a negative user review and rating can do to your app’s ranking, it’s definitely worth the upfront cost.

A perfect example of this is what happened to Facebook and its reputation after the Cambridge Analytica scandal; 1 in 10 American users deleted their actual profile, and 26% of American users deleted Facebook’s app from their devices.

Their brand is irreparably ruined in the eyes of some of its former customers – 15% of users who responded to a survey conducted by market intelligence firm Creative Strategies and Techpinions said there was nothing Facebook could do to regain their trust.

This was the response to a social media company’s mishandling of user data – now just imagine what the fallout would be if your sensitive-data-based app mishandled users’ personal information.

Context is key

When budgeting for a login feature with your mobile app, it all comes down to how secure your app needs to be. Basic user authentication can be implemented for as little as $100, and IPSec can reach the realm of $10,000.

How much does it cost to implement backend CRM software?

Continuing with our quest to provide you with the most comprehensive answer to the question: how much does it cost to make an app?, it’s our next addition to the fray – and this time, we’re going over the cost of backend CRM (Customer Relationship Management) integration.

There’s the usual simple answer (that really doesn’t answer anything): it depends on the complexity of the CRM software and the mobile app that goes with it.

There’s also two different options, both of which come with widely differing upfront and lifetime costs and value:

  1. Purchasing (and then implementing) a third party CRM API = low upfront cost, high lifetime cost, low lifetime value
  2. Building your own custom CRM software, and then integrating it with the backend of your internal app = high upfront cost, medium lifetime cost, high lifetime value

If you want to go the third-party API route, the answer ultimately comes down to the SaaS provider you chose to go with. Going the custom CRM software route, will, in the long run, save you both time and money.

Before we get into the reasons as to why, we’re going to cover the basics of the functionalities a CRM software can provide – so when you’re planning out your own internal business app’s development (and the backend integration of its sister CRM software), you’ll know what to expect.

CRM software functionality

CRM software is designed with the intention of providing a hub for every aspect of managing your business’ relationships with its customers:

  • Management of: Contacts, leads, prospects, affiliates, and partnersCustomer data: Storage and processing
  • Customer profiles: Personal data, contact information, history of past purchases
  • Process automation: Syncing communications, automating reports as well as email (and sometimes text) marketing efforts

Let’s go over the features that make those functionalities possible.

Lead management

Keeping track of leads is crucial in today’s market – and it’s no longer only large corporations that deal with high volumes of clients – small business must compete at a global scale in order to keep up.

One of the most practical methods to increasing customer loyalty is to develop and maintain a personal connection with every customer – from their initial point of contact with your business onwards. In order to effectively accomplish this standard, lead management is a necessary and effective tool.

By using the lead management functionality CRM software provides, not only can you disseminate leads to the right people, you can automate your mid funnel processes; such as marketing and remarketing campaigns that utilize email or text campaigns that serve to keep customers engaged with your business, thereby creating (and increasing) lead generation.

A perfect example of the efficiency CRM software provides is the automation of leads’ contact information – when a client fills out their info on your website, it’s then added to their customer profile in your database.

When your sales team adds contact information to a customer profile from a lead they just created, the data ends up in the same place. Not only does this make it impossible to lose or duplicate information, it means that if a sales representative is no longer with your company, the lead’s info stays within your database – not on their personal phone.

Process Management

When was the meeting with David? No, the other David. You know – the one with the on-demand dog walking app?

CRM mitigates the wasted minutes in those kinds of conversations. If an account representative schedules a call with David-the-dog-walker, your account manager will know as well, because all the information David and his business can be found in the same place – his client profile in your CRM software.

Assigning tasks, scheduling meetings, making sure follow-up emails are sent, and phone calls are placed is simple when it’s automated. You can even set up automatic notifications to make sure no task is left by the wayside.

Speaking of keeping everything in the same place, let’s move on to…

CRM Dashboard capabilities

Everyone loves a good dashboard – and with CRM software, you can create customized dashboards for each facet of your operations – from sales and marketing to service automation and even accounting.

Dashboards are the perfect tool for helping your employees understand the big picture, the pieces and processes that make it up, and their role in your business’ operations as a whole. They’re also excellent more mobile devices, as they are the quickest way to find information on a smaller screen.

Auto-generated reports and invoicing

There’s not much to say here, other than CRM software will put the “I want those reports on my desk by 5,” cliche to rest. Instead of spending countless hours tracking down and then organizing information, you can just click a button.

There’s nothing quite as inefficient as spending money to fill and send out invoices. The time and money spent on filling out documents that are, by their very nature, asking customers for money is one of the more catch-22 moments in everyday business life. Just like reports, filling out invoices is a thing of the past with CRM software. The program already knows who bought what, where it’s going, and who’s receiving it.

Lead Scoring

Knowing who to go after at the right time is a skill business developers must hone over years of professional development. CRM software can be used to automatically track and score the engagement of your users, and then update their profiles with their current score.

With a system that can quickly analyze and interpret vast amounts of data and interactions, you can better measure your leads’ online behavior, email and social engagement, and any other channels you use to engage with customers.

Wrap all that up in an app

The best part is that all of those functionalities can be packed into a mobile app – through integrating your CRM software with your internal business app’s backend. This means that when your employees are away from their desks, out in the field, or serve a roll that keeps them on their feet, you can still make sure they’re in the know.

This doesn’t mean replacing your CRM software with an app – merely that it’s just as accessible and useful when your employees are in situations that require them to be away from their desk.

The cost of implementing CRM software with a mobile app

Funnily enough, the cost of implementing your CRM software with a mobile app is a pretty low cost- your custom CRM software is basically it’s own API, so it comes down to how much time it takes to connect the endpoints with the backend logic of your app. A typical rate to do this would range from $75 to $125 per hour.

The true cost of implementing CRM software with an app is the actual development of the CRM software itself – building out a CRM system with the features listed above is a process that typically takes (at least) a few years.

The time it takes to develop is inexorably tied to the scale and complexity of the needs of your company – which usually means the greater your need for CRM software, the higher the cost to develop. The upfront cost to begin development of custom CRM software can range (again, depending on complexity) from $50,000 to $75,000. Over the course of a few years of development, costs can range from $175,000 (for a simple CRM system), and $250,000 – $500,000 for a complex one.

Those are high numbers – but consider the longterm costs of continuously paying for a third party CRM software; when looking at the most popular CRM SaaS provider, the option with the most functionality is $300 per user per month. If you have 25 users, that means $7,500 per month, or $90,000 in one year.

So, even if your custom CRM system cost $500,000 to develop, that cost is basically paid for after five years. In regards to the long term cost, the custom CRM software will win every time. Not only does custom-built CRM software have a lower lifetime cost, it also comes with a better value – since it’s custom, it’s made to specifically improve your processes, not business practices in general. This makes your employees who use it even more efficient with their time, which leads to happier customers, and more sales.

How much does it cost to implement wearables?

Just how much does it cost to implement wearable technology with your app? We have the answer, but before we get into it, let’s look into where the wearable market is today, and how it got there.

A brief history of the future

If there’s one burgeoning technology that has “future” written all over it, it’s wearable tech. From 2010 to about 2015, there seemed to be a contraction in the evolution of different types of consumer-facing hardware – sure, there were many different devices being created, but they all generally fit into the category of “thing with a screen.”

A smartphone is a smaller tablet. A tablet is a laptop without a keyboard (unless you’re talking about Microsoft’s Surface), and a laptop is a portable desktop computer. All of these devices were made to basically function (other than inputs) in the same manner – and during this time, innovation was based around making devices smaller, and more portable.

Mp3 players were abandoned in favor of iPods. iPods were abandoned and replaced with iPhones or Android devices.

The first wearable devices, like the FitBit, were a continuation of this trend – take a screen, make it smaller, and put it on a device. There was one important distinction with this device, however – unlike smartphones, tablets, and laptops (which all accomplish the same tasks), the original FitBit only did two things – it kept track of your daily steps, and how much time you spent sleeping.

This was in 2009 – two years after the first iPhone was released, and during the time period mobile devices were focused on adding features, not purposely limiting them.

The power of wearables isn’t their ability to do everything, however – it’s their ability to do a small range of things very well. When it comes to keeping track of steps, wearing an unobtrusive device that you don’t need to interact with is a much better user experience than taking out a phone, opening an app, waiting for it to load, starting your step counter…

What’s less distracting when you go for a run – a smartphone bigger than your hand, or a device you can wear on your wrist?

So what does a watch that keeps track of your heartbeat, steps, and sleep cycle have to do with the future? It’s because this is just the beginning.

The wearable hardware market

Smartwatches and fitness trackers – the two types of devices that immediately come to mind when the subject of wearable tech is brought up.

For good reason to – the vast majority of wearable devices sold have been Apple’s AppleWatch, which sold 1 million units in one day on its initial launch in 2014. Since then, there’s been steady, incremental improvements to smartwatches, like battery life and screen resolution. When WatchOS 2.0 came out, and apps began to run natively on AppleWatches without the help of a companion smart phone, the benefit of smartwatches began to come apparent.

Wearable tech’s association with fitness isn’t unfounded either – the fitness and sport segment of the wearable market accounts for 39% of the market share. Speaking of market share – the wearable market, while new, isn’t small at all – in the U.S. alone, there were 38 million users of wearable tech by 2018.

The truly exciting aspect of these numbers is their potential – with AR-specific products already on their way to market this year, like Microsoft’s HoloLens2, the growth and innovation the wearables market will experience will most likely be staggering – in both economic growth, and impact on society. In the U.S. market, 21% of consumers have stated they are “very likely” to purchase a piece of wearable tech like a smartwatch. With AR, VR, and MxR on the horizon, this statistic will only increase.

Just take a look at this piece from TIME about the future of wearable tech – smart clothes that provide tactile feedback paired with GPS navigation, shoes that charge your other wearable devices by utilizing the energy from your movements, and GPS enabled shirt buttons that can call 911 when you’re in danger.

The wearable software market

There are three main industries focused on expanding their markets via wearable devices:

  • Fitness and Wellness
  • Healthcare
  • Defense

Both the fitness and healthcare industries are expanding into wearables for obvious reasons – defense contractors and the DOD, however, are more interested in the application of VR and AR technology.

The healthcare industry is expected to monitor the health of an estimated 5 million patients by 2023, driving $60 billion in spending on wearable tech. The Department of Defense is expected to spend nearly $11 billion on VR wearable tech by 2022 – while that’s a hefty price tag, the amount of time and money saved in training soldiers is a much higher number.

While wearable tech will most likely never fully replace smartphones and laptops, they will undoubtably enhance the experiences they provide to users. That’s why it’s important to make sure the pain point your wearable app solves is even more targeted than a standard mobile app.

Despite many pieces of wearable tech providing the hardware layer for native, standalone apps that run independently without the help of the cloud or another piece of technology, most apps that live on wearables (especially smartwatches) are supplemental additions to an already existing app.

So, how much does it cost to implement wearables?

Luckily, developing a wearable app isn’t much different than developing for iOS or Android – there’s just a few tweaks here and there. AppleWatch apps are programmed using Xcode and Swift, just like all iOS apps, and Android Wear apps are programmed using the usual suspects – JAVA and C++.

Let’s pretend that we were going to make a wearable app for Brew Trader – it’s an app that gives users the ability to find and trade craft beer with other beer enthusiasts nearby, which they can find on a map, or through searching for a specific beer.

Let’s say the wearable app we’re developing is going to be used to supplement the process of communicating with other users – currently, users are sent a notification when they have a trade request. In order to optimize the interpersonal communication between users, and lessen the time a request spends in limbo, we decided to build out a wearable app that alerts the user about any trade requests, or responses to their own requests.

What would this require?

First, we would need to build out the UI for the wearable app – the parameters of which rely on a set of factors such as the screen shape (for smartwatches: rectangular, or circular) and model of wearable device (AppleWatch vs. Android Wear). If we wanted Brew Trader to be available for both Apple’s and Android’s wearable devices, we’d need to develop native apps for both.

The interfaces of smartwatches use different inputs and design hierarchy than mobile apps, so while it’s important to keep the styles of your app similar, it’s just as important to not reuse UI elements – you’ll end up going back to re-design them anyway.

Second, we’d connect the wearable app to the mobile app using the cloud, as well as connecting the wearable app itself to the backend database Brew Trader uses to keep track of trade requests, user profiles, and user DMs.

Third, we’d use an analytics platform like Kumulos to create segmented push notifications that alert users to trade requests, responses, and DMs.

Fourth, we’d implement the new code into Brew Trader’s code base, and add the new smartwatch functionality as an update to the already existing app.

And when it comes to implementing a wearable app into an already existing app, that’s really all there is to it. Something that’s very much worth noting – if the only thing you want to achieve by implementing a wearable app into your already existent app are push notifications (and the push notifications don’t rely on data from the mobile version), there’s virtually no extra cost. All smartwatches can display the push notifications of an app, regardless if it’s a mobile or wearable app in question.

If you want to build a wearable app from the ground up, it’ll largely be the same cost and process as normally developing a mobile app. One thing we will recommend here is to directly contact the company that designs the hardware you’re planning to develop for. The wearable industry is still very plastic, so UI/UX standards aren’t set in stone, and users are still very willing to learn new ways to interact with wearable devices. As a developer, you can actually influence the development of hardware to include physical features or processing capabilities your app would need to function. This isn’t an opportunity developers have very often, and the window to do so will soon be coming to a close.

How much does it cost to implement push notifications? – with Kumulos

Push notifications are a fantastic and proven strategy used to increase both user engagement and user retention – but are they worth the cost?

The short answer: most of the time. But let’s get into the reasons why.

The cost of implementing push notifications

Let’s start with the lowest cost option first – sending out push notifications on your own. In order to do this (at least for iOS), you’ll need to:

  1. Sign up for an Apple Developer Program Membership ($99)
  2. Set up a push notification certificate for your app ID (which you’ll get when you sign up for an ADPM)
  3. Download a push notification app from the App Store
  4. Set up a server from which to send push notifications to your users’ devices (costs for servers vary, and largely depend on your data loads)
  5. Use callbacks in the app to receive and handle push notifications

You should note that for iOS users to receive your push notifications, they must opt-in. For Android, it’s the opposite – users are automatically set up to receive push notifications when they download an app. Because of this, Android apps see a much higher opt-in rate than iOS – 91% compared to 43%.

Keep in mind, however, that iOS users tend to engage with apps more than Android users do. In addition to this, users who opt-in to push notifications engage with apps 88% more than those who don’t.

Also remember that just because you’re sending out push notifications yourself doesn’t mean that it’s free – if you’re the CEO of your company, you’re using your own time. If an employee of yours is sending them out, they’re using their own time – and time is money.

Sending a push notification, no matter if you’re supplying the backend infrastructure, is never truly free of cost. There’s also one glaring issue with sending out push notifications yourself – you lack the ability to study your push notification analytics.

Implementing push notifications through an analytics platform

If you’re invested in making a successful app, you’re most likely going to use an analytics platform in order to, well, analyze how users engage with your app. If you use these types of services, they might just have their own push notification service.

While this does cost more than sending out the push notifications on your own, successfully running an app without the support of an analytics platform is nigh impossible. So if you’re already utilizing a service like this, you might as well make the most of it.

There are a lot of analytics platforms, but we prefer Kumulos. A major reason for this is because through their platform, you can schedule, send out, and analyze your push notifications – as well as create segmented campaigns.

Bringing your analytical capabilities and your push notification campaigns together has an extra bonus – you’re able to study patterns of user behavior (like the day of the week, or hour of the day) that a user is most likely to open up your app. If they didn’t open up your app at their usual time yesterday, send them a push notification with a message that serves as a gentle reminder for them to engage with your app.

Now, we’ve stated this before, but we’ll say it again: it’s incredibly important to keep one fact in mind when sending out a push notification – you are interrupting your users’ daily lives. It’s the digital version of being handed a flier while you walk down the sidewalk – or being asked to write down your signature for a cause.

That’s why there are four key factors behind successful push notifications:

  1. Targeted
  2. Immediately beneficial to your users
  3. Attention-grabbing
  4. Billboard rule (less than ten words, ideally 7)

If your push notifications fall into the realm of “sales-y,” you actually run the risk of decreasing your app’s user engagement, and increase the chances of users abandoning your app in favor of one that doesn’t annoy them.

Bob Lawson, Founder, Kumulos says, “We 100% agree that push notifications are worth it, when done correctly. It’s far less expensive to retain existing app users than work on acquiring additional users. Having the ability to analyze the results of push notification campaigns is key to driving successful outcomes for any app.”

If you’re using a platform like Kumulos to both analyze user behavior and send out push notifications, you’re more likely to find the sweet spot between grabbing your users’ attention (for their own benefit), and interrupting them (for the benefit of your metrics). Users can easily tell which category your message falls into – and they’ll react accordingly.

This is why, even though it costs more (at least initially) to subscribe to an analytics platform with push notifications capabilities, it’s ultimately more economical to do so than going the “free” route.

Targeting the needs of your users, and providing them with a pertinent CTA is how you increase your user engagement. Shouting into the void, or asking your users to do something for your app while providing no benefit in return is how you lose users.

Here’s an example of a bad push notification:

Hi! This is _______! We’d love it if you could review and rate ______, the app you love, in the app store! Here’s a link to share us on social media: [link]

And here’s an example of a push notification that accomplishes the same thing, but in a way that’s beneficial for both your app and your users:

One month free for rating ______: [Link]

Now, that might seem like a low effort sales pitch, but what’s less of an interruption? “Here’s the thing,” versus “Hi! Here’s this great thing we’d like you to know about! If you want to act upon this thing, visit here!”

The second example also provides users with an immediate benefit: “one month free.” Don’t bury the lead.

There are other strategies for getting the most from push notifications, namely Proximity Marketing. If you’d like to learn more about that, check out our guest blog from Kumulos’ Caroline McClelland.

The last thing we want to cover is that sometimes push notifications aren’t the best way to go about increasing your user engagement and retention. Like anything in this world, context is key to success.

Understand how your users’ interact with your app, and if that interaction could receive benefit from push notifications. If there’s no benefit they could provide your app, don’t use them.

So, how much do push notifications cost?

As much as you want them to. Just remember; the more investment you put into analyzing your users’ needs and usage patterns, the more targeted (and segmented) of a push notification campaign you can make – which in turn results in better responses to your push notifications.

Don’t be the seedy car sales representative. Be the friend who wants their friend group to know about the cool thing.

How much does it cost to add a GPS & mapping API?

How much does it cost to include a GPS and mapping API in your app?

Depending on what you want your app to achieve, the answer can vary drastically. It also depends on the API you want to use, the type of app you’re making, and the functionality you want your map to provide.

Let’s go over the cost of some of the more popular GPS and mapping APIs, starting with the most well-known of all:

Google Maps

First of all, if your app is free (as in no cost to download, no ad revenue, and no subscription fee) Google Maps is free to use. This includes all of their API’s functionality – directions, routing, street view, and all the other functionalities.

Google Maps also provides developers with the ability to customize their map – this includes colors, information presented, and much more. The customized map can then be copied as simple Javascript to be implemented into your app – this works with both Android and iOS platforms.

Google Maps’ costs are as follows:

  • Embed Advance: $14 per month
  • Static Maps: $2.00 per month
  • Dynamic Maps: $7.00 per month
  • Static Street View: $7.00 per month
  • Dynamic Street View: $14.00 per month

For more information, visit Google Map’s pricing page.

Keep in mind that even if you’re on a free plan for Google’s API (or any API for that matter), it still takes time and costs money for developers to implement that API into your app. Most APIs also require a backend through which they access data, which adds to your costs. Backend service pricing varies wildly.

Mapbox

Another GPS and mapping API, Mapbox is free-to-implement as long as you stay below the magic number of 50,000 views/requests/users a month. Mapbox gives developers the ability to provide users with real-time navigation, augmented reality, and data visualization. Their API is customizable, and their tools for visualizing data can be used on the web, mobile, and desktop.

If you go over that magic number of 50,000, the price moves up to fifty cents per 1,000 map views, geocoding requests, directions requests, matrix elements, and Tilequery requests. If you’re building an enterprise app, you can get a volume discount if your numbers are over 5 million for the same categories.

Mapbox can be implemented for both Android and iOS apps.

For more information, visit Mapbox’s pricing page.

Tom Tom

Tom Tom is yet another mapping API – rather than providing a pricing plan based on interactions per month, Tom Tom offers you 2,500 API transactions on a daily basis. This number is reset each day. Keep in mind that a transaction isn’t a user opening your app, using the map functionality, and then closing it. For their maps API and traffic tiles, one transaction is equal to fifteen requests.

If you’re going to go above those 2,500 free transactions per day, you can check out Tom Tom’s pricing page here. For 50,000 transactions, the price is $25.00, and for ten million the price is $4,199.00 – as you can see, depending on how many users you expect, your costs can vary significantly.

So just what are GPS and mapping APIs?

First, let’s cover the basics – API, just in case you aren’t familiar with the acronym, stands for Application Programming Interface. Basically, an API provides a developer with set of functionalities and protocols that define how pieces of software interact with each other.

In regards to an what an API call (also referred to as an API request) is, it’s essentially a piece of software in an app connecting to a server in order to transmit data between the server and the app. This is all made possible by backend integration.

This is how GPS and mapping APIs are able to update users with directions, or can display (and react to) traffic conditions. Every time your users interact with the mapping API your app uses (for instance, finding the nearest gas station) they are guided by directions that are provided by multiple API calls.

The app communicates to the server where it is, and the server uses that data to correctly display the next step in their route. This process is continued until the user has reached their destination.

This is why most GPS and mapping APIs offer different options from which to mix and match – and why you should choose which features you want to include carefully. While mapping APIs are designed to scale with your usage volume, they do become more expensive as your user base grows.

It’s always easier to add functionalities than it is to take them away – your users will be disappointed and dissatisfied if they notice a feature that was available to them is no longer there.

That’s why we recommend starting out your app as an MVP.

How (not) to build an app with Appy Pie

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.

For the self-driven individual, an app WYSIWYG (What You See Is What You Get) editor sounds like a dream – they can work pretty well for websites, so why not apps? Wouldn’t it be cheaper to make it on your own anyway?

It makes sense that a service like Appy Pie would be tempting for any appreneur with an eye for design and a small budget – or maybe a CTO in the same situation. But – and this is my honest opinion – I think it would be easier to design an app in Sketch, prototype it in Invision, teach yourself Swift, and build in Xcode, than it would be to create a successful app using a service like Appy Pie.

I have come to form this opinion because I tried to make an app using Appy Pie. I originally intended this to be a fairly benign chapter of our How to Build a Mobile App: The Ultimate Guide, detailing the best options to use and a short how-to guide for the appreneur who does not have the funding to hire an app developer; but almost as soon as I started testing the user experience of Appy Pie, I knew that wasn’t going to happen.

Because; skipping (for now – I’m going to get to these later) the un-organized creation system, limited options, and inescapable cookie-cutter feel – it’s not you making your app. It’s Appy Pie.

Now, I feel like I need to put a little disclaimer before we go any further; I don’t hate you, Appy Pie. This isn’t a vendetta against you personally. It’s just WYSIWYG doesn’t work with app creation. This isn’t even really about Appy Pie – it’s about any service that provides a way to make apps without coding them.

Making an app with Appy Pie

Appy Pie

At first, I was intrigued. “Create an app for free in 3 easy steps? That sounds awesome!” I was interested in how it would work; I had built a website that didn’t need to accomplish much using a WYSIWYG creator in my first year of exploring web dev, and it had honestly taught me a few things, and the site really wasn’t half bad (for what it was intended to do). So, I had hope that there would be an equivalent for apps..

What I’m trying to say, is that I went into this with an open mind; I didn’t intend to write a piece touting the benefits of hiring a mobile developer over using a service like Appy Pie. It’s just how it naturally transpired.

Appy Pie

One of the first questions Apps Pie asks is on point: What’s the purpose of your app? As we’ve gone over in the past, knowing the purpose of your app is one of the most important questions to answer before doing anything else. At this point, I was hopeful.

And then came “Step 2.”

Appy Pie

This is where it all starts to fall apart. The above screenshot is what you’re greeted with, and while Appy Pie’s UI is pretty straightforward to navigate, I found it extremely difficult to visualize what I was creating. Now, not every app developer has the same process, but a simplified overview usually looks like this:

  • Designing the UI in Sketch
  • Planning the flow in Invision
  • And then coding based upon the Invision file

Appy Pie seems to take this process and condense it into one step. While this may seem like the service has just streamlined the app building process, they’ve instead muddied the waters. There’s a lot to keep track of when planning and building an app, and one scrollable list isn’t the most efficient way to go about it.

Take, for instance, what an app’s UI design looks like in Sketch:

Sketch

Every rectangle you see above is the design for each screen of a single app. These screens are then put into Invision and linked together to plan out the app’s flow and UX. During the design and prototyping phase, our UI/UX team gets into the nitty gritty details of each screen, working in tandem with our programmers to determine everything from screen transitions to the exact pixel dimensions for each button, field, and image.

Our developers can then take the Invision file, and code based on that – providing them with easy access to all the necessary information, from hex colors and fonts to UX and flow.

Now, imagine doing all of that, but with this UI acting as your tech doc, your design editor, your prototype, and your code:

Appy Pie

Yes, it’s visually simple. But take a look at that Sketch screenshot again. Now imagine bringing that level of detail into a system like Appy Pie’s. This system condenses the intricate and detailed process of creating feature sets, UI/UX design, and app flow into:

  • Choose feature
  • Design feature
  • Choose another feature
  • Design that feature
  • Repeat ad nauseam

This is a great way to produce an unorganized app. It’s akin to not only building a house without a blueprint – but building a fully functional and furnished kitchen with plumbing, appliances, lighting, table and cabinets, and a coat of paint – and then moving on to the living room’s wooden frame. Doing this, it’s unlikely you’ll build a structurally sound home.

This isn’t even mentioning the cookie-cutter feel this system is sure to produce. Take a look at the options given to you for layout and design:

Appy Pie

Appy Pie

With limited options and methods of implementation, your app is bound to feel just like someone else’s.

This muddied method for app creation has another negative compounding factor: You don’t know how anything fits together. Sure, “Step 2” has a live preview of each page on the right side of Appy Pie’s UI:

Appy Pie

But all too often, I would be met with this message:

Appy Pie

Which brings us to development cycles. We’ve covered some dev cycles before, but overall, most developers will use what’s called agile. Basically, the steps to an agile development cycle are as follows:

  1. Identify and set goal for issue
  2. Work on issue
  3. Meet up after a set amount of time to discuss and test process on issue
  4. Iterate until complete

This process can take anywhere from a day to two weeks, and it largely depends on the developer – but (and this is a very important but) – each issue (another word for feature) is tested independently before it’s implemented. This is because (as we’ve covered in our Swift development piece) programmers will build their code in a branch, test that branch independently from the rest of the code, debug, and then merge their branch with the master branch.

This serves two very important functions: compartmentalizing bugs, and reducing the risk to the overall codebase. It’s much simpler to look over 100 lines of code and find the problem with your app than it is to look over 10,000 lines. By testing each feature by itself, developers are able to cut down on overall time spent testing the app – measure twice, cut once.

And this is where things really start to go downhill. I had made a gallery linked to my Flickr account, and I wanted to test it on a phone to see what it would actually be like to use this app on a device. So, I downloaded the app, and this is what I saw:

Appy Pie

Honestly, not bad. All the work I had to do was select the grid layout, and I had played around a bit with some of Appy Pie’s default backgrounds. The scrolling, albeit a little janky, worked, and switching between the “Donate” and “Photo” bottom menu options worked. There were a few problems though – scrolling just stopped loading new images after a certain point, and I wanted to take away the “Sets” tab, along with changing the typeface the gallery used.

So, I set those as goals to fix – much in the same way developers will test, find a bug, and fix it. I went back into Appy Pie to edit the gallery, and I was met with this:

Appy Pie

I couldn’t edit. I had downloaded the app to a device in order to test a feature set, and I couldn’t make changes (not until I paid, at least) based on my findings from testing.

How to make an app with Appy Pie: v1.1

With this newfound information, I present the fool-proof guide on how to make an app in Appy Pie “for free in 3 easy steps”:

  1. Make an Appy Pie account
  2. Design, plan, and implement your entire app all at once (perfectly too, no testing allowed)
  3. Publish your app

It’s just that easy!

When I started researching Appy Pie’s service, I really didn’t expect to end up writing something with as much snark – but my plan was forced to change. I tested an outline against my actual experience, found they didn’t work together, and then edited the outline to make it fit with what actually happened. A process Appy Pie can’t seem to replicate – for free, at least.

There’s so much more to a successful app than just making it too; ASO is a huge factor for your app’s success. For any sort of analytics, you’re paying $50 per month per app, and that app can only be stored on a maximum of 600 MB of space.

There are entire companies dedicated to analytics and building keyword campaigns for apps, and when you build an app with Appy Pie, you’re expected to do all of it yourself, while paying a platform for allowing you to do so.

If you’re a self-driven individual set on making your own app, we think that’s great. Our senior Swift developer is self-taught, and we believe some of the best coders come from the evolution of hobbyist to professional – but keep in mind, if a service’s “Create an app for free in 3 easy steps” claim seems a little too good to be true, that’s because, more than likely, it is.

Android vs. iOS – How do I decide which platform to launch on?

This is a question we covered a bit in our piece about how to find a mobile developer, but I felt like there was more to talk about; we were recently discussing in a meeting why some clients seem to favor one platform over the other, and what the benefits are to launching on iOS versus Android.

First, I think it’s important to distinguish what I mean when I say platforms – this isn’t just limited to Android and iOS, after all. There’s other facets of these OSs; AppleWatch and AppleTV; while Android is currently supported on SmartTVs and wearables like the MOTO ACTV, and is already making headway with smart glasses, home appliances, cars, and even SmartMirrors. Apple itself is of course supporting their own ventures into these new implementations of smart tech, with their own projects like Titan, for example.

But how do you decide what platform is best for your idea? Before we get into the what the future holds for Apple, Android, and all the other tech giants, let’s get a clear picture as to what the current field looks like today:

Just the facts

  • In the U.S., Android owns 54.6% of the market, and iOS owns 44.4% (Android is the top performer globally)
  • More iOS users download purchasable apps than Android users (11.82% vs. 5.76%)
  • iOS apps have a higher retention rate than Android (1% to 3% higher)
  • Android has a lower publishing cost than iOS (Android has a one-time-fee, iOS is yearly)
  • iOS development is cheaper than Android (by about 30%)

A few things to keep in mind: Android’s market share, while larger than iOS, is skewed by the fact that Android comes with many pre-paid phone options, while there are no pre-paid iPhone options. While the larger percentage of market share should indicate apps that are hosted on both Google Play and the App Store would see more total downloads from Android users, we have, in fact, witnessed the opposite.

Three apps that we have published to both the App Store and Google Play are the perfect example of this. Out of these three apps, one has an audience centered in the U.S., one is centered internationally, and one has an audience split almost evenly between the U.S. and international markets.

  • The app with users mainly from the U.S. has seen 76% of it’s downloads come from iOS users.
  • The app with mostly international users (remember, Android boasts a very high market share internationally) has seen 46% of its downloads come from iOS users.
  • The app with an even split between U.S. based and international users has seen 65% of its downloads come from iOS.

As of Q4 in 2017, Google Play hosted 3.5 million apps, while the App Store had an offering of over 2 million. Users have downloaded apps 19.2 billion times from Google Play, and 8.2 billion times from the App Store.

iPhone users tend to be younger (by only a few years, but still a noticeable difference), and are described as “power users,” meaning they engage with more categories of apps more frequently, and on a regular basis, when compared to their Android counterparts. While iPhone users are more likely to engage with apps than Android users, they also represent a smaller audience when compared to Android.

A question you should ask yourself (and this is largely dependent on what type of app you’re making) is: what is more important for my app? Reach, or engagement?

iPhone users are more likely to engage in “m-commerce” (online purchasing through their mobile device), and are also more likely to retain their position as Apple customers, as 80% of iPhone users have perviously owned another iPhone.

While iPhone users tend to favor retail and social media, Android users tend to gravitate towards (and purchase more frequently) utility and productivity apps. iPhone users tend to value simplicity and consistency, while Android users place great import on the customizable nature of their apps; likewise, iPhone users usually identify as extroverts, while Android users are mainly introverts.

These findings, of course, are not set in stone – there are most definitely introverted, low-engagement iPhone users just as there are extroverted, high-engagement Android users; some Android users exemplify the epitome of brand loyalty, while some iPhone users are disillusioned by their experiences with iOS.

But the trends are noticeable, and when deciding which platform is most important to focus on, this is data that should be considered carefully.

For more information, check out our Android and iOS dev pages.

Development options

Android vs iOS Development

As we’ve discussed previously, it’s always better to develop your app natively. This does come with one main detractor, however; cost. A great way to offset this is by focusing on one platform initially, and using the MVP model of development. We believe the best platform for an MVP is iOS, mainly due to the platform’s high user engagement. Since users are more likely to engage with, and spend more time using their apps, iOS early adopters provide higher quality feedback than Android.

In fact, one of the most successful apps on the market today, Snapchat, has mainly focused on developing their app for iOS. Now, with the benefit of a (much) larger budget, they are bringing Android up to par with their iOS version.

This is not to say that Android apps won’t work as MVPs; rather that iOS user behavior lends itself to the user engagement necessary to build a successful MVP.

The future of apps and their platforms

There’s no way to be sure what advancements in tech will look like, and predictions about the future rarely come to fruition as we expect, but there is one trend that has remained throughout the explosive growth of the internet of things; people use more, want more, and expect more.

If you’re in the ideation stage of app development, consider what you’d like to see happen. Wearables are expected to represent a $34 billion industry by next year, and right now, mainly focus on health and fitness apps. As of now, in 2019, AppleWatch is the leader of the pack when it comes to smart watches, but this could very easily change.

Android, and Google, by proxy, have cast a very wide net when it comes to exploring new avenues for devices through which to engage users, and Apple, like usual, tends to focus in on a few products to perfect.

There’s no right or wrong platform for any app, but there’s sometimes a better fit. Like any venture, it’s important to do your own market research, and plan based on your own findings. For any appreneur or CTO, the best steps you can take to build a successful app is to know your competition, know what makes your app different, and to do it better than anyone else.