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 it’s 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 MVPWe 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.

How to Build a Mobile App: ASO 101

By now, you’ve probably heard the term “ASO” come up in workplace conversations, whether at a company meeting or from your office’s resident tech expert. We’ve written a few pieces about the topic already – but if you’re a CTO or appreneur that wants to brush up on the basics of ASO without digging through boring dev and publisher guides, you’ve come to the right place!

What is ASO?

It’s an idea that’s been around since the early 2010’s, but don’t be embarrassed if you don’t know too much about it – six years ago App Store Optimization was in its fledgling stage, and it wasn’t until recently that ASO became a necessity like other facets of digital marketing (social media, and SEO for example).

It’s an ever-evolving field, as Apple and Android have spent the past decade revamping and refurbishing their respective app stores – much I the same way Google has updated the parameters and functionality of SEO.

ASO, at it’s heart, is powered by keywords, just like SEO – except with a limited amount of available characters. Think of the difference between ASO and SEO like the difference between Twitter and Facebook; just as tweets must be short, quippy, and straight-forward, so too must be your ASO efforts.

The two fronts of an ASO campaign

User acquisition, and user retention, in that order. These can be broken down into sub-categories:

User acquisition:

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

User retention:

  1. User reviews and ratings
  2. Time users actually engage with the app
  3. In-app purchases (if applicable)

Keywords

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:

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

Tip: Use keywords consistently throughout your app’s title, subtitle, and description. This will help you gain ground as you launch. Don’t be afraid to borrow ideas from your competitors too; if it works, it works. Research is key to your success – consider the consequences of either using the keywords your competition is using, or finding another set of keywords to focus on. Which is more likely to get you traffic? If you believe you can compete, do that. If you’re not so sure, try to catch another segment of your target audience, and slowly build up to where your app can compete with the top performers.

For more info on keyword research, check out our piece on the topic.

The app’s build and compatibility

These are considerations that you should take into account before publishing your app to the App Store – in fact, even before development begins. This is a balancing act, as increasing the number of platforms an app will run on also increases its development cost, but simultaneously increases its potential audience.

Some questions you should ask yourself are:

  • Is my app compatible with the latest devices?
  • What platforms does my app belong on? (iPhone, iPad, AppleWatch, etc.)

Tip: Another big (and often overlooked) factor is your app’s footprint on a device’s storage space. According to this study by The Manifest, 25% of mobile users have deleted an app purely based on the need for extra storage space. The smaller your app is, the less likely this is to happen.

The App Store

Whystle App Store Profile

Above: An example of what an app looks like on the App Store.

This is where all of your ASO efforts come to a head. Your app’s page on the App Store is powered by metadata:

  • Title (limited to 30 characters)
  • Subtitle (limited to 30 characters)
  • Promotional text (limited to 170 characters)
  • Description
  • Up to 3 preview videos
  • Up to 20 promoted in-app purchases

Your app’s icon and preview images also effect how people interact with your app on the App Store – think of these as your app’s visual branding elements.

You app’s title, subtitle, and in-app purchases rank for keywords, while your promotional text, description, and visual elements don’t rank in searches. Every section is important to your user acquisition, however – make sure you give each section its due. This is your app’s brand, storefront, and demo space all wrapped into one – any missing or underutilized section will immediately turn off users from downloading your app.

Tip: A powerful method for improving user acquisition is A/B testing. Don’t be afraid to play around with elements like your app’s icon or description – just make sure you analyze data before and after changes so you can study their impact on conversion rates. If you notice a dip in your numbers, you can always change them back. Subtitles, for instance, are a great place to capitalize on trending phrases. For more info about keeping up with trends, check out our piece written for The Manifest.

User reviews and ratings

Whystle Ratings and Reviews

Above: An example of user ratings and reviews.

Your app’s user reviews and ratings are the middle ground between user acquisition and retention, as they affect (or are effected by) both. If your app has good ratings and reviews, it’ll most likely have high download numbers (or at least higher than if its ratings and reviews were mediocre), and good ratings and reviews usually stem from proper user retention practices.

Apple (and the App Store, by proxy) take your app’s rating and reviews seriously, and they have a direct effect on your app’s ranking – the better reviews and ratings you have, the better of a spot your app will receive when users search for keywords your app is ranking for

Tip: Take heed of users’ reviews, and act upon them. Use updates to your advantage – you’d be surprised at the impact listening to (and implementing) a user’s suggestions can have on your app’s retention.

Time spent engaging with your app

Just as keywords are the driving force behind your app’s user acquisition, the time users spend engaging with your app is the primary factor the App Store uses to determine your user retention. There is no set of guidelines to achieve high user retention, but some determining factors are:

  • Your app’s UI/UX (for novel ideas on how to improve user acquisition through UI/UX, check out our post on the topic.)
  • The way your app was developed (Hybrid vs. Native development)
  • The implementation of retention strategies (Push-notifications and regular updates

There are a lot of different services to help keep track of how users interact with your app (we tend to use Kumulos.) These help with determining what features your users spend the most time interacting with, how they use your app, and can also be used to track crashes, or where in your app users stop their sessions (usually due to slow load times or visual errors.)

Tip: Never underestimate the power of an update. Updates, unlike most push-notifications or requests to rate an app, promote a sense of curiosity in your users; they will be drawn to open your app to see what’s new.

The long and short of it

ASO is the culmination of directly-managed deliverables. Through proper keyword research, utilization, and implementation, good UI/UX, and strategies to engage users within your app, you can turn your ASO campaign into the driving force behind your business. Don’t be afraid to play around with your app’s page on the app store, as trending topics can lead to a surge in your conversion rates, and changes that decrease your app’s performance can always be switched back.

Good luck, and happy ASOing!

Increasing your user retention by giving them control – Our thoughts & experiences

We were sitting around the conference room yesterday, and our Senior UI/UX designer was presenting our latest build (we make a habit of getting the whole team together to look over builds before sending them off to clients). Like a lot of apps, at some point, it eventually had to ask for the users’ payment information, in order to process transactions through a payment service like Blueswipe or Stripe.

Our design team had looked into how other apps went about doing this, our main inspiration being the eponymous Uber. You can see in this video that Uber, like many apps, allows users to peruse what the app offers, and as soon as the user attempts to actually use the service, it requires them to input payment information. One main question arose during our meeting, however; just when is the optimal time to ask a user to input their credit card information?

From a business and sales standpoint, it makes sense to ask for that information right away – any salesperson dreads taking an extra step that can lead to hesitation and second-guessing during the closing of a sale, and especially loathes the idea of taking customers out of the purchasing experience – but user behavior shows a different trend.

Most mobile users are willing to download almost any app when it’s free – there’s virtually no risk (especially on iOS) on their part. But if that app asks for payment information up front, they will almost invariably delete the app.

We had experienced this first hand in the past – an app we had built was seeing about fifty downloads per day, but user retention was abysmal. We could see exactly when and where users jumped ship – as soon as the app required the user to enter a credit card before continuing to use the service.

When we played around with the app’s flow, and allowed users to look at what the app had to offer before it asked for payment information, user retention skyrocketed. The app continues to grow to this day.

It’s actually a pretty interesting facet of user psychology; even when we know a service won’t automatically charge our account, we’re all still leery of putting in financial information, even in a secure digital environment.

I even have a distinct memory of using an old pre-paid debit card to sign up for a free trial on Netflix; a service I knew I would continually use. I had no problem entering in my actual credit card’s information when the free trial period had ended, however, and to this day still subscribe to their service.

I knew I would use their service. I trusted their brand and website. Yet I still delayed entering in my information as long as possible. Why did I do that?

It’s not laziness – my real credit card was on hand – I had to dig through a desk drawer to find an old pre-paid card. Using a pre-paid card ultimately added a step to the process.

At first, sitting in the build presentation meeting, I thought I had cracked the formula for how to determine the reasoning behind a user’s unwillingness to enter their payment information: The service’s value proposition + the user’s trust in the service. I reasoned that if a user can see what a service offers, they are more likely to take the risk of entering in their credit card. After they actually use the service, they build trust in the brand, and the risk of entering in personal information slowly diminishes, until that risk eventually morphs into a reward.

This is all true, I believe, to some extent; but it still doesn’t explain my Netflix free trial experience. I had already been subscribed to Netflix for years under my family’s account – the whole reason I was making my own account was because, as an adult, it’s important to pay for your own streaming services – because, you know, that’s what adults do.

So it was back to the proverbial drawing board – and then it hit me. This isn’t actually about trust, security, or a need to know what the service will bring to the table.

It’s about control.

Asking for payment information up front doesn’t actually reduce user acquisition – it’s requiring the user to input their credit card that causes users to abandon a service or platform. Case in point, try to make a Netflix account without a credit or debit card. You can’t. But you have the option for a free trial. It’s that illusion of choice that makes the user feel like they’re in control, and consequently creates a more palatable situation.

After a pretty in-depth discussion during the meeting, we decided that asking a new user to input their payment information during the initial set up of their account wasn’t a bad thing – as long as they had the option not to.

In fact, this actually adds an element of control in the users’ eyes. The app still eventually requires the user to enter in their payment information, but it gives them the choice of when to input that data.

This doesn’t just apply to asking a user for payment information, however; it’s applicable to tutorials, user profiles, push notifications… almost any feature really.

Tutorials are an annoyance – unless you can skip it. Push notifications are bothersome – unless you requested them.

There’s a trend in UI/UX design to make everything happen in the smallest number of steps possible – which, in most situations, is overwhelmingly good practice. But perhaps, as an industry, when we consider user acquisition and retention, we should consider the power of giving users’ the ability to skip steps. To control their experience within the app. The tutorial is there for the user that wants to know all the ins-and-outs before actually using the app, and the option to skip is there to give the user more control.

This might actually be better UX than not including the extra step to begin with, because it gives the illusion of more control. What’s more satisfying for a user; no experience at all, or the option to say, “Ha ha, I don’t want to do that, so I won’t.”

It feels good to say “no” sometimes. Give the people what they want.

How to find the perfect mobile app developer

So, you’re an appreneur (or a CTO), and you want to make an app. Great! Do you already have a development partner? If yes, even better!

If you answered “no,” don’t worry. We’re going to go over everything you need to know and do to find the perfect developer, just for your specific needs.

Before you get into the trenches and start your search for a developer, it’s important to ask yourself a few questions:

  1. What do I want my app to accomplish?
  2. What platform(s) do I want my app to be on?
  3. What is my competition?
  4. What is my time table?
  5. What is my budget?

Once you can answer these questions, you’re ready to move to the next step – finding a development partner. But first, let’s delve into the reasoning behind these questions.

What do I want my app to accomplish?

This is probably the most important question you can ask yourself, as it sets the stage for all the questions that follow. You should be able to describe what your app does in no more than two sentences. For example:

I want to make an AR app that expedites the training of my technicians and assists them with diagnostics while on the job-site.

What platforms do I want my app to be on?

This question is important to ask; as development, publishing, available markets, and user behavior can (and does) vary wildly between the two main platforms, Android and iOS.

While this question is largely based upon what you want your app to accomplish, there are a few factors to consider when deciding the best answer to this question:

  • In the U.S., Android owns 54.6% of the market, and iOS owns 44.4% (Android is the clear winner globally)
  • More iOS users purchase 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%)

For more information, check out our Android and iOS dev pages, as well as a deep look into iOS development (we’ll be going over Android development soon).

What is my competition?

Knowledge is power. Knowing what you’re up against is a huge boost for your app – while researching your competitors, you can see what works for them, tailor it to your app’s brand, and do it better. If one of your competitors has a high user rating score and good reviews, download it. Take the time to use their app, and take note of features you’d like to include in your own, as well as ways to improve upon your competitor’s flow.

If you’ve searched and found no competition, you might want to consider starting with an MVP, to capitalize on your untapped market.

What is my time table?

The answer to this question is largely dependent on what you want your app to accomplish. A simple app can take less than six months to develop from inception to launch, while a complex app can take upwards of a year.

If you want to get to market ASAP, your best bet is an MVP.

What is my budget?

Again, this is largely dependent on what you want your app to accomplish. A complex app usually costs over $500,000, and simple apps can cost less that $37,500. A few things to keep in mind before setting your budget are:

  • Each feature adds to the overall cost
  • Certain features, like backend integration or heavy graphics have a higher cost
  • Simple apps on average take 250 hours to develop, medium take 1,000, and a complex apps’ development time can take 5,000 hours.

For more information about how to formulate a budget, check out our blog post on the topic. For a personalized estimate for your own app idea, use our mobile app cost calculator.

All of these questions are necessary to answer before you speak to a developer. This will help you communicate more effectively with your developer, and they’ll be able to give you a more accurate estimate about time and cost based upon your answers.

For example, let’s say you want that AR diagnostic app to include a backend data set linked to a server so you can access system data in real time, but you only have a budget of $50,000. Your developer would be able to address these issues before making headway into the project, reducing the chance of wasted, sunken costs.

Don’t use Google to find developers

There are already companies dedicated to finding developers for you. Two sources you can trust are Clutch and The Manifest. There are a lot of sites out there that showcase development companies – but these two you can trust, as they use information from a developer’s client history, client reviews, and ability to deliver in order to determine rankings, rather than a payment hierarchy method.

If you’re already working with a developer who’s not ranked on Clutch or The Manifest, and they’re a good partner, don’t fret – personal experiences should always be weighed over site rankings. You might, however, want to tell your development partner about these sites, as they are just as beneficial for developers as they are for clients.

Using Clutch

Clutch gives you the ability to find developers, set what parameters you want to use to find them (by platform, vertical, or location), and provides you with a breakdown of that developer – from client reviews to service lines, industry focus to what types of business they’ve worked with in the past.

Clutch Profile

Shown above is an example from our Clutch profile of how information is presented on the site

Clutch also hosts a blog where you can find information covering everything from B2B marketing to ASO and beyond.

A nice feature Clutch offers are badges, which developers can display on their site to show that they’re trustworthy. If you see a developer with a Clutch badge, they mean business, and you can rest assured they know what they’re doing.

Clutch Badges

Shown above is an example of our Clutch badges

Using The Manifest

The Manifest operates in largely the same manner as Clutch. The Manifest offers industry leader shortlists, and a blog (that we’ve been featured on!) hosting great thought pieces and business advice.

The Manifest listing

Like Clutch, The Manifest will offer a short bio and client history for each development firm, so you can get a feel for what each developer brings to the table.

And with that…

You’re all set! Happy hunting!

Just remember that you’re always going to have questions – and that’s okay. A good developer will either have an answer for you, or do what they can to find one. Most importantly, your personal preference and business needs should always be taken into account, and if a website is telling you x is the better choice, but you have a good feeling about y, go with your gut.

UI/UX and user retention – Strategies for success

There’s a quote from one of the founding fathers of modern architecture that perfectly describes what good UI/UX is.

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

Frank Lloyd Wright may have been speaking to the principles of good design in architecture, but his words could just as easily be used to describe robust mobile UI/UX design. I doubt the architect had ever dreamed of this quote being attributed to smartphones and mobile apps, but this idea forms a solid foundation of what good UI/UX should be.

He was speaking of the Guggenheim, but his work that most masterfully portrayed this school of thought was Falling Water. But – you may be asking yourself – what does a mid-century home in Pennsylvania have to do with UI/UX?

When a user opens your app, they should feel like they’re going home.

There is no precise, set in stone, foolproof method for ensuring your app’s UI/UX is successful – but there are steps you can take to help achieve this.

What to expect:

  • A look into the blending of UI/UX and user retention
  • Steps you can take during development to help ensure strong user retention

Minimum Viable Product

Speaking of solid foundations, its always best if your app starts with one. The easiest way to ensure this is to begin your development with an MVP (minimum viable product).

MVPs are the epitome of KISS (keep it simple, stupid) and are designed to provide the answer to your users’ pain point – and nothing else. Take a look, for example, at BrewTrader, an app we made. It’s designed to provide one function – to connect craft beer enthusiasts and provide a platform for them through which to trade brews. Each feature exists to provide a single part of the solution, and together as a whole, work synchronously to achieve the goal of craft beer switching hands.

When you are only focused on one goal, your UI inherently builds itself to achieve that goal – and with less tangential features to consider, clean and concise design will most likely come to fruition as a result.

It’s important to note that UI is directly responsible for the vast majority of your app’s UX, and is a significant factor that users will consider when they ask themselves the question; “Do I like this app?”

It might seem counter-intuitive to send out an app to market that isn’t fully complete – but as long as the inner workings are there to solve your users’ singular, crucial pain point, they’ll be pleased. A good MVPs incompleteness isn’t noticeable – and your users shouldn’t be aware they were missing something until after you add it.

As long as BrewTrader keeps the craft beer flowing, users are happy. When tangential, quality-of-life features (like user rating systems, or location services) are added later, users won’t feel like they were short-changed in the beginning – they’ll be grateful for an enhanced UX, and as such, be more likely to continue using the app.

Once your MVP is ready, you can move on to testing.

Testing

App Testing

Testing is one of the hardest steps for any developer – large testbeds are an organizational nightmare for project managers, software engineers are plagued with re-writes, and CTOs are frustrated by the inevitable technical issues that will undoubtably rear their ugly head.

But if there’s one way to ensure good UX, it’s user testing.

There isn’t much to say about this other than to just do it. Testing is used to diagnose flaws in your app – which, while not fun for the devs, is crucial to good UX.

After the first three days of a download, 77% of users have already deleted that app from their device. After 30 days, 90% of active users will have stopped using the app. The lesson here? The odds are always stacked against your app when it comes to user retention. This can be attributed to a litany of reasons, the most common culprits being slow load times, freezing/crashing, janky animations, and even taking up too much device storage.

One of the most demoralizing aspects of testing is that your testers will rarely go into detail about features and UI they liked. It’s much more difficult to express what makes up a well-designed UI than it is to criticize; but take to heart that if your UI isn’t receiving any feedback, it’s most likely because it’s already doing its job. There’s always room for improvement (as with anything in this world) but remember that an app’s UI isn’t a painting – its design should be bold enough to demand attention, simple enough to rely on your users’ intuition, and robust enough to allow additions and updates down the line.

The best way to increase your app’s chance at successfully capturing a regularly returning user base is to throughly test it. By using user stories, you can determine where the trouble spots are – and then hone in and fix the issues. There’s probably never been (and never will be) a bug-free app, but the closer you can get to a perfect app before launch, the greater your user retention numbers will be off-the-bat.

Features

Ever had your device’s keyboard lag while you’re texting? It’s disconcerting when the key you pressed doesn’t appear above your thumb, and it’s hardly noticeable when it works correctly. That’s the sign of a good feature.

A well-implemented feature doesn’t announce its presence every time it appears on a screen; it quietly enhances the user’s experience within the app. In short, your features should flow into one another.

These visual, quality-of-life features that interact with a user’s inputs are called motion design, and are a very simple way to increase your user retention, as they act as visual indicators as to what step the user is on in your app at any given time. Your users should never feel lost – they should feel at home – and one of the easiest ways to provide that comfort is with motion design.

A feature should always serve to enhance the solution to your users’ pain point, so when determining your app’s tech stack, consider; “Does this help my users?”

If it does, great! If it doesn’t, it’s time to go back to the drawing board. There aren’t many features that are directly responsible for increasing user retention (other than push notifications, which 60% of iPhone users disable anyway), but they rather act as a whole to present a polished, useful package for your users.

Don’t be worried if your app isn’t making use of every feature available – if your app doesn’t need location services, for example, it will function better without it. App bloat is real, and less is more.

The most important step you can take when it comes to increasing user retention through features is to make sure each feature works perfectly, and flows into the next.

Updates

Updating your app frequently serves three important purposes:

  • It reminds your users that your app exists
  • It keeps your app’s security up to date
  • It shows your users that you care, and are invested in improving their experiences

Updates are, I would argue, a more effective call-to-action than push notifications. Not only does the notification to update your app serve the same purpose of reminding a user to open your app, it implicitly tells your users there is either something new, or something has been improved.

Keeping your users personal information secure is a no-brainer – any user that notices their information has been compromised by your app will undoubtedly stop using your app and delete it. A large chunk of app conversions come from word-of-mouth; and dissatisfied customers are much more likely to complain about your app than a happy user is to praise it. Never underestimate how damaging a low user review or score can be on your app’s rank within the App Store or Google Play.

Updates that improve your app’s UI, or fix bugs, show your users that you care about their experience. People like feeling cared for – just think about the difference between eating at a fast-food restaurant and dining at a sit-down eatery. We even have different words to describe these culinary experiences – “eating” versus “dining.”

Start with an app that gives your users an experience to dine on, rather than just eat. Then, update it frequently to ensure your menu is consistently fresh and robust.

Users are fickle, until they’re not

There doesn’t seem to be much middle-ground here; if a user hasn’t deleted your app, they’ll either open it once a month, or make it part of their daily lives. In fact, the average mobile user in the US will spend 90% of their time using their top five apps.

There is no set of rules for ensuring high user retention numbers, but clean and responsive UI, through testing, synchronous features, and pertinent updates will greatly increase your app’s chances of success.

Out-of-the-box tools you can use to make a targeted ASO campaign

A trend we see a lot in this industry are great ideas with no legs. Sometimes it’s for the usual reasons – lack of monetary investment, insufficient market research, or a belief that anything is possible with tech – but all too often, the hurdle that’s most difficult to cross for an appreneur (or even a large company for that matter) is planning how their app will succeed once it’s on the App Store or Google Play.

What to expect:

  • A quick look into how and why combining ASO with SEO campaigns is a strategy for success and efficiency
  • An instructional tour of SEO tools Answer the Public and Keywords Everywhere, and how to merge these into your ASO campaigns

Plan your ASO now

The app store is a big and scary place for a fledgling app – and it’s all too easy for your great idea to drown in the seas of the App Store and Google Play. ASO (App Store Optimization) is not only your app’s lifeline, however – it’s the vehicle for your app’s growth. Your ASO efforts should constantly evolve with trends in the marketplace – but setting a solid foundation before your app is launched can save you the trouble of future headaches.

While still relatively new, ASO is as important to your app’s success as SEO is to your website’s, (to be fair, SEO is still new when compared to traditional marketing channels) and should be treated with the same care as your company’s brand. ASO, in fact, is your branding and the channel simultaneously.

I like to think of the App Store or Google Play like a giant mall – stores in a mall use signage to draw in customers, and then provide a unique experience for shoppers while they’re in the store. ASO works in pretty much the same manner – apps use keywords and their icon to entice users to look at their page on the App Store, and the page itself serves to provide those users with a unique look into what their app offers, and how it can help them solve a particular pain point.

That’s the driving force behind every app – a pain point. It’s almost too simple to look at apps everyone knows about and determine the pain point they were created to solve; Uber wanted to give users the ability to hail a cab without waiting for one to find them first, AirBnB gave travelers a network to find affordable accommodations in expensive areas, and WhatsApp was made to serve as an all-in-one communications channel for voice, video, text, and almost any form of media under the sun.

All of these apps have grown in scope and functionality, but their adherence to providing a specific solution to their original pain point remains, undoubtably due to their market research. The market research findings that dictate the pain point your app focuses on should also dictate what your ASO focuses on.

This is why when you’re conducting your own market research, and you’re entrenched in campaign ideation, it’s the perfect time to plan your ASO. You can then directly utilize your market research findings and implement them into your ASO campaign. There are plenty of ways to do this, such as classic market research tools like focus groups or surveys, but there are a lot of online services that can help jumpstart your ASO campaign, and provide insight into your customer profile. We’ll cover two:

  • Answer the Public – This is an SEO tool first, and an ASO tool second. Luckily, what works for one usually works for the other.
  • Keywords Everywhere – This is used to provide insight into specific keywords’ value and competition. Again, this is an SEO tool, but it’s just as valuable for ASO.

So how do SEO tools help my ASO campaign?

Ever since the advent of Google, the idea of searching has morphed into “Googling,” and people tend to use the search function of any site or service in much the same way as they would Google.

According to MOZ’s Beginner’s Guide to SEO, (the best SEO resource out there) people use the search function in three main ways:

  • To do something – A user would search “buy hiking shoes” to find different options of hiking shoes to purchase.
  • To learn something – A user would search “what are the best hiking shoes” to find out what hikers are saying about different brands.
  • To go somewhere – A user would search “Made-up Brand hiking shoes” to go directly to an online store.

People on the App Store or Google Play largely use the app store’s search function in the same way. Searches on the App Store and Google Play generally fall into the “do something” and “go somewhere” categories.

According to Statista, while the largest channel for app discovery is through the search function of the App Store and Google Play, more apps are discovered from channels outside of the App Store and Google Play. These channels (ordered from highest percentage of discovery to lowest) include:

  • Friends and family
  • Social Media
  • News, reviews, and shows
  • Websites
  • Web Ads
  • Traditional Ads

All in all, those six channels account for 58% of all app discovery, and out of those six, five are influenced by SEO.

Answer the Public

So, let’s say you’re working on an app that sells hiking shoes. In order to find out what people are searching for when it comes to hiking shoes, it’s best to start with Answer the Public.

To begin, simply start by typing in a phrase (it’s best to start with generic, non-specific phrases). In this case, the phrase “hiking shoes” was used.

Answer the Public example

Answer the Public will break down that phrase into five categories:

  • Questions associated with the phrase – e.g. “Which hiking shoes to buy?”
  • Prepositions associated with the phrase – e.g. “Hiking shoes for kids”
  • Comparisons associated with the phrase – e.g. “Hiking shoes vs. trail running shoes”
  • Alphabetical listings of words added to the phrase – e.g. “Hiking shoes Amazon” and “Hiking shoes black Friday”
  • Popular related searches – e.g. “Hiking shoes near me” or “Hiking shoes for sale”

This is a great tool to not only help your SEO keyword ideation, but also your ASO. While you add keywords to your website, (a channel that accounts for 10% of app discovery) add those same keywords to your app’s page on the App Store and Google Play. If people are searching for “Hiking shoes” on Google, they’re most likely searching for the same thing on the App Store.

You can use Answer the Public to stay in the know about what people are searching – and continuously update your keywords to reflect those searches. Unlike SEO, however, ASO should be limited to five keyword phrases (which should repeat throughout your app’s title, subtitle, and description for maximum effect) so keep that in mind when updating your page on the App Store. For example, our hiking shoe app would most likely always include the keyword phrase “Hiking shoes for sale,” as that’s the app’s main purpose; other keywords can be implemented and switched to capitalize market trends.

Keeping up with search trends is a powerful tool for maximizing your app’s success. For instance, more people hike in the summer, so adding key phrases such as “summer sale,” or capitalizing on nature-centric holidays like Earth Day with phrases like “Earth Day sale” can bring temporary but powerful boosts to the amount searches your app will appear in. By continuously using services like Answer the Public, and updating your keywords to reflect current trends, these temporary boots can become your norm.

Keywords Everywhere

An add-on for Google Chrome, Keywords Everywhere is easy-to-use, free, and tremendously helpful. When paired with Answer the Public, this tool really begins to shine.

This add-on will automatically detect keywords and display the monthly search rate, cost per click, and competition for each keyword. When paired with Answer the public, it looks like this:

Keywords Everywhere example

And when used with a Google Search, looks like this:

Keywords Everywhere example

Working from the above example, let’s look at “best hiking shoes” versus “hiking shoes womens.”

“Best hiking shoes” was searched 22,200 times in January globally, its cost per click (CPC) is $1.71, and its competition is 1 (very high).

“Hiking shoes womens” was searched for 270 times in January globally, its CPC is $1.18, and its competition is 1 (very high).

By comparing the two, we’re able to glimpse some important trends:

  • “Best hiking shoes” is about 82 times more popular than “hiking shoes womens”
  • While both searches are highly competitive, “best hiking shoes” fits into category 2 of types of searches: To learn something. “Hiking shoes womens” fits into category 1 of types of searches: To do something. Due to this, “hiking shoes womens” is the more valuable key phrase.

So why is “hiking shoes womens” the better option? Intent.

Someone searching for “best hiking shoes” probably isn’t looking to purchase anything (at least immediately) – they’re most likely conducting their own research into what brand of hiking shoes would be their best option. While it’s a popular search on Google, the number of conversions that directly come from “best hiking shoes” is most likely low. There is, however, great value in a key phrase like ”hiking shoes womens,” as someone searching this key phrase isn’t asking a question, or searching for more information – they’re looking for a store from which to buy hiking shoes for women.

This knowledge can then be transferred and utilized with both your SEO and ASO campaigns.

Both of these key phrases would be good for our hiking shoes app’s ASO; “best hiking shoes” because it is searched so frequently, and “hiking shoes womens” because people searching this phrase already know they want an app that sells women’s hiking shoes. With such high competition for both of these keywords, however, it would be pertinent to add in keywords with lower competition, such as:

Keywords Everywhere example

This key phrase shows two very promising factors:

  • While the volume of searches is low, every search is implicitly describing the intent to purchase hiking shoes
  • It has low competition, so the low volume of monthly searches is balanced with a more accessible playing field

All in all, it’s a balancing game between finding keywords that are searched for regularly, and making sure the competition you’re facing is accessible.

ASO early, ASO often

While it always helps to come out strong with your ASO campaign, it’s never too late to start. These tools are free for anyone to use, and can provide great insight into both your SEO and ASO efforts. By pairing your SEO and ASO, you can more effectively target and capture audiences, and create conversions from clicks.

iOS Development and Swift Code – What you need to know

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

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

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

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

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

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

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

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

The tools available to developers

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

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

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

The Swift process

Android Pie and iPhone 12.1.2

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

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

In order to do this, developers:

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

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

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

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

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

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

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

Glossary of developer jargon:

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

AR – It’s time to start thinking about it

There seem to be new technologies and trends emerging every day as the internet of things grows to envelop and shape the way we interact with each other, our jobs, and our hobbies. Today, one of these hot-topic-pieces-of-tech is augmented reality (AR).

With the release of Apple’s ARKit in June 2017, and Android’s ARCore in March 2018, mobile developers now have the tools to natively develop AR apps for smartphones, wearables, and even cars. If you’re a business that isn’t in the industry of user-facing software and products like Google or Snapchat, it might be easy to overlook the value of implementing AR into your daily procedures, or difficult to determine just how AR would work for you and your company.

Before we get into how your company can implement AR into its business model, let’s go over why AR (despite being a relatively new and untested technology) is probably the most exciting field of innovation for consumers and business alike.

In October of 2001, it was difficult to imagine that the iPod would completely revolutionize the technological landscape. We’d seen the evolution from records to cassettes and 8-tracks, to CDs and Walkmans – but all that had changed was the size and mobility of the music player – listeners still interacted with their devices using play, skip, stop, etc. It wasn’t until the iPod came to the market that a device changed the way listeners interacted with their music – suddenly, you didn’t need a backpack to carry your CDs, and track titles were visually displayed in searchable lists. The planning required by an individual to take music on the go was replaced with the ease of picking up a device with all of your favorite songs on it, and simply putting it in your pocket. This led to a drastic shift in the way people thought of their interactions with their music players – you listen to a Walkman, but you use an iPod.

We all know what came next – the largest shake-up the music industry had seen since the switch from analogue to digital recording – and like any significant change to a market, there were growing pains aplenty as artists and producers alike adapted to the changing climate.

It’s a trend that has continued rapidly ever since, as advancements in technology revolutionize every industry imaginable. In 2007, when the iPhone was first introduced, people stopped talking on their phones, and started using them. A year later, Android phones were on the market, and soon enough, smartphones evolved from a trend-setter status-symbol to ubiquitous multi-tools used to enhance almost every aspect of our daily lives. It took only six years to go from a device that holds 1000 songs to smartphones that put Captain Kirk’s communicator to shame.

Well, it’s 2001 all over again; except this time, it’s not music – it’s augmented reality.

Training and quality control

Imagine hiring a new HVAC technician. For that new hire to be successful, they must be trained, which means another technician is either pulled from their current job, or given the extra responsibility of teaching while also working. This is the way skilled trade knowledge has been passed down from expert to apprentice since the dawn of time, but it lacks the efficiency AR provides.

With an AR enhanced training program, that new technician can learn the ins and outs of HVAC systems on their own, without receiving instructions from an experienced employee – greatly increasing productivity and reducing the total cost of the hiring process. New employees are not only trained on their own – they are also trained more effectively, as AR ensures each training session disseminates the correct information and processes every time.

AR allows that new technician to see every layer and part of the HVAC system – from individual screws to the entire ventilation structure – and how each piece fits together. Your trainee can experience every possible type of mechanical failure for the system, and learn the appropriate remedy at their own pace.

Imagine being able to provide real, on-the-job experience without ever risking inefficiency or error at an actual job site; with AR, a technician can become an expert without ever going into the field.

When it comes to manufacturing, AR is the ultimate quality control assistant. Manufacturing jobs such as those on automobile production lines require high levels of accuracy, utilize a staggering number of parts, and rely on step by step processes that can easily be forgotten or implemented in the wrong order – especially during a long shift.

AR can, in real-time, highlight the next step in the assembly process, show where and how the parts are implemented, and check for accuracy after the step has been completed.

To see how this works, check out this amazing AR system by SCS Concept Group, VPG+.

Efficiency

Industries that utilize automated equipment, such as manufacturing or mining operations, can easily be enhanced with AR diagnostic systems. A fun project we did for Luckstone (one of the largest family-owned and operated producers of crushed stone, sand, and gravel in the U.S.) was an AR app that enhanced the productivity of quarry operations by providing the foreman with an interface that allowed on-site remote data analysis in real-time. The user points their mobile device at an operating machine, and a tag is displayed on the device’s screen – that tag can be expanded, providing real-time data on pounds of stone moved, operating efficiency, and any other data point relevant to the operations of the machine.

This saves foremen the wasted time of either walking across the quarry to the specific machine, or leaving the job site to analyze data in their office. This system was adapted to their business development team’s needs, and we developed an app that gave sales representatives the ability to access cloud data on past, current, and prospective clients based on geo location.

The sales representative points their phone towards a business, and in real time, information on past interactions with that customer is displayed on their device, giving them the ability to research potential clients, follow up on leads, and ensure they don’t mistakingly visit the same business twice, all in real time.

AR may be new, but it may just be the next big thing

It was only in 2017 when Apple released ARKit, after all; but AR is already making waves in the mobile industry. In 2018, Snapchat, which heavily invests in AR technology, posted a net worth of $3.2 billion. With leaps in advancement with wearable technology, and the integration of smart technologies in cars, it wouldn’t be surprising for AR to become commonplace in our daily lives in the coming years. It might even come to be expected by users – in 2006, if someone had told Jack Dorsey that Twitter would help decide the 2016 presidential election, he’d probably have laughed – but a social media startup became so integral to the way we communicate our ideas that it did just that.

We’re right at the cusp before the AR industry begins a rapid period of growth, so now is the time to start planning just how to implement AR into your own business’ needs.

How to Build a Mobile App: Native vs. Hybrid Development

Every business and entrepreneur wants to push their product to market with the smallest investment of time and capital as possible, and for good reason. It makes sense as an appreneur to seek out the method of mobile development with the lowest cost, which is usually hybrid app development.

In our second installment of How to Build a Mobile App: The Ultimate Guide, we’ll look into the pros and cons of both hybrid and native app development, and shed light on why when examining the entire lifecycle of an app, we believe native is the more cost effective choice.

It is important to note that this is a topic of debate with a wide and varied array of opinions and conclusions. Throughout my research on the native vs. hybrid debate, the overwhelming consensus is that “it depends on the developer.”

Developers and blogs are quick to espouse the pros and cons of native and hybrid apps that the tech industry has agreed upon, but there seems to be little supporting evidence as to where these findings originated, other than from their own personal experience. Articles, thought-pieces, and blogs have all come to contradicting conclusions based upon the same sets of data, and these conclusions seem to arise from the opinions and skillsets of the developers or authors themselves.

Regardless of any opinion about native and hybrid development, the most important step you can take as an appreneur or business is to work with a developer you trust – but it is important to know how each method of development can influence your app’s future.

This is a debate that seems to be mainly fueled by opinions rather than stats – but we will provide as much insight as possible by using what case studies and supporting data are out there.

There are many different lenses from which to view this debate, but we will mainly focus on answering these questions:

  • What is hybrid development?
  • What is native development?
  • What do they mean for your users?
  • What do they mean for your business?

What is hybrid development?

Hybrid development follows the naming convention of most dev terms, and does exactly as its title implies; it utilizes a software development kit (SDK) to make an app that can run on multiple platforms (Android and iOS, for example) and is coded using HTML, CSS, and JavaScript – as well as others.

A hybrid app’s code is passed through a “wrapper” that the OS can understand – like an English speaker using a phone to translate a conversation with a Spanish speaker. Hybrid apps rely on plugins to access your device’s functionality – such as the device’s native hardware, camera, mapping, messaging, and email functionalities. Plugins are built and supported by third parties, and a hybrid developer doesn’t have control over how a plugin functions – only when and where it is implemented.

In a similar vein, a progressive web app (a hot topic right now) uses the device’s native browser to access a website specifically designed to display information on a mobile device. It’s akin to clicking a hyperlink, but instead of taking you to a link, it takes you to the site where the app is hosted. The app isn’t visually displaying the browser layer, but uses the device’s browser as a way to connect the device to the app.

Relatively new to the development scene is React Native, which allows developers to code an app using the same UI (User Interface) blocks as a native app, but written in JavaScript and React. It’s basically a hybrid of native and hybrid development, giving developers the opportunity to mix web-based languages with their native counterparts – and provides developers with the option to use JavaScript and React for simple processes, and the device’s native code for heavy lifting and pages that must be tight and responsive.

What is native development?

Just like hybrid, native development’s name describes its exact method of app creation; apps are coded using languages native to a specific platform, such as using Swift to write for iOS, or JAVA for Android.

Native apps can seamlessly integrate with the native functionality on your device – this gives native developers the opportunity to focus on designing the main aspects of your app, rather than spending time working with third party plugins to achieve the same functionalities already included on your users’ device. Native apps are also more secure than hybrid.

What do they mean for your users?

Your users honestly don’t care if your app is built using hybrid, native, progressive, or React Native development. They care about solving their pain point – and how well your app solves that problem. Whether it’s Snapchat (a natively-developed app with a focus on iOS) solving the dearth of filtered selfies, or an HVAC engineer using an augmented reality (AR) app to run diagnostics on a broken system, your users care about how responsive your app is to their inputs, the intuitiveness of its UI, and the quality of the solution it provides.

Users want your app to feel like it belongs on their device; they don’t want to be forced to learn how to use your app. They want your app to work for them, and the easiest way to ensure your users are provided with an intuitive UX (user experience) is to natively develop your app.

When it comes to UX/UI, natively-developed apps will almost invariably perform better than hybrid. Native apps are not only coded for a specific platform; they provide a UI that is designed to the standards and conventions of that platform. To put it simply; using an iPhone feels completely different than using a Samsung. They both display interactive information across a touchscreen; and for a user, that’s just about where their similarities come to an end.

Over time, Android and iOS users have come to expect certain commands to perform specific functions, and both platforms rely on their users to interact with apps using different sets of intuition. Both platforms have released style guides for developers to follow, which can vary significantly in their principles of design and function.

Take, for example, the difference between the home screens of Android Pie and an iPhone X:

Android Pie and iPhone 12.1.2

Above (left to right): Android Pie, and an iPhone X running iOS 12.1.2

Have you ever borrowed a friend or colleague’s phone, only to be presented with an unfamiliar UI? It’s a jarring experience, and it’s an excellent example of the personal connection we share with our phones and other mobile devices.

Android users will intuitively search for the “hamburger” (three horizontal lines stacked on top of each other) style menu to access information, while iPhone users will expect bottom menu bar navigation. It seems pretty straight-forward to adapt to either system, but users quickly form strong opinions based on their first interactions with an app, and users are more likely to uninstall your app than keep it. Within the first 3 days of an app being downloaded, 77% of the users who downloaded it have already uninstalled.

An important thing to keep in mind is that your app is not the only one on a user’s device. There are most likely apps competing for your users’ attention, and those users are liable to switch to another app at any time – especially if it doesn’t provide the best experience possible. According to Dynatrace, a software intelligence company, 48% of users are less likely to continue using your app after a negative experience, 31% are less likely to purchase another app made by your company – and will spread negative word-of-mouth marketing to their friends – and 26% will give your app a negative rating.

This is why your development method matters to your users. An app with a hybrid design will run on both platforms – but it won’t run as well as a native app. A hybrid app will always be forced to sacrifice the aspects of the user experience that make each platform unique; and because of this, your app will feel less personal – and mobile’s strongest attractor is the personal experience it provides.

If your app isn’t responsive, and doesn’t flow seamlessly with the rest of the UI/UX a platform offers, users will grow frustrated – which can lead to them switching to a competitor, or giving your app a bad rating or review.

What do they mean for your business?

Simply put, hybrid development will almost invariably have a lower initial cost and faster development time when compared to native. This is for two main reasons: There is no extra cost to write code that runs on multiple platforms, and they are written using languages web developers already know.

This means that when developing for multiple platforms, hybrid development takes roughly half the time of native, and opens access to two markets for the cost of one. This method of development usually comes with a lower billable rate, as web developers make about 20% less than mobile developers and spend less time coding and testing (initially), as the app runs on every platform using the same code.

These factors indicate hybrid development has both a lower initial investment and opportunity cost when compared to native, and are extremely compelling reasons to choose hybrid over native; but the lower up-front cost and doubled market size are traps that can lead to issues down the line that can severely hamper your app’s growth and sustainability.

It was in 2012 when Facebook CEO and tech giant Mark Zuckerberg was quoted saying “the biggest mistake that we made as a company is betting too much on HTML5 as opposed to native,” in an interview with TechCrunch. “[I]t just wasn’t there,” he continued. “[S]ince we’ve done the iOS app we’ve seen double the amount of feeds people consume.”

The social media company had many reasons for switching to native development, which were presented in a post detailing the performance issues and limitations Facebook encountered with HTML5. Some of these performance issues include:

  • Lagging scrolling speeds
  • Janky animations
  • The overload of data in the feed would sometimes cause the app to crash

These were issues Facebook deemed important enough to spend the time and money on developing their app natively, and is a perfect example that no matter how large your market presence is, your UX is crucial to your app’s continued growth and success.

A hybrid app may have a lower initial cost than a natively-developed one – but a native app will provide a better experience, and only the best apps perform well on the App Store and Google Play. In 2016, the top 200 apps on the App Store had an average of $82,500 in daily revenue, while the top 8,000 apps had an average daily revenue of just $3,500, a stark decline that demonstrates the need to be the absolute best at providing the solution to whatever pain point your app aims to solve.

As another example, in 2016, AirBnB took a leap of faith and began development using React Native, a switch from their native development roots (a five-part, in-depth study into their experiences with React Native can be found here). Ultimately, AirBnB decided to switch back to native development for many reasons, including:

  • There were technical and organizational issues with React Native that hampered development, causing unexpected delays on projects that could easily have been completed using native code.
  • It turned out that while their app was created using React Native, only a small portion of the app was truly coded using React. In order to work effectively, bridging infrastructure was required, and the engineers were forced to add to their work load by supporting code on three platforms instead of two.
  • While build time iterations were an order of magnitude faster than native, debugging could take days.

When comparing the cost of developing an app for both iOS and Android, native development will always be more expensive than hybrid, as code must be written separately for each platform, leading to more billable hours – but keep in mind that companies like Facebook and AirBnB have deemed that investment to be worth it.

Web developer for Mozilla, James Long, even released a thought-piece in 2015 detailing why hybrid apps will never compete with native when it comes to performance and UX.

Your users decide whether or not your app is successful, and their decision is based on their experiences using your app. Your UX is largely determined by your app’s method of development, and native development almost invariably provides a better UI/UX.

In an interesting study, Alex Sullivan (a developer and writer for thoughtbot) created a simple stopwatch app for Android using three development methods: native, React Native, and Flutter (a hybrid development kit). When testing on a Nexus 5, the natively-developed app beat out both the React Native and Flutter apps by a “non trivial margin when it comes to performance,” and both CPU and memory usage were lower on the native app than the React Native and Flutter apps.

If your app does the same thing as a competing app, but the competing app does it one second faster, users will switch to your competitor. If there is a marked difference in performance for an app that only functions as a stop watch like Sullivan’s, its easy to extrapolate why companies like Facebook decided to switch to the more expensive option of native development; they were worried someone would do it better and faster.

Android Pie and iPhone 12.1.2

One of the most important factors in determining how successful your app will be is your app’s App Store optimization, which is colloquially abbreviated to ASO. ASO is used to boost your app’s ranking in the App Store and Google Play by utilizing trending keywords to catch users searching for a solution to their particular pain point.

In the future, we’ll take an intricate look at all the strategies you can utilize to perfect your app’s ASO.

Other than keywords, your app’s user ratings, reviews, and retention are the key variables used to determine your app’s ranking on the app store. Each of these factors has a direct correlation with your app’s UX/UI, and this is where the trap hybrid development sets becomes twofold; with a cheaper and more direct path to a multi-platform release, you set yourself up to fail twice as fast, and twice as hard. Beating another appreneur or business to market is all well and good, but as soon as a competing app comes into the picture, it only has to provide a slightly better UX/UI than yours to begin siphoning from your user base.

This is where the longevity of native and hybrid development really starts to split. All apps require updates throughout their lifecycle – sometimes due to the platform itself updating, security issues, implementing additional functionality, or improving UI to follow current design trends.

If your app is hybrid, when an update for a platform is released (no matter how small of an update), you must check every plugin to make sure it’s still functional. If a plugin isn’t functioning properly, the developer must wait for the third-party provider to update the plugin itself – this can lead to downtime that is both out of your control, and your developer’s.

Hybrid apps must constantly be re-worked and tweaked to function properly on different platforms, and you’ll often attempt to solve one issue on one platform, only to begin working on a different problem for the other.

The trap set by the initial low cost of hybrid development becomes exponential by this point; a hybrid app’s UX/UI will under-perform natively-developed apps on both Android and iOS, which in turn leads to lower user ratings, reviews, and retention on Google Play and the App Store. Even if your hybrid app provides the best user experience it possibly can, there’s most likely a native app out there that’s doing it better. If a competing app’s average user rating is a four, and your’s is a three, those ratings add up, and can lead to a significant disparity between the two apps’ ASO and overall ranking.

A hybrid app, by this point, is stuck between a rock and a hard place. It may have been on the market for a longer period of time than a native app, but time on the App Store or Google Play isn’t the key factor in determining your app’s success: it’s ASO. The hybrid app will constantly be battling the low or mediocre user ratings it receives, which is a huge handicap to your overall ASO score. You must now weigh the options before you: constantly provide users with updates to keep up with competition and the standards of multiple platforms, or walk away before your sunken costs get out of hand.

A native app also has the added benefit that a large chunk of your app’s ASO comes from a passive source – those being user retention, ratings and reviews – and since those factors are already robust, it gives you the ability to focus purely on keywords (the lifeblood of successful ASO) and trending topics.

It’s like building a house; it doesn’t matter how pretty the paint is if the foundation isn’t sound. A house with good bones might have a higher initial cost and take longer to build, but throughout the years it requires much less maintenance, and updates to the home can add additional rooms rather than fixing extant issues.

Interestingly enough, while hybrid apps require more updates and usually have a higher rate of bugs and crashes when compared to native apps, 44% of hybrid developers don’t track errors and crashes (this stat comes from an article arguing hybrid is a better option than native).

The pros and cons of hybrid and native development

Hybrid pros:

  • Quick development cycle
  • Low initial cost
  • Multi-platform
  • Low initial billable rate

Hybrid cons:

  • Compromised UX/UI
  • Frequent updates
  • High maintenance costs
  • Handicapped ASO

Native pros:

  • Robust UX/UI
  • Reliable
  • Secure
  • Longevity

Native cons:

  • Slower development cycle
  • Higher billable rate
  • Higher initial cost

If you’re considering building an app, and are worried about the up-front costs of native development, remember that you can always start with a natively-developed MVP, and build from there. Taking the extra initial time and cost to produce a native app will inevitably save you money if you plan on your app being around for more than a year, and it’s better to start with a solid foundation than trying to go back in and fill cracks later.