How does my app work with my Business - woman presents an app to a man - image by undraw.co

How does my app work with my business?

How does my new app work with my business? Its something you need to know as a new app owner. Image credit: undraw.co

How does my App Work with my Business?

How do I know what I’m getting when I build an app? What are all the parts that I need to make sure it works and keeps working for my customers?  How can I be sure my app is an asset for my business?

If you’re asking these questions then you are in the right place. These are exactly the sort of questions that a product owner, app entrepreneur or business owner ought to be asking when they want to be sure the app they are planning will work effectively.

This is the fifth post in my series how to build an app. In this one I’ll be looking at more advanced material then in the previous four articles; which cover how apps work, what kind of apps there are, how apps get built and how you make money from apps. If you haven’t seen those, you should go back and read them unless you’re already an accomplished app builder.

Getting up in Your Business

In this post I’ll be covering how the backend of apps communicates with your business to provide value for your customers and for you. We will be looking at what happens behind that glossy user experience, to automate business processes.

We’ll be digging in to discover what it is that you get your hands on when you’re an app owner, who has an app delivered to them.

Teams change and developers leave. What access would you need to continue on? Image credit: undraw.co

What should you expect to be handed to you by your app development team? If your entire app development team disappeared tomorrow, what would you need to carry on and keep building your app with a new team?

And thirdly and finally in this post we’re going to be looking at how you can treat your app as an asset to your business. Something that when your business is valued, that like goodwill and a client list, your app functions as an important part of your businesses balance sheet.

Let’s jump right in.

Tasks are your Business Now

In the first article “How do Mobile Apps Work” we discussed how developers built features in response to user experience designs. In the fourth on “Can I make Money with my App” we discussed how task based designs are used to ensure that your customers can achieve end-to-end value chain transactions inside of your app. 

User experience can model many business flows. Sometimes you need backend architecture designs in greater detail. Image credit: undraw.co

This idea of using experience design to model tasks done by your customers is critical to getting your app to perform effectively. We will return to this through this article.

Term Time: Customers and Business

In this series of articles, I use the term business to refer to what ever it is that you’re trying to achieve, and customers to refer to the folks you want to engage to help you get there. This is true even if you’re a not-for-profit, or in some other way are making an app that doesn’t quite fit the mould implied by “customer” and “business”.

I just don’t like the term “user” when discussing the people who will be engaging with your app. Its inescapable, especially because we have “user experience” in the mix and UX being essential. But I try to use customer in preference whenever I can. In the same way, I hammer business because we want to be business-like when we are working with tech, to make sure its effective, and provides value.

Managing App Effort

So we’re building the app to allow our customers to execute tasks and we have our team writing the code to make this happen.

The code that implements all of this behaviour has to go somewhere. It has to be stored somewhere, as it rolls off the production line from our coding team.

That somewhere is a store in the cloud that we call a repo. A repo is like a large directory or folder, in which developers place all of the code that they write for your app.

That cloud directory has special access protections so that only the developers, and you as the owner of the app can access it.

When developers write their code, as I mentioned in earlier posts they work to create an app package which can be installed on the device – the iPhone or android phone. That package can also be uploaded to the App Store or Google play store.

Code Repo: Core to Automation

In reality the process is a little bit different from that. Yes, developers can write code locally, and then push it straight to the stores.

For a release however, usually the cloud store where the code is placed – that’s our repo – is configured to automatically generate the package. It can be even configured to automatically push the package into the App Store and Google Play store.

Scripts function like bots that test and build your app. Together with the repo they form a continuous integration system. Image credit: undraw.co

Actually its more accurate to say its a special cloud-based app, called a Continuous Integration system (CI system) that automatically tests the code, then generates the app from the repo. But it is the repo typically that holds all the code for the build, contains the versioning details, and nowadays even holds the scripts for the CI system.

So to keep it simple think of your repo as not just a store for you apps code, but also the core of your app building process cycle.

Like a Version?

What’s even more interesting about the repo is that it’s not just a collection of all of the code that your developers have written for you. The repo is versioned. I alluded to this already in the previous section. Its these new version numbers that play a critical role in making frequent app releases.

What this versioning means is that if something breaks in your app the repo can be cranked back to a previous version. One that we know worked okay. 

Repository Data lives in the Cloud

So there’s a lot of cloud stuff going on here. I’ll just go over these two again.

First we have the code that’s been written by the developers stored in the cloud, in the repo. If you hear names like “GitHub” and “BitBucket”, that is your repo they’re talking about. You want to make sure you have the passwords or keys to access it & administer it.

Second we have the App Store & Google play store where packages are pushed to. And that’s in the cloud too. You need passwords to access those too.

Repository: Holds code, versions it, secures it, and drives releasing an app to the stores. Make sure you have passwords to it.

What you can take from this is the general idea that several cloud-based systems are all working together, like a well-oiled machine, to process the the code and other outputs from the people in your app development team.

That system culminates in the App Store and Google Play store, but it starts with your cloud based code repo.

So when you think about what you get if someone builds you an app, it’s the keys to that repo that you want. It’s the goose that lays the golden eggs. Or at least lays the new updated versions of your app that you’re going to want down the track.

What Happens with Updates?

Now, once your customers download a new version of your app, they can open it up and the app and connect to cloud services to access additional functionality. We discussed this briefly in the previous posts on How Apps Work.

Let’s have a really good think about app updates (made by your development team); and about updates to the items that appear in your app (like services or menu items, or clothes for sale).

A customer may access a product for sale inside of your app, and complete a transaction to order that product to be delivered.

Customer payment transactions need special care in your app. Could they get charged and not receive what they paid for? Image credit: undraw.co

For this to work the app will probably need to contact a store API to check that there is sufficient inventory of the product to fulfil the order, collect the customers details, and then connect the customer to a banking API provided by your e-commerce solution.

So that is in a for-instance internet store app:

  • Your online storefront (a web-app)
  • Product fulfilment (drop-shipping or inventory)
  • Banking or e-commerce (PayPal or Stripe)
  • CRM system for customers details (Zoho or Hubspot)

What if one of these four change? You release a new app version right?

But unlike the web, your apps update when a new version is released to the App Store and installed by your customers. So you need for the old and the new version to work with all of the above services.

You’ll have customers out there with the old version of the app. Maybe for quite some time. They may just choose not to update. You at least need to not crash the app, and display some useful message like “Please update”.

Cloud or In-App?

Let’s say you manage digital for a small food chain. You have maybe a dozen restaurants in the country. And let’s say you update your menu.

You as a business app product owner may access your web-app, and update your restaurant menu in response to recent changes. Then submit those changes so the new menu goes live.

So where does the menu live? Cloud, or in-app?

If its in the cloud only – say via a hybrid app web-view, then customers who don’t have internet at the time they check your app cannot see the menu.

But if its on the phone only it makes your app downloads bigger, and you need to make an app update, just to change your menu.

In reality a good design might be to have it in the cloud, with a local cache, and a default that is installed with the app. So it’s in both places.

Stock in Trade

In your business what is providing value might be physical things you’re selling as items. Or it might be posts and reviews to your pet-minding or childcare app. Whatever they are, these items are your business to care about, if your customer is to succeed and lead to your app success.

What does all this mean from the point of view of your business?

It means that you really need to think about items that are going to appear in your app. Think about those items as part of a task it’s going to be completed by your customer – like viewing a menu, or a review.

And when you think about it, decide which details of the items have to be in the code and be shipped as part of the app. That details will be shipped to every single phone that has the app installed.

Ride share companies have Standard, Luxury and People-Mover options in their menu. Its easy to fix these in the app & update price etc from the cloud. Image credit: undraw.co

Also think which other parts will need to be live in the cloud and will need to be connected to and updated when the app is actually used.

Often the best way to visualise this is with detailed User Experience flows.

Alternatively there might be best practice for the stores or back-end API’s that you are using. So you might use a dedicated review site API. Either way you’ll need to think about where the information about those items is stored.

Viewing and Updating: Two Different Customer Tasks

Think about a case of products that are ordered in an app. In this example case only the cloud that the phone app connected to knew about the details of the products. But the app needs to know how to display them once it gets from the cloud the list of products that were available.

One pattern I have implemented for an app with In-App Purchases is to have 7 items that comprise the purchasable products. These 7 items are coded into the app, along with a name, description, category, price and photo. The app knows how to display all of these things in either a detail view for the item, or in a list of all items.

Let’s imagine one item is not available.

The picture changes if the app allows updates – that is the customer could review or purchase an item. Here we need to be careful.

For stores where items are a selection from a slow changing range, model them in the app and update availability online. Image credit: undraw.co

To check that we’re OK to display an item, our app can connect to the fulfilment centre and update the inventory amount, find that the item is out of stock, or off the menu, and update the view, so only 6 items appear in the store view.

This way you have a double-entry approach to the items in the app. The app knows about base items, and how to display them.

But that model is updated from the cloud, when the customer interacts with the app.

Out of Sync or Out of Stock

In the case of the menu for the restaurant, it might be possible to store the menus inside of the app when the code is being written. If you have items that are for sale, that are ordered up, like say a cake shop, it might be that you stop doing a particular item.

You could ship the app to the App Store with the menu inside of it. Customers could download your app and quickly see your menu of cakes without having to even connect to the Internet.

But do you see the problem here?

If you are not able to make say the carrot cake because carrots are in short supply, then you make it unavailable on the web-app; you need to make sure that the customer cannot place an order for it in the app. If a customers card was to get charged, and no cake was supplied that is a very bad result.

You need to think about what would happen if connectivity to the web-app was out – say due to your site being down for maintenance. Could the app still connect to Stripe?

Update transactions, especially ones involving customers money, need to be very carefully planned out. Handle error and no-network as well as success cases.

So here you need a “fail-closed” or “fail-safe” design for the user-experience flow. If the app does not get updated with a non-zero amount of cakes available, then it will show “out of stock” even if the app could not connect to the site.

Some very simple apps just function like a flyer or a brochure, and display information that changes infrequently. This can be okay if that’s all you need. But be very careful with update transactions.

Take Advantage of Dynamic Data

We talked in the previous post about stickiness being really important. We discussed ways to get customers to revisit your app. One way is to be updating the app with new content – if the app gets updated often customers will open the updated app because it appears on the home screen showing new updates are ready to be viewed, so sometimes it can be good to update the app.

However it can be a pain if you have important information that you need to change and customers have not updated the app, and thus seeing old information.

Tabbed apps with a profile have a chance to personalise things for the customer. Make them feel special and empowered. Image credit: undraw.co

This is why it’s important to break down the tasks that your customers are going to be completing inside of your app, step-by-step and think clearly about which parts of those tasks need to interact with data that is going to be stored on the cloud, versus data that can be stored inside the app itself.

Your app should know about the customer. It has stored information, so use that to display up-to-date dynamic information from your business.

We covered this in the previous section with a “be careful” message. Now we’re going to flip that, and think of the other risk of not having enough changing information.

Access and Roles

Let’s think some more about examples. Take the task of a craftsperson who updates the items for sale on a crafts-for-sale app. The app itself has owners who make the software for the app. But there’s a privileged role for the craftspeople who sell their wares on there. And of course the customers who buy the crafts are a third role.

The first thing that has to happen is there needs to be a way to confirm that whoever it is that’s connecting to the cloud service where the item information is stored actually has permission to change that data. Imagine if the craftsperson had a competitor who wanted to cause trouble – if there was no security anyone could connect and completely wreck their sales. 

So the app has to connect to a cloud service to check credentials of the craftsperson, and once it’s been confirmed that they have access the app can then go ahead and apply the changes.

You could get away with a hard-coded access for the owners of the app – they probably know the passwords they need. But you need something to handle that special privileged user: that something is a role.

Platform-as-a-Service. None Shall PaaS!

In reality it’s common to use what we call a platform-as-a-service or PaaS to provide a lot of the cloud functionality needed for things like login. PaaS is a special case of Software-as-a-Service or SaaS. These days it’s much more convenient to let someone else host that software, hence we can think of PaaS and SaaS as pretty much being the same thing.

If you’ve ever seen login with Google in an app, that’s using Google’s platform as a service.

This platform as a service for all kinds of cloud operations, in addition to login and authentication, including managing data, storing files and playing video. 

So now you understand that there are lots of different cloud components at the backend of any successful app.

UX Needs to be Mapped out for All Roles

There’s the cloud that gets new app versions out. They include the repo from when new versions of the app are pushed to the stores, and the continuous integration systems.

Then there’s your own business cloud, the store data of items that customers want to interact with, your business web-app, and platform-as-a-service providers. We’ll talk more about that last one later.

Even though these backend transactions can be complex, it’s not important to understand all of the technologies involved. Your developers will be across all the issues like encryption, and cloud storage.

A store owner role in a “crafts for sale” app would have different UX, than customers. Image credit: undraw.co
  • UX for Crafts for Sale app
    • Vendor
      • Photo, Description, Price – Modify
      • Reviews – View
    • Craft buyers
      • Review – Modify
      • Photo, Description, Price – View

The most important thing is to carefully break down the tasks that your customer figures will go through an item by item detail where data needs to flow as your customer completes that transaction with your website.

Big Backends

And do that for each type of customer. That is to say each role. Going back to our craftspeople – they are your customers too, if you own that crafts-for-sale app.

If the transaction involves you or an employee authenticating and operating on an administrator basis with your data it’s even more important to think carefully and clearly about every single step of that transaction.

Sometimes your backend, in-house operation scales up and just giving out the admin password to everyone is not good enough. Then you need to manage that as a role as well.

Roles, Items and UX. Oh my!

Ok, so we have covered quite a bit of confusing business stuff. But you can start to see how the complexity blows out really quickly once you have a matrix of roles, items that need managing and both views and online stores of those items.

It doesn’t matter how it’s implemented, your job as product owner is just to confirm that those steps work once the functionality is claimed to have been implemented by the developers.

The best way to deal with this is to put all your matrix of customer use-cases and roles, and item updates into a Great Big Chart. The cells that are not working yet are red, or yellow, and they get marked green once they work.

Product owners can map out complex roles & task interactions with a big chart. These are useful in acceptance testing. Image credit: undraw.co

Spreadsheets can work quite well for this, as long as you use ones that are accessible to everyone that needs to work on it.

In teams that are using a release-often, continuous integration model, the Product Owner can consult their chart to check during sprint review that working software is fulfilling use cases.

Front-load the High Risk

Note that it’s extremely normal for the most complex parts of an app to be implemented upfront early in the activate meant process so that you can check that these cloud transactions are successfully implemented by your development team, before getting into the longtail of completion.

But what happens in the app if we can’t connect to the cloud? What happens if someone connects to the cloud long enough to download the app, but then after that the cloud is not available because the network has dropped out or the customer has turned off their data?

One common problem with badly engineered apps is that they’re not robust against network dropouts, crashes, and use of behaviour such as backgrounding the app or closing the app.

Plan to test for network or other outages during your app acceptance, or automated tests. Image credit: undraw.co

When you think about a task that your customer is going to be completing in the app such as ordering, they will often switch to another app such as a text messaging app to consult with a friend about the purchase.

Poorly engineered apps may not handle being backgrounded in this way.

Now you have more rows and cells for your Great Big Chart. As well as cases for the different roles, you have “no-network” and “app backgrounded” rows as well.

Acceptance Testing and Releases

For this reason when doing acceptance testing on your app prior to release your product owner will work with the development team to test app packages that are release-candidates, ensuring that the app still works even if the network is turned off at times.

This testing is done on actual devices. End-to-end tests that include connecting to any cloud services should also be done at this time.  Note that some developers rely on test systems like browser stack which emulates phone devices, and does not actually use a real phone the way a customer would.

A cloud based error showing up in a native app due to mobile connectivity drop-outs. Screenshot taken by (c) Smithsoft 2020, Screen design (c) Uorda. Used by fair use.

Handle this by looking at your Great Big Chart and pick the items that would be Show-Stoppers for the release. These are the combinations of roles, items and use-cases for tasks which absolutely have to work. Write up these items as tests for your Quality Assurance team to try out when checking a release-candidate.

How do you handle this QA stuff?

“Wait, did you say QA? You haven’t even covered QA!” I hear you say.

It’s OK, how you handle this will depend on your team dynamics and the relationship you have to your developers.

Analytics and your Business

When we discussed the cloud and how apps work with it we discovered that there is kind of two clouds.

Firstly, there’s the cloud that is used to get your apps out to your customers. This is your Apple App Store, and Google Play Store; and also the repository of code along with your continuous integration systems that automate the process of getting new builds out so that your developers don’t have to do this manually.

Secondly we have the cloud that is used as the back-end of your app. There’s your own website or web-app, and various PaaS offerings and so on that can be integrated, payment providers and so on.

Well now we have a new cloud complication, that I had previously been ignoring so as make explanations easier.

And that extra complication is analytics.

What is it?

Analytics: the Necessary Complication to your Cloud or PaaS picture

Before I answer that I just want to say that analytics are pretty much the most important thing to include in your app. Get developers to include it the moment the app actually compiles on a device.

Typically its easy to do: just include the analytics vendors Software Development Kit (or SDK) in the build of your apps. Sometimes its as simple as adding a line in a dependency management system.

Once the SDK is in; developers have a new set of API’s that they can code to, allowing the documentation of customers doing tasks such as opening the apps cart, posting a new article or setting their profile picture. We know now how critical tasks are: analytics are what shows you your task completion, for the app out there in TV land. Its a view into the world of your customers.

Analytics are pretty much the most important thing to include in your app.

If you ever find yourself asking questions about what is happening with your app, the answer is usually “use analytics”.

In the past we used to refer to “Business Intelligence” for what we learn about our customers. And we know already about consoles for seeing what is happening with – for example – the uptake of new releases. Our database systems and the load on them is captured over time on consoles.

All of these come under the heading of analytics. And its yet more work for our already swamped Product Owner, and Project Manager/Team Lead. If some of the developer team are dedicated to reliability or operations, you might have some of them looking after analytics too.

Basically analytics are data that you get back from live systems. They are the most valuable data you have about your customers, about your apps and about how the whole system is working.

Back-end and Front-end Analytics? Hrrm, lets just say Analytics

Like the rest of the cloud picture you have back-end and front-end analytics. In my opinion there is no clean line between the two and its good to have some cross-over in who is looking at these to make sure actionable insights have more than one set of eyes on them.

The front end analytics can be Firebase Analytics (not to be confused with Google Analytics) which is free but part of the google megaplex; or MixPanel which is a paid-solution but independent & powerful, or one of the other myriad offerings in this complex space.

Flurry analytics, now owned by Yahoo. Free, still used, and the original mobile solution. (c) Smithsoft, screen (c) Flurry Inc.

These answer questions like what version of my app are users on? Who is entering my funnel for a particular task? Are there parts of the app that are dead – that is not being used? Are crashes or errors impacting my users?

There’s advertising and campaign related analytics too. These answer questions like which ads were most successful in getting my customers to install and actually open, then generate revenue in my app? These SDK’s will depend on which ads providers you’re using – often Facebook, Google or others.

The Software Development Kit proliferation

For these front end systems to work you need to include the vendors SDK into your mobile app, and then log events. This is essential to do.

The back end analytics will be your Google Play and App Store consoles, (which can include app crashes as well, as version information). This is not a replacement for proper mobile analytics however.

There’s your Continuous Integration system consoles that show what builds are progressing as they push to the stores automatically.

For the behaviour of your http traffic, that is your business web-site or web-app, there’s Splunk or New Relic, and many others that leverage log analysis to produce insights as to what’s going right or wrong.

Note that these SDK’s can expose your app to issues with the App Stores especially if out-of-date, so only use where necessary, update them aggressively, and purge them if not used.

An Alternative to Quality?

With great analytics across the board, developers can build quickly and with confidence knowing that any problems can be quickly detected and then fixed; sometimes even before many customers are affected.

Does this mean you don’t have to worry about all that pesky Quality Assurance. Well, almost. You can take that approach. Facebook has famously worked with “go fast and break things” type methodology.

Analytics can tell you what your customers are experiencing on the other side of the world, in other time zones before problems or bad reviews arise. But are they a replacement for quality? Image (c) Sarah Smith.

It all depends on your appetite for quality versus velocity of features. The needle on that barometer is a business decision that needs to be made at that level of your thinking.

In the early stages of a project, when fewer customers are involved, it can be a great idea to adopt a more aggressive feature velocity, use feature toggles to manage features that are not ready for mass adoption and watch the whole thing with analytics.

At least if your analytics picture is solid you have these options.

Sidebar: Developer Relations

As a business owner then, you should expect that your developer will give you access to the code that they have written for you. Your developer should give you a login to the repo where they’re placing the code that you are paying for. This is especially important if you’re playing things more arms length with your app development, rather than getting involved with daily work on the app.

I have worked with start-ups and customers in the past who have pressured and soured the relationship with their developers not realising that at any moment the cost of the developers walking away from the relationship was that they would lose everything. This happened because they did not have access to the code repository.

Communication is key to working with your whole development team. That communication includes access to code, UX designs and working software versions as apps are developed. Avoid souring your relationship as you need your team onside. Image credit: undraw.co

App owners who retain developers, often watch their apps grow with excitement, as release after release new features arrive. But if they don’t have access to the repo they may find they have nothing if that developer closes down business.

PaaS access is also Business Critical

But even access to the code is not enough, if there are back end services that you also need to make the app work. It’s common for example to store managed data in the cloud – the PaaS I mentioned above. These services are the ones that the app requires once it’s logged in to present dynamic data.

So to this end as an app development customer you need to work with your product owner or project manager to make sure that you have a shared list of login details for all the platform-as-a-service backends, the code repo and any other cloud facilities that are required to make the app work.

So lets assume you have the repository access, and the backend keys as well. You can log in to Firebase or whatever other PaaS is being used, and you’re all set up.

Quality Assurance and Getting New Apps Versions Out

The last thing is how to handle releases. As I mentioned above I don’t really cover QA in these articles.

The ideal situation is you have a low rate of problems with your app, you work tightly with your development team and they demonstrate features to you as product owner during the apps progress.

Ideally you have a soft-launch process where you curate early-access customers who get to experience the warts-and-all versions of the app. As the app stabilises feature-wise you get more bugs fixed as well.

But you can shoot for a high quality release as a different option. That’s a more old-school approach. Doing that involves more work than accepting a “release often” and “fix often” approach.

We discussed above the the idea of Continuous Integration. Developers show their work to the product owner on a daily basis, and present it as working software in the Sprint Review. In this model the developers write automated tests to make sure functionality keeps working.

But it is true that sometimes marketing departments and investors want a Big Bang release. Then you have to take a bit more rigour to your tests.

Pizza and Spreadsheets

When you work for a release that you want to expose to customers in a big way, you can consult your Great Big Chart, and come up with a suite of acceptance tests – again Excel or Google Sheets is fine for this.

The developers will supply a release candidate, say version RC1, which is on a seperate part of the code base called a branch. This part of the code base only gets fixes. No new features go into that branch.

Repository branches can provide a release candidate with separation from other code, in a high-process release model. Image credit: undraw.co

If your acceptance testing exposes problems then you go back to the team, who code a fix, put it in the branch and make a new version called RC2.

Finally you get a golden release candidate that goes out for your launch. You have a very high confidence in the quality. But it comes at a cost.

Either you have to shout everyone in your team lots of pizza and drinks as you sit around a table trying out all the cases in your Acceptance Tests spreadsheet. It can stretch for days if the process doesn’t go to plan.

You can outsource QA as well. This is quite common. But again its costly and also very variable results are had as the temptation to just throw it over the wall to an external QA house without an acceptance test suite is great.

Unless you have your tests worked out, the external QA house can find a bunch of pointless flaws that are not show stoppers, leaving the things you care about untested.

Continuous Integration

This is developer Nirvana. The golden standard for software is to have low errors, great automated tests that your continuous integration system runs for you, and just keep rolling out new releases every week or two.

Doing this is much preferred to having managed QA and high-process releases.

And it can be achieved but doing it requires a lot of discipline and some very talented engineering managers.

In Closing

In closing out this article let’s summarise what we have learnt.

  • Understand the role code plays in building your app.
    • It’s more complex than just developers pushing packages
    • Apps can be updated automatically from the repo
    • the repo is critical to the Continuous Integration of your app.
  • Secondly we covered how task-based-design can be used
    • to double check that even the most complex interactions
    • check roles to create a Great Big Chart of use-cases
  • As part of that design you should be sure about
    • which items are hardcoded into the app, and
    • which are dynamically fetched from cloud Apis.
  • Manage your relationship with your developer and team
    • Backend services that your app uses in production,
    • PaaS (platform as a service) like Google for login or
    • any other cloud database used for the app
    • You need admin access as part of the developer giving over control of the app to you as the app owner (but don’t abuse that access)
  • Quality assurance can be part of a big-bang release process but generally continuous releases and soft-launches are better if possible.
    • QA is costly unless you in-house it and
    • out-sourcing effectiveness depends on how good your acceptance testing documentation is.

Images (where noted) are the work of Katerina Limpitsouni. Check Katerina’s stuff on undraw.co.

Sarah Smith and app developers, outside the Apple App Store

How do you build an app? Pt 2. (Coding)

Queensland app developers, show how to code an app James Bowling, Sarah Smith, Cameron Owen and John Passfield. Picture: Annette Dew Courier Mail Oct 2014.

How do you build an app? Part 2 (Code)

What is involved in building an app? Who do you need to talk to you when you’re building it? Can I build my own app? Can I outsource building my app to developers overseas? Do I need to know how to code an app?

You’re reading the second part of my two-part post on “How to Build an App”. If you haven’t read part 1, start there to get the background for what I’ll cover in this post. I’ll be launching straight into discussion of how app building teams work, and that foundation will be critical to understanding this post.

This post 1 & 2 builds on my previous one “What kind of apps are there?”. If you haven’t read that now is a good time to check back there, just in case some of the concepts from there that I refer to in this post don’t make sense. 

With this two-parter, I’ve got halfway through my series for folks who looking for how to code or build an app. I talk about the series in a special introduction post, which is definitely good for perspective. Check that introduction for context to the whole series, and links to the other articles.

Don’t Bury the Lead

In part 1 I looked at the critical process & team setup for app building success. The last specialist I will look in that team is the engineering manager. Also this person could be the team lead, project manager or scrum master. Their job is to resolve problems that may stand in the way of the success of their developers, UX designer and product owner.

This person is an expert in developer team dynamics, and technical focus. The team lead will check on the progress of features, and review code submitted. The team lead or project manager also works to make sure packages get regularly uploaded. A package is typically uploaded on a regular cadence, each time a new set of features is ready.

Agile process is often used to track success of a project. Image credit: undraw.co

Where a team has been put together specifically for one project this role is typically held by a project manager. If the team already exists, especially an outsourced or overseas one, then we manage to project to project by an engineering manager.

Team Leads versus Project or Engineering Manager

For a small project, a team lead may write code as well as managing the team. For teams of more than three, the team leader no longer has time to write code becomes a project manager or engineering manager.

Larger efforts may require more than one team, in which case the engineering manager would coordinate those teams, each headed by a project manager or team lead.

The engineer manager or project manager is a technical partner to the product owner. Where the product owner manages the progress of the business side, the engineering manager watches over the technical progress of app development. 

Where the product owner manages the progress of the business side, the project manager watches over the technical progress of app development. 

A list of business functionality items called the project backlog is the simplest and best tool in the project managers toolbox. This tool has become best practice for communication of feature planning between team members. It’s especially important between the product owner and the project manager. Here’s how it works.

Backlog, Doing and Done

Each item on the backlog is a very small piece of work for the app. Each of these small pieces must be demonstrable. The product owner works to define each item in the project backlog.

The project manager ensures developers work on project backlog items. To achieve this PM’s will actively measure the progress of the project. The easiest metric for this is a simple count of items that are completed.

Project managers often run teams in an agile cycle, slicing off work for a one-week or two-week period called a “sprint”. At the end of the cycle they check on work done via a sprint review. At the sprint review leads ensure that discussion is offline. A good lead will note it for bring-up at a retrospective. The retrospective is simply a discussion. But team leads will often use fun retro formats to keep it productive.

Agile work cycle with planning workshop on the left, leading to Sprints at the top, then to sprint review at the right and retro at the bottom. Copyright Smithsoft 2020
Agile sprints run in a cycle. Image (c) Smithsoft 2020

Hiring and Firing

The team will change, with new developers added and existing developers who leave. Because of this engineers will need to handover their work, and its an important job for the project manager who makes sure that this hiring & handover happens smoothly.

Developers will set up and maintain automation tools to help speed releases. The team will also need code management tools and cloud productivity tools. The project manager or team lead is in charge of making sure these all work, and assigning engineers time to maintain them.

Let’s look at these 4 roles again:

  • Developer
  • UX designer
  • Product owner
  • Project manager

All of these four roles are indispensable to development of an app but only one of them is completely technical. Only one – the developer – involves writing the actual code for the app.

Understanding the Business is Key

In the introduction post for this series I said that the most important thing for success with your app is understanding your business.

The role of product owner is one that you can fulfil yourself, because this is precisely what the product owner does: understand your business. In fact the product owner is really a proxy or stand-in for the main stakeholder or business who is paying for the app to be developed.

If that’s true, why is a product owner professional even needed in the first place? Why do folks needing apps built not just always be their own product owner?

Product owners intimately understand what their customers need from the app. Image credit: blackillustrations.com

The reason is being a Product Owner is a lot of work. I mentioned above that app building is a cycle. Every single day the team and the product owner is in constant communication as the app evolves. Every week or two weeks the app development cycle results in new test releases which have to be compared against the product vision. All of this work involves the product owner ensuring that the app continues to approach optimal product market fit.

Many App Projects will need Professional Product Owners

For well resourced folks and larger corporations looking to get an app developed for their business I recommend approaching larger App development companies and firms employing professionals in all 4 of these roles. These app development companies, if reputable, will have an entire team that builds apps consistently, and who work well together.

If you’re a small business owner, entrepreneur or keen to get into app development you can get your hands dirty and take on the role of product owner yourself.

Keen to get into app development? You can get your hands dirty and take on the role of product owner yourself.

In order to succeed with this hands-on approach here are the steps you’ll need to take as Product Owner:

  1. Retain a UX designer to define the wireframes for your app
  2. Recruit a team of developers to to work on the app
  3. Define app functions in a project backlog
  4. Iterate with the team to produce weekly releases
  5. Test and verify the early releases 
  6. Feedback to the UX designer any changes you wish made
  7. Capture bugs and issues into the backlog
  8. Repeat these steps through app release 
  9. Continue these steps into the life cycle of your app

There have been a few startup entrepreneurs that have been hugely successful in taking on all this work. Mel Perkins of Canva is a great example.

If you go this route you’ll wind up being intimately knowledgeable about the technical implementation of the app which is a good thing, since the tech is a large part of the business. You’ll need to commit to learn fast however if tech is not currently a strong suit for you.

Rinse and Repeat

Wait, surely steps one and two don’t need to be repeated and continued through App release and the life cycle of the app? Once we have our designer and Team will just keep going until the app is finished?

There is that classic mistake. Did you spot it? The app being “finished” …? 

An old experienced developer once said “an app is only finished once it’s dead and buried”.

If you’ve invested into building an app, it’s a waste of that investment if you leave it to stagnate, and don’t keep maintaining it because it will rapidly fall out of date. Customers know when they are using an old, out of date, unmaintained app.

Black woman with a wheelchair poi's to a life-size mobile phone design. Product owners continue define improvements to product market fit. Image credit: blackillustrations.com
Product owners continue to define improvements to product market fit. Image credit: blackillustrations.com

And because of this ongoing life cycle almost always the team that is working on it will change during the lifetime of the app.

So to cycle back to the four roles that are involved with building an app, I’ve just covered the product owner role. I’ve talked about how much hard work this role is and how the product owner cares about the app as it progresses gets released and continues on being updated while it’s in production.

Self Build for App Development

What about the developers – is that something I can do myself if I want to build an app? Should I learn how to code an app?

In fact most of the Google searches I tried doing before I started this series of posts; when I searched for the term how to build an app came back with tutorials about developers writing code.

Black woman works on a laptop, by a whiteboard. Learning to code while building your own app is tough. Image credit: blackillustrations.com
Learning to code while building your own app that you need to work right is tough.
Image credit: blackillustrations.com

If you believe the folks who are creating those tutorials, anyone can start writing code and build their own app. It’s true that the tools are accessible and the skills are not exclusive.

But succeeding in building the app you want is very difficult, and it’s much more effective to work as the product owner if you are the person who cares deeply about getting the app to a success.

Developers are not Forever

Developers will often come and go, during the lifetime of an app. This is natural, and to be expected. Your team has to be set up to survive this.

In fact I have often done work for product owners where the original developers have walked away leaving the product owner to try and find new folks to keep the app up-to-date after Apple or android has changed the iPhone what updated to a new iOS or android version.

As long as you’re using source control, you’re good. Software engineers can come and go, and as long as their work is in source control it’s not a big problem.

What’s source control, I hear you ask? Or at least some of you?

In a nutshell it’s an online, collaborative tool used by developers to manage code. All professional developers I know use source control routinely. Its best practice.

I will link below to some good beginners tutorials if you want to try writing code for your own apps in programming languages like Swift or Objective-C for iOS; or in Java and Kotlin for android.

You too Can Code! But do you Have to, If you Just Want an App?

Coding is wonderfully creative and building your own project is an inspiring challenge to take on. Succeeding with shipping your own app it’s a great achievement to have under your belt.

But I will leave teaching actually writing code up to the many other tutorials that you can find on the web.

Many folks I took to use the term building an app in the same way we talk about building a house.

When I say I am building a house I don’t usually mean that I’m hammering in the nails and soaring the wood myself.

Building your own home usually means getting a team to help put it together.
Image credit: undraw.co

Aren’t most folks usually getting a professional builder for that? For the rest of these articles I’ll be assuming that you are getting a professional development team to build your app as well.

I’ll give you everything you need in these articles to understand how you can contribute as part of that team, by taking on the product owner role. 

How Much do you want to Get your Hands Dirty?

There are many folks who want to step back a bit. Folks who are time poor because they are working hard on their business.

Often the challenge of being a fully engaged product owner is too great and they would rather work with a professional product owner and a development team.

For these folks I’ll cover in this article series what you need to watch out for to make sure that your product owner is doing their job and how you can communicate with them to ensure your app continues to match the business needs that you have.

Summary

To close out this article then I’ll cover go over what we’ve covered.

First app development takes place in cycles. Developers write code it gets deployed a new app releases happen frequently so the product owners can check on progress.

Second apps I never finished. If they are successful. Instead after launch they continue to be maintained, updated and improved to take into account iOS and android upgrades.

Third, a team of professionals works on building an app. They are: the developer, the UX designer, the product owner, And the project manager

The four roles in an app building team: developer, the UX designer, the product owner, And the project manager. Image credit: undraw.co

The UX designer is crucial, and needs to be engaged right from the very beginning of the app development process. 

The project manager ensures that the team is kept on track technically, and manages automation and a collaboration tooling. They are is also responsible for retaining new developers and handing them off from the project When they leave.

The product owner tracks the feature completeness of the app to ensure it meets the business needs. The product owner understands the business & works with all the other team members to ensure product market fit.

And the developer writes code to actually implement features and UX design.

Of these four roles the product owner role is the one that you can most successfully assume if you want to build your own app. Actually writing code, being a developer on an app, makes it very difficult to also be a good product owner.

Tutorial references & credits

Want to learn to code?

The good news is there’s lot of free resources, and having the skills will make you a better app-preneur.

Images (where noted) are the work of Katerina Limpitsouni. Check Katerina’s stuff on undraw.co. Some images are by John Saunders of Black Illustrations.

Woman and creature look at a phone shaped graph going up and to the right Image credit: undraw.co

Can I make Money from my App?

Image credit: undraw.co

Can I make Money from my App?

How do I get people to download my app? How do I get folks using my app to buy what I’m selling? What is my app is a flop?

These are questions that any entrepreneur, business owner or developer should be asking themselves before they start building their new app. In this fourth article in my series How to Build an App I’ll be giving you answers to these questions.

Black businessman with briefcase and suit jacket, walks through group of upward trending arrows. Image credit: blackillustrations.com
Before even starting development on your app, think about how you make it a success. In whichever way “success” makes sense for your app.
Image credit: blackillustrations.com

To get the context for this, including what kinds of apps there are, how apps work and how you build an app, refer the previous articles in the series.

Let’s jump right in.

They will. Oh Really?

Often when I’m coaching start-ups I hear people say: then our users will download our app and they will…. 

I just stop them right there. Hold up my hand and stop the mid-speech.

Our users will download our app then they will…

Every beginner app entrepreneur ever

At that point I just want to grab that start-up founder by the lapels, stop them, and ask them.  “‘they will…”. You just said they will.

This is the number one mistake that new app owners make about the app when they’re designing it.

Before you even start building, while you’re still working with your UX designer, and your product owner to hash out the basic shape of your app you need to answer this question: why will my users do anything?

Your story about how your app succeeds needs to start with “Joe, who is a X, wants to do Y” where Y is something unrelated to your business “and so he Z” where Z is a story about how Joe even connects with your app in the first place.

Its easy if you are building an app for your bricks & mortar store because Joe is in your shop, and you give him a voucher for 20% off if he downloads & uses your app today. Otherwise, why would customers even find your app, let alone use it?

Start with your customers. Ask what do they want to do?

The mistake often happens because owners of apps have a lot of functionality that they want to put in.

Often they have a website packed full of “valuable” stuff that they want the customers to engage with. When they start building an app the first thing they want to do is cram all of that stuff into the app as well.

Successful apps are the ones that work for what customers want to do. Often that has nothing – at least initially – to do with what you’re trying to force feed them via your app.

A good way to understand how to avoid this mistake is to see how successful apps manage to fit with what customers are trying to do, and thus wind up making money for their owners.

So before we work out how to fix this mistake let’s just look at some of the ways that Apps make money.

Money is not the only measure of success by far, but its a good place to start.

Monetisation in Apps

Let’s think of two broad categories for apps that succeed in making coin for the folks that own them:

  • Firstly those that provide value inside the apps themselves, and
  • Secondly those that are commerce enablers for businesses.

Examples of the first kind abound, and were part of the initial app gold rush in 2007 onward. They could be what we think of when we think of some of the most popular “apps”, like Instagram or Twitter.

These of course are well known as mobile apps, but are now massive web presences as well. Both were mobile apps first however: Twitter because SMS or “texting” got us interested in communicating by short messages. And Instagram because we all have a camera in our pocket now.

Those kinds of apps like Twitter have public users who will get together on the platform to share photos or personal messages, and while they’re there they see advertisements that the platform (Instagram or Twitter) shows to them.

We are also familiar with mobile games like Candy Crush, or apps such as Duolingo that teaches you languages. Here the value that lures the folks to the platform is some in-app offering – like learning a language, or playing a game.

Free to Play Apps

So if you’re the app owner, and you’re not using your app to enable some commerce outside the app then you have to make money right on the customers phone itself. And when customers don’t want to pay a cent, you have to do that some other way than getting them to pay up-front. Enter the “free to play” apps.

Ads on Twitter are shown inline with posts made by platform users.
Screenshot of Twitter (c) 2016 used under fair use.

What’s common to Twitter, and DuoLingo is these apps make money from the actual app having some value that it delivers to its users inside the app itself.

Free apps that generate revenue from the app directly survive by acquiring a wide funnel of incoming users, retaining some and then monetising them.

The critical strategy for this kind of free app is to have a wide funnel of incoming users, who go through the classic cycle of acquisition, retention and monetisation. This area is huge and there’s plenty of great books & resources around it. Some of the best ones have been written by game monetisation experts but they apply just as well to non-game apps. The Free-to-Play Toolbox is an excellent place to start.

“Free” is a marketing strategy, not a business model. In fact, it’s not even a marketing strategy.. [for your app]. You need to figure out how to get users (free can help), how to hold onto them and ultimately, how to make money from them.

The Free-to-play Toolbox, Rob Fahey & Nicholas Lovell

It’s very common to have the customers pay for that value by ingesting advertisements. Other possibilities are subscriptions with a free month, which have become hugely popular, and in-app economies, like Trello Gold.

Premium Apps

In yet other cases customers can upgrade from the free to the premium version by completing an in-app purchase also known as an “IAP” or by buying the “premium” app outright in the App Store.

I have bought a few premium apps on mobile, and I have no doubt you may have a few favourites too. Its possible to do OK with selling apps up front.

In fact Apple would really prefer that we went back to this way of doing things. Its much better for their customers, and they’d save a ton of pain, dealing with people who complain constantly that their child spent a ton on in-app-purchases when they weren’t looking.

The reality is that app pricing is a race to the bottom, with everyone searching for “free” solutions for almost every niche of value based direct revenue app. That giant free-to-play funnel of popular apps keeps gobbling up all the customers and making it very hard to break even with a premium app these days.

The way to do it, is to make something absolutely gorgeous, and truly excellent, then win via App Store listings, and positive reviews. This is possible but takes a long time, and lots of user-testing, UX genius, and endless polishing.

Monetisation outside of Apps

Apps also can make money indirectly, by speeding up, enabling and making more ubiquitous the every day actions involved in business.

Apps like Uber, AirBnb and Airtasker enable us to pay for services like transport or the home handyman.

The local government, the tax office, post office and big corporations like Facebook and Google often have apps to help folks engage with various parts of the business.

  • Workplace by Facebook iPhone app App Store listing screenshot. App is (c) Facebook. App Store is (c) Apple.
  • Australia Post App for iPhone app screenshot. App is (c) Aust Post
  • Google My Business App for Android Google Play store screenshot. App is (c) Google.
  • Facebook Pages Manager app for iPhone App Store listing. App Store is (c) Apple. Facebook Pages Manager is (c) Facebook
  • Apple Music app for Android screenshot. App is (c) Apple

Smaller businesses often use web apps to manage restaurant menus, online stores and appointment bookings.

What all these apps have in common, where the folks interact directly or indirectly with the business, is that tasks are at the core of success for these apps.

What this means is that for you to make money from your app, see your app to be a success, is to ensure the folks who are using your app can complete tasks that they already had in mind when they were downloading the app.

Commerce Based Apps Succeed when Tasks are Completed

What do I mean by a task? Tasks don’t sound very exciting or lucrative do they?

We use the word tasks, because it works with task based analytics. Will cover analytics in full in the next video, but what we mean is measuring whether or not a user can complete one end-to-end transaction within your app and successfully achieve what they were trying to do.

Let’s imagine your business has a special promotion for summer or winter or some new seasonal holiday, and you send out promo codes to your customers to take advantage of the offer. A task would be for a customer to take that code,  shop on your app, and apply the code to their account.

A task would be for a customer to take an emailed code,  shop on your app, & apply the code to their account in-store.

The task starts when the customer sees the code in the email, the first action might be to manually open the app from their phone after seeing the email on the desktop; or it might be that they already were reading the email on their phone went to the website, and then from the website were prompted to open the app which they then did. 

Task Completions are Key

From there the user opens their profile, And paste the code into a form, and press submit. At this point a wait spinner may be displayed, and then finally a message saying that the code has been applied and then a $10 discount will appear on the next purchase.

Don’t leave customers watching a wait spinner. Give them the value, and do it fast or they’ll leave & try somewhere else. Image credit: undraw.co

I’m sure you can imagine tasks that customers would do all the time when engaging with your business.

The most important thing with tasks is that even if a customer can get almost all the way through the task, if they can’t complete it then you don’t make that sale. It might not be a literal sale, but it’s some interaction where the customer receives value, and engages with your business.

Getting Tasks Right Starts with UX Design

As the owner of the app, you need to work with your user experience designer to come up with a workflow that can demonstrate to the customer how to complete the task they want to do, and how to understand that they have successfully completed it. You should also take into account the possibility that something goes wrong, and in that case your design should include messages that will allow the customer to try to recover from the problem.

The product owner is constantly checking that key tasks can be worked through to completion in the app. Image credit: undraw.co

During the app development process, each iteration, the product owner should be working to check that these tasks can be completed inside of the app. If a feature that has been implemented by the development team is claimed to help a user complete a task, then that should be able to be verified by trying it out in the app.

The product owner checks if a coding task hasn’t been completed, and will push it back to the developers; if an end user cannot complete the task.

It doesn’t matter how many fancy animations, or other whizz-bang things are happening on screen; the coding is not finished if the customer cannot complete their end-to-end task.

Rule Number One for App Monetisation

So here is the first rule for making money from your app: identify the top 3 tasks that you want customers to engage with through your app; then absolutely nail the user experience for those tasks and insure that throughout development of the app those tasks are tested end to end to make sure they work and the value was delivered both to the customer, and to your business.

With apps that feature customers engaging in a monetary transaction inside your app a critical step is ensuring trust. Customers will be looking for all the hallmarks that let them know the money is safe, and the goods that they are paying for will be received by them. This is part of the task. If the customer feels unsafe, and doesn’t trust the app then something about the user experience is wrong.

Can I trust that my transaction went OK? Image credit: undraw.co

To ensure that tasks are working, conduct acceptance testing prior to your release where each step of the end to end task is tested out on a device like a phone or an iPad – not on a computer. Your developer must demonstrate to you that the entirety of the task can be completed by the customer. 

You should do this acceptance testing with an actual customer figure, someone who hasn’t been part of the development of the app. Ask them to complete the task described in plain English and see if they can do it in the app. For example, ask them to apply the code that you’ve received in the email to your user account in the app. If they run into problems then the app may need to be fixed.

In-App Purchases

In the case of in-app purchases (IAP’S) the Apple App Store has its own Apis for these which can make these transactions very secure. Likewise Google has its own commerce APIs. Both of these require custom native programming in the app to work.

Store API programming is tricky and customers credit cards are at stake.
Image credit: undraw.co

Apple in particular is a stickler for getting these right. If a customer buys something in your app, which they get to keep – for example upgrading to a premium version in the app, then you must provide for restoring that purchase if the app is reinstalled.

Retention Rules

The second rule for making money with your app is stickiness. You need to keep your customers in your app. You need to have the making longer sessions, and you need to provide reasons for them to come back to your app after they’ve closed it.

The number one reason why customers uninstall apps is because they don’t see any reason to keep using them. Often when customers upgrade their phones they will manually install apps so they can get rid of ones they haven’t been using. Android and iOS can even clean up apps that are not being used.

Your job as an app owner is to ensure folks who have downloaded your app have a reason to come back to it

So your job as an app owner is to ensure stickiness, by ensuring that those who have downloaded your app have a reason to come back to it. You need to think from their point of view.

Folks who have downloaded your app should feel like they are special, and that they have special insight, or privileged access to your business. If your business has Street premises, then there should be prominent signage asking folks who have the app installed to use it to get special discounts, jump queues or gain other benefits.

On your app website you should have carefully crafted open in app linkage so that customers can continue their transactions from the website into the app.

Application Deep Linking

Marketing promotions that utilise email should open automatically in the app if possible and include special promotional incentives to get app owners users to click through.

Although it is extremely easy to annoy and uses the careful and judicious use of notifications is also a great way to have users return to the app.

You need to make sure that the notifications have been asked for specifically by the user, for example “notify me when an out of stock item comes back into stock”.

When a user gets a notification it should be seamless for them to click through into the app and continue their task as cued by the message.

Boots on the Ground

The final point that I’ll make in this article about using your app to generate revenue for your business, is that you need to have a really good understanding of how your business operates and how your customers gain value from it. This applies even if you believe that the app itself will generate revenue for you, like say Twitter or Airbnb.

There’s a lot to unpack here so I’ll take a few steps to get to my point. To do that let’s understand the concept of boots on the ground. 

Amazon Treasure Truck, Seattle, WA 2016 (c) Sarah Smith
Amazon really understands boots on the ground.
Amazon Treasure Truck, Seattle, WA 2016 (c) Sarah Smith

Think about a regular business like a car wash. Here you might own a car wash and employ eight people to wash cars, while you yourself talk directly to customers, take credit card payments to handle all of the business like advertising and signage. As the business grows you can probably manage for a while just by yourself but for each time the number of cars doubles you need to have double the number of people washing cars. 

Businesses that Grow may need more Service Staff located where Customers Are

Once the business grows to a certain point you’ll need to have additional car wash real estate and probably extra hands on deck to speak directly to customers who are coming to the premises. These people that are working in the business I call boots on the ground.

Boots on the ground is when people have to be in the same location as the customer to assist them in getting the value from the business.

Something that’s often not understood is that in apps like Airbnb and Uber boots on the ground is a really big part of the operation of the business as well as the app. In fact it’s often much bigger. We only see the app but behind-the-scenes there’s a huge support operation of boots on the ground.

Uber has to employ people to on-board new drivers, handle online complaints, and deal with logistical issues. Those people have to at least be in the same time zone and very often in the same geographical location. For AirBnb it’s the same. There is very often a need for support folks who speak the same language as the users involved in any complaint or issue.

Okay so now we understand boots on the ground, how does that affect your business?

A Real-life Story of App Entrepreneurs

One group of entrepreneurs I worked with during my start-up years were extremely resourceful and talented young app developers. They came up with an app that involved trades people taking photographs inside their app and communicating with the customers of those trades people.

Tradespeople that wanted to work with my friends app had to be walked through setting up. Image credit: undraw.co

The assumption of the app was that this would help the trades people communicate to their customers that the work had been completed in a trustworthy & high-quality way via the photographs. The app was successfully built, but my entrepreneur friends found that the trades people did not want to start working with the app by themselves. 

My entrepreneur friends found that the tradespeople would download the app but then did not know what to do next. They had several trades people download the app, and they had to go and visit them personally and work through with them as they took the photographs and engaged with their trades customers.

My entrepreneur friends underestimated how much cost in boots on the ground was required to get the app working.

This is part of the “they will” problem. People who have not experienced an app before, that are new to an app, will often need help to get started.

They may need to be tutorials online, support staff, or people working with them in person to get started with the app.

Typically when we come to know about a successful app it’s already been in the store for a good 18 months or more, all the kinks have been worked out and it has a large user base. At this point many people already know how to use the app because their friends use it, and it’s gone through several iterations of user experience updates.

Eighteen Months

However the folks who are new to building apps look at these mature App Store successes and think that their own app will just spring into being on the first launch, and new users will use the app just like the thousands of other users of say Instagram or Twitter. Unfortunately this could not be further from the truth.

Your app. It’s everything right now. But imagine it wasn’t there & think of all the customers you are doing business with. Image credit: undraw.co

You may require many boots on the ground for some time before your app really starts to get traction and stickiness with your users.

A big part of the business effort around the app which has nothing to do with the app itself is of course marketing.

Take your app out of the picture for a moment, and just imagine doing business directly with all of the customers you imagine will download your app.

How will you reach them?

How will they respond on, for example Twitter?

How will you handle your apps social media, or negative app reviews if they don’t like the app?

Imagine there’s no app. You’re just trying to do business directly with all those people.

This is the scale of what you’re trying to do. This is a business problem that you need to solve before you can think about how your app will succeed. 

Successfully promoting your app is hard legwork, and it’s a big part of the boots on the ground process which means more human hours of work that don’t get assisted by any magical digital process just because you’re working with an app.

Mark your calendar for eighteen months. That’s how long you’ll need active users before your app is mature enough for recommendations to be a factor.
Image credit: undraw.co

Count on eighteen months before your app is mature enough before you start getting an effect where people are recommending it to their friends, and relying on it.

The apps you are looking at and using as inspiration in the App Store? They’re probably these ones that are at least 18 months old.

The Gold Rush is Over

Back when the App Store and Google play store first launched, putting an app up, would certainly result in people downloading it because there are relatively few to choose from. These days there are thousands and thousands of apps being submitted every single day.

Your new app will quickly be submerged under the torrent of other app submissions. Marketing your app to your customers is part of marketing any other sector of your business and has to be treated the same.

App Store listings are no longer a place to get discovered just for showing up. Image credit: undraw.co

A key success strategy for your app is to limit the boots on the ground factor, reduce your marketing spend and the amount of work hours you have to do by doing a very small launch 1st to a manageable number of customers.

This can be what we call a soft launch where the app is placed into the App Store, and you manually approach your customers and place the app in their hands, just like my entrepreneur friends had to with their trades persons.

Consider a Soft-launch for your App

The soft launch process will allow your customers to experience your app, and you can witness that happen firsthand, recording any fixes that you immediately realise you need to make. Also I cannot recommend highly enough throwing away all the features that you planned to integrate into the app and just select two or three of the most critical features that you require for the app.

Simple apps with well chosen feature sets are the most successful money making apps.

What Do we Know Now?

Alright. To close out and sum up this article let’s go over what we’ve learned.

  • Think: why would the customer do anything? Especially, why would they download your app?
  • There are a couple of different kinds of apps:
    • ones that direct make money inside the app
      • through in-app purchases, adverts, subscriptions or
      • up-front “premium” in the App Store or Google play store;
    • and commerce apps that help customers engage with a business.
  • Apps that directly make money include free apps; which rely on a funnel and a conversion process. Premium apps are still a thing, but hard to make bank.
  • Apps that engage with an existing organisation or business at least have a pre-existing customer relationship to leverage.
Apps are a business, so if you already have a business leverage that customer relationship into your app. Image credit: undraw.co

But apps of both of these kinds need to be sure of one thing for success: that customers can complete tasks.

  • To make money from your app
    • ensure that customers can complete the tasks in the app
      • complete means all the way to the end.
    • When customers complete a task that gives them value
    • they can then be ready to give you value.
  • To achieve this you must use the skills of your user experience designer
    • Have your product owner and UX designer working
    • to absolutely nail these task based designs.

At all costs avoid the mistake of just simply exposing functionality from your website.

  • Do acceptance testing on your app before release with folks who have never use the app before, to check that your customers will be able to achieve those tasks.

Understand boots on the ground.

Think about the regular business related aspects of doing commerce with all of those customers – especially imagine marketing to all those customers, and how you will get those customers to come and use your app.

  • Solve this marketing problem the way you would any marketing problems for your business.
  • Imagine that there was no app and you had to deal directly with the customers.
    • What transactions would have to happen?
  • Know how many people you will require to support your app when you release it.
    • Release via a soft launch to a very small hand curated group of customers that you can directly work with.

How do you Build an App? Sarah Smith coding an iOS app at The Coterie - (c) Smithsoft 2016

How do you build an app? Pt 1. (Design)

Image “How to build an app” Sarah Smith coding an iOS app (c) Smithsoft 2016.

How do you build an app? Pt 1. (Design)

What is involved in building an app? Who do you need to talk to you when you’re building it? Can I build my own app? Can I outsource building my app to developers overseas?

If you’re asking those questions you’re in the right place.

This post builds on my previous one “What kind of apps are there?”. If you haven’t read that now is a good time to check back there, just in case some of the concepts from there that I refer to in this post don’t make sense. 

This is the second post in my series on for folks new to app development.  Check that introduction for context to the whole series on “How to Build an App”, and links to the other articles.

Its a long post! So I’ve broken it into two parts.

That way after you’ve read this first part about the design side of the app building process; you can make some notes, and get a breath of fresh air. And then you’ll be ready for the rest of the story in part 2, which covers the technical side of the app building process.

Getting Started as an App-preneur

In this post I’ll be digging deep into that core question of how to get started building your own app. We will discover who are the specialist people that work on building apps.

And most importantly I’ll go over mistakes that folks new to building apps make and show you the path to avoiding those mistakes.

So by now you know that  developers have to write the code to build an app. Then they create a package, which they upload to the App Store or Google Play store. In the case of a Web app they deploy the app to a web server.

App Development Cycles

This is how the cycle of app development begins. Once some code has been written for an app and it has been installed onto a device, or deployed to the web developers try out the app to see if it works and matches what the app is supposed to look like.

The developers will find things that need to be fixed and changed. Each day they’ll meet with others in the team who also look at the work on the app so far and feed in changes. Then the developers make changes to the code and go around again. 

Apps are checked constantly. Image credit: undraw.co -- Three people examine an over-sized mobile phone at their feet, while checking papers they're holding.
Apps are checked constantly as development progresses.
Image credit: undraw.co

Each week or two a version of the app is released for the team and stakeholders to test & try out. Close to go-live early “beta test” versions of the app are tested thoroughly. After go-live there’s already typically a backlog of features that are wanted, and issues that are known about.

App building has a cadence. Regular releases that are tested and tried out are at the core of the app development cycle.

At go live date you have a backlog of features. This means the delivery of the app is always a compromise. Because there’s always at launch some features that are desired being left out. You have some issues you have not yet fixed, waiting for the next version to be released.

This is the number one mistake made by folks who don’t know how to build an app. When building an app you need to plan for the ongoing life cycle of the app.

I cannot stress this enough.

Tip: Plan for the Ongoing Process of App Development

As a coach I see a red flag that folks have failed to plan for the ongoing life cycle of an app. It’s when I hear ingenue app-entrepreneurs talk about launching when the app is finished.

Successful apps are never finished. Corollary: the only finished apps are failed apps.

So many app entrepreneurs that I’ve met, who have given post-mortem talks at conferences & who have written articles online, blame the terrible developers, the App Store or the vicissitudes of fortune for the fact that at their first launch their app was not ready.

Crunch development is awful for your team, does not produce good product and usually results from bad planning.  image credit: undraw.co -- A woman codes on a laptop late at night with a city-scape behind her.
Doing crunch development to meet badly planned launches.
Image credit: undraw.co

Newsflash! Are you planning a big launch day? You should prepare for a huge gap between your expectations and delivery. This is true even with an army of perfect developers. Its even true if there’s no problems with the App Store or Google Play store.

There’s a huge raft of reasons why this gap occurs, and keeps occurring, but the biggest one is because building an app is a learning experience. Both you as the app owner and the team building it are learning all about what this app will do to meet customer needs.

So how do you avoid this mistake?

Gaps Between Product and Market Fit

As the owner of an app when you first develop it you will cycle around with your app development team, changing it several times from your original plan, until you’re happy enough to go live.

But even after you go live on the App Store or Google Play store you will keep cycling and changing your app based on how your customers respond to the app. Analytics, download numbers, advertising campaigns and App Store feedback will all play into your plans for improvements to the app.

App Store listings are always 3 x work than you think. And it continues after launch. Image: undraw.co -- for people assemble components for an app.
App Store listing is a huge job. And it doesn’t stop at launch.
Image credit: undraw.co

Your launch date does not have to be tied to go live of your app. You can do a soft launch. Once your app is in the store these days no one will notice it or download it typically. So you can time your launch date for a later update when you release some additional functionality and make your big marketing splash at that time instead.

Give strong consideration to a soft-launch for your app. This is so technical completion of the app is not tied to a big product launch. That big splash launch can happen weeks or months after the app first goes live, typically with an additional big feature update.

Throughout all this you were cycling through day by day, week by week with your developers improving the app and steering it closer to product market fit. So the key to success with building an app is actually building a relationship with your app development team through the delivery date and beyond into the life cycle of the app after delivery.

Who is on the App Building Team?

Before we go on to understand the app building process let’s turn and look at the team of specialist people involved in the success of a modern mobile app.

Teams building apps need several developers. Image: undraw.co -- Two developers sit side by side with laptops.
Teams building apps often need several developers or software engineers. Image credit: undraw.co

We’ve already discussed the app developer or software engineer. This person writes the code that implements the functionality of the app. They create connections up from the app to the Internet to access cloud based services. They write code to access platform Apis to leverage the power of the iOS or android platform that the app is running on.

But the developer needs to know with great clarity exactly what the app they are building should look like and how it should function in the hands of the customer. This is the job of the UX designer.

Start with User Experience Design

Developers are talented at implementing functionality. But a separate specialist UX designer has to do the job of experience design.

Two UX designers sit back to back, on working with Adobe Experience Designer, and the other with Sketch. Image: undraw.co
User experience designers work with specialist tools. Image credit: undraw.co

The UX designer will listen to all of the product requirements, what the app needs to do, who will use it, what it should look like and how it will handle the content it needs to display.

With all this information the UX designer will prepare graphical mock ups of all of the app screens including detailed descriptions, button sizes and interaction details. 

How to build an app: engage a UX designer before you begin writing any code at all. You can be that UX designer.

By viewing these mockups on an actual phone or tablet you can quickly see whether or not the app will work the way you want it to. Iterating this way, with mock-ups is much less expensive than doing it with a coded app. It’s very difficult to succeed with your app if you rely on coded apps to begin feeling out the user experience.

Special mockup software even allows you to experience tapping buttons and swiping to change screens. It’s cheap to change a mockup. It’s expensive to change already written code.

Sorry, No Plain Vanilla

Another big mistake made by those new to app development is to believe that there are simple defaults that will work for their app design. There are an infinite number of possible apps and for each app an infinite number of possible ways to build it.

Developers will create something that can work. But this is leaving app design up to chance. The developers have to guess. They will take a basic verbal or written description, then add their imagination.

The other way to say this is that there are defaults, but you are not going to like them, in my experience.

Let’s say an inexperienced product owner authorised some hand-wavey “defaults”. I hear folks new to development say “Just do something that works”. Then the developers demonstrate what they’ve coded up. Then you find it doesn’t fit business needs and you have expensive rework.

Avoid the mistake of thinking there’s some simple defaults for the controls and user experience in your app.

To avoid this mistake make sure you use a talented UX designer to create application mockups or wireframes. If you are talented creatively and with graphics it’s possible to build wireframes yourself.  

User Experience designers will make sure critical app controls don’t get left to chance.
Image credit: undraw.co

There’s tools to create the graphics including buttons and other phone and tablet user interface elements, and other tools to share them online collaboratively with developers.

There’s tutorials available on the Internet and you can learn how to use these tools. However if you’re busy trying to launch an app it’s probably best to get a professional to do this work.

As a bonus once you have wireframes it’s much easier to talk to different developers about your ambitions for your app.

Use the Targeting Computer, Luke

Another heartbreaking mistake that folks new to app building make is trying to describe what they want by writing an email.

Apps are completely graphical in how they work with buttons, scrolling, and swiping. Because of this always use graphical tools to describe what you want the app to.

And then when your app changes, you want to communicate that too. App designs will change throughout its lifetime. You’ll want to use online collaboration tools built to handle wireframe  designs so you can handle those changes.

Figma is one of my favourites UX tools, but use one that handles collaboration well. Image credit: undraw.co

The same goes to having meetings. In my time in startups and the app business, I have watched as desperate business owners drag their entire development team into time wasting meeting after meeting where they wave their hands around trying to describe what they want; only to have the developers completely misunderstand their intent.

Development professionals, Jedi and ninjas, know the right kind of tools for this critical communication. Use the force Luke!

Customer and Product Input

I do my app development work by beginning with customer and business needs. Typically I then work with someone who is a specialist at framing and communicating those needs. A person I will work with during the ongoing process of development. I refer to that person is as the product owner or product manager. But they could be an app development client, or a figure from a client company. 

The product owner, UX designer and developer work together on a daily basis. The cycle of design code and test happens daily and weekly with the product owner checking that the results of the development process actually fit the customer’s needs. 

Product owners constantly check that app builds meet customer needs.
Image credit: undraw.co

The product owner shoulders the burden of representing all of the people who will be using the app. Sometimes there is difficulty between the app developer and the UX designer as to how a button should work or look. When that happens the product owner can resolve that difficulty. They will do that by looking at the business case for that part of the app.

Continued in Part 2

From here we continue the story with a discussion of the technical team members and what they do to build apps.

There’s also a handy summary section at the end of part 2, that wraps up all the learnings from these two part-posts.

Grab a break, stretch your legs; get a cup of tea or a coffee; and I’ll see you over in part 2 of How to Build an App!

Images (where noted) are the work of Katerina Limpitsouni. Check Katerina’s stuff on undraw.co.

Woman seated on the ground looks on at phone, iPad and laptop screens - What kinds of apps are there?

What kinds of apps are there?

Image credit: undraw.co

What kinds of apps are there?

When I’m using an app on my phone I don’t care what kind of app it is as long as I can do what I need. But if I want to have a mobile app built, suddenly there seems to be so many different choices to make.

Native or web-app? Cross-platform or coded-per-platform? Gamification? Notifications?

How do I know what kind of app I want?

People wait at pedestrian crossing near a rail bridge in Shinjuku, Japan; one uses her cellphone. (c) 2018 Sarah Smith
Japanese app publishers have a bigger focus on native games than other countries. People at a pedestrian crossing in Shinjuku, Japan. One woman looks at her cellphone. Image (c) 2018 Sarah Smith

This post builds on my previous one “How apps work”. If you haven’t read that yet I suggest you go back and take a look, especially if any of the concepts in this post don’t make sense. 

This is the second post in my series on “How to build an app”.  Check there for context to the whole series, and links to the other articles.

In this post I’ll be looking at what goes into the three main different kinds of apps you can build for phones and tablets. 

Let’s dive right in.

Main Types of Apps on Mobile

There’s three main types of apps to choose from on mobile.

  • The first kind of app is the native app
    • These are harder to build, but
    • provide full access to the power of the phone or tablet
  • The second kind of app is the web app
    • You know this as a website or online app.
    • These can be optimised for mobile
  • The third kind of app is a hybrid app
    • These apps aim to be the best of both worlds: 
    • a native app that uses web functionality.

In the previous post on how apps work we learned that apps are a part of the fabric of the Internet. 

The truth is that even the most simple native app has some Internet functionality built-in.

For example if I make a calculator app then upload it to the App Store and it crashes when customers use it, I as the developer can, over the Internet, get that information transmitted to me via built-in analytics inside the app.

My app can handle notifications that it receives over the Internet.

Notifications are a key differentiator for choosing the kind of app you want. Image credit: undraw.co

When I want someone to download my new calculator app I advertise it and when someone clicks that Internet based ad, my app can know how it got installed and activate a special promotion.

These are all ways that even a very simple app interacts with the Internet. Put a sticky note on this idea, and we’ll come back to it.

Web Apps versus Native Apps

We learned in the previous article that developers have to write code and create a binary package that is uploaded to the App Store before someone can download that app. 

Working with the App Store and Google play store can be a big problem during app development. 

Web apps are basically websites. Developers don’t have to get approval from Apple or Google for their website.  A Web app has interactive functionality such as login and dynamic page generation. Thanks to JavaScript in a web app users can interact with maps, cards & other interactive content. They can do a lot of things real native apps can do.

Web apps use HTML and other web technologies but tailored for mobile. Image credit: undraw.co

But to create a Web app a developer doesn’t need to write native code to build a package and upload it to an App Store.

Webapps are written in a combination of human readable text, markup language and scripting.  Once written the web app is “deployed” which means it is copied from the developers computer up to the cloud.

This can be almost instantaneous. Deploying a website can be seconds or minutes at most. When a developer deploys a Web app the very next time anyone visits the website that visitor will see that updated functionality. 

Although web apps are just websites, meaning they are deployed on a Web server on the Internet instead of installed on someone’s phone there a lot of things you can do to improve the experience and, with effort a good developer can make them work more like a native app. 

Responsive and Progressive Web Apps

Responsive web apps are the biggest improvement developers can make to web app experiences on mobile. So much so, that they deserve their own heading in this article.

The word responsive here means apps that can change to fit the exact size and shape of an iPhone or iPad. Responsive web apps work when the phone is in portrait mode, that is normal phone use with a narrow screen. Or in landscape mode, that is rotated on its side; with a wider screen. 

Responsive apps work when the phone is rotated. Image credit: undraw.co

Responsive web apps also can hide clutter that typically appears in a highly detailed desktop webpage. Hiding clutter like this makes the webpage appear more quickly and work much better for people who use the app. Responsive web apps are more user-friendly.

Google has promoted the use of progressive web apps or PWA’s. On supported devices like newer android phones PWA’s can access some of the native features of the phone or tablet. 

Progressive web apps work by having a special file called the manifest on the web server. When a phone or tablet accesses the web server to view a page the manifest details how the website can be bookmarked on the phone or tablet’s home screen. 

The Web View

Tap the bookmark on the home screen and the PWA is launched in a full screen web view by the phone’s native browser, be it mobile Safari on iOS or mobile Chrome on Android. 

What is a web view?

A web view is a web browser for example Chrome, Safari or Internet Explorer; except all of the buttons, location bar and everything have been stripped away so that only the web page part remains.

When you are reading an email and you find that it looks exactly like a web page that’s because it’s rendering in a web view. 

Web views can be full screen on mobile, and PWA’s can work even offline.
Image credit: undraw.co

Because some webpages can be stored locally the PWA can even work in a limited way when the phone is not connected to the Internet.

You can try this out with Trivago.com or Starbucks.com – use the save to home screen function of your web browser and then open trivago from that bookmark on your home screen. You should see a full screen experience.

The Store Bought Experience

The important difference that allows you to tell between a Web app or a PWA and a real native app is that only the native app is installed via the App Store or Google play store.

Only the native app can directly access native features such as Bluetooth and microphone. Also the full power of the phone or tablet can only be accessed by native apps. 

Also there’s the install experience. So for PWA’s and web apps “installation” involves bookmarking an app to the home screen and does not engage user trust in the same way as installing an app from the App Store. It’s also quite confusing, especially on iOS.

If you are considering building a web app ensure that you try out Trivago and other web-apps on Apple iOS and older android phones to understand what kind of experience your users will receive.

Progressive Web Apps – or PWA’s – are still web-apps. If your customers are on Android or are B2B, you could consider a PWA for your app.

If you know your customers are primarily on Android, or you have a captive group such as in a B2B solution where you can specify the platform, you could consider a PWA. But remember that a PWA is still, despite all the service workers and talk of notifications, is still really a web-app.

The third kind of app is the hybrid app: it’s a combination of web and native app. How does it work?

Hybrid Apps: Web and Native in One

Like a native app the hybrid app is installed from the Apple App Store or Google play store. Also like a native app the hybrid app can receive notifications, use the camera, microphone, Bluetooth and generally access the full power of the phone or tablet. 

Hybrid apps also include web views to show Internet content. Remember when views from our discussion of PWA’s? This works the same as when you view an email as webpage.

Woman places a component into a mobile app. Image credit undraw.co
Hybrid apps have web views embedded into an app.
Image credit: undraw.co

Let’s go back to the example of Zombo from the previous post.

Zombo wants an app with two tabs: a home tab and a profile tab. They want to have the app in the Apple App Store and Google play store.

Hybrid Apps are got from the App Store

When Alice downloads the Zombo app from the App Store onto her iPhone she can go into the profile tab and use the camera to read a barcode from Zombo’s latest catalog and access special offers code. She can receive mobile notifications if Zombo launches new special deals. Alice can log into the app and store her username and password in the secure keychain for her phone.

When Alice opens the home tab on the Zombo app inside that tab is a web view that downloads the latest content from Zombo’s web server. Inside that web view on the home tab Alice can receive special offers tailored to her account which she logged into on the profile tab. This is just like using the Zombo web app in a web browser. However if the Internet is not available Alice can still view cached content in the Zombo app.

Best of Both Worlds?

These types of hybrid apps can provide the best of both worlds. They include many of the benefits of a web app and a native app in one. Hybrid apps can be a good way of including web functionality from your existing web properties into both an android and iOS app.

Existing web properties can be re-used in a hybrid app. Image: undraw.co

The drawback with hybrid apps is that they’re expensive to build, and can be buggy and complex to maintain. The experience when navigating to other pages in the web app can be complex for example if a user clicks on the link inside of a web view it may open an external web browser and confuse customers.

But they are undeniably the most powerful and flexible of all the app-types on offer.

Cross-Platform Apps

There is one other important kind of app: the cross platform app. These apps are built using special technologies and frameworks that allow developers to create an experience that is close to native but which will work across different platforms such as iOS and android. We will look more at cross-platform apps in a later article.

Summing it all Up

All right to close it out this article lets summarise what we’ve learned.

  • There’s three main kinds of apps: native, web app and hybrid.
  • Native apps are powerful but hard to build 
    • require code to be written even for small updates, and 
    • packages need to be uploaded to the App Store 
      • whenever you want to change them. 
      • The packages are not human readable
      • We call these binary packages.
  • Native apps are the only way to reliably access the full power of the phone or tablet.
    • Features like notifications, Bluetooth, camera, and microphone are only available generally to native apps.
  • Web apps or online apps are websites designed for iOS or Android.
    • Because they are online changes appear straight away.
    • The code for web apps is easier and more human readable
  • Responsive web apps are the biggest improvement to apps on mobile
    • They change the size and shape to fit mobile screens
    • They can be less cluttered and easier to use
  • Progressive web apps or PWA’s can be bookmarked to your home screen
    • When launched they appear in a full screen window
    • On some platforms PWA‘s can use technologies to provide some of the features of native apps
  • Responsive web apps and PWA‘s are still websites
  • native apps are installed from the Apple App Store or Google play store
  • Hybrid apps are native apps that have some web views
    • They are more complex than both native and web apps
    • They can have the best of both worlds

Images (where noted) are the work of Katerina Limpitsouni. Check Katerina’s stuff on undraw.co.

Man gazing up at phone with technical display. How do apps work - image credit undraw.co

How do Apps Work?

Image credit: undraw.co

How do Mobile Apps Work?

Many of us use apps every day. But we don’t often stop to think: how do mobile apps even work?

In this article I’ll be digging into how apps work to connect people with things they value, and how that works for your business. I’ll talk about app development, the cloud, the app stores, and some other technical stuff – but we are going to be keeping it light on the jargon.

It’s the first post in my series “How do I build an app?”. Check the series introduction for context and links to the other articles.

Let’s dive in.

Apps are part of the fabric of the Internet

Apps seem simple when you look at them!  But we know companies like Facebook and Google; Twitter and Snapchat have hundreds, even thousands of people working on apps. 

How do apps work? A lot of the code runs in the cloud. A thousand engineers on their laptops in one room at Brisbane Convention Center for the Google Cloud on Board event 5 March 2019 (c) Smithsoft
How do apps work? A lot of the code runs in the cloud. Around a thousand engineers on their laptops in one room at Brisbane Convention Center for the Google Cloud on Board event 5 March 2019 (c) Smithsoft

When I tap an icon on my phone the Twitter app opens up. But all those engineers working on code for apps: what happens to all that code?

What about even a simple app like the notes app that comes with my phone? Surely most of that simple app is just what you see on the surface?

Apps use the Cloud to provide functionality

The answer of course is that even a simple app is more than just the icon and the application itself on your phone. Much of the functionality of apps is actually in the cloud. Even the humble notes app is saving data into the cloud. For some apps, and Facebook is a great example, the mobile app is just a small windows onto a huge web-based system. No wonder they need all those engineers!

Cloud download - image credit: undraw.co
Cloud download: much of apps is actually cloud functionality – image credit: undraw.co

So what is the cloud? Just in case you need a refresher let’s take a minute to go over ”the cloud” as it relates to apps.

Sidebar: Cloud Refresher

Think about a television station. It broadcasts, day and night, waiting for someone to tune in with their TV set. We don’t know where the television station is. When we tune in we just see the shows that the television station is broadcasting.

The television station is like a server computer. Lots of server computers together form the cloud. You’ve heard of network television?  Well the cloud is a network too. 

A server is just a computer that is connected to the Internet 24/7 and the cloud is just interconnected servers

A server is just a computer that is connected to the Internet 24/7. And it serves up stuff.

The cloud is just the word for a large number of remote, interconnected servers all working together.

The World Wide Web means we can all see the same page. Those pages are served up by server computers running 24/7. Image credit: undraw.co
The World Wide Web means we can all see the same page. Those pages are served up by server computers running 24/7. Image credit: undraw.co

A great example of the cloud is the World Wide Web. There’s thousands of millions of pages of information on millions of server computers just waiting for us to view them. The way they work together is by linking via clickable links.

All those server computers can receive information as well as broadcasting it. Right, so that’s the “cloud”.

So apps are sending data to the cloud & pulling data from the cloud. But also the cloud is pushing apps to us via our phones. 

The best way to think of this two-way street is that apps these days are part of the fabric of the Internet. This is a very important thing to understand about modern day apps. Many new app developers and entrepreneurs fail to understand this.  They think about their app just as local to their phone and separate from the internet.

App Programming Interfaces

Think about an example of the lifecycle of an app – we’ll use a fictitious new online shopping app called Zombo:

  • Alice sees an app banner promotion on Zombo’s website and clicks on it
  • Alice downloads the Zombo app from the App Store to her phone; and
  • once installed the app communicates over the Internet so Alice can
    • log in to the Zombo store
    • fetch special offers, 
    • save her favourites or 
    • share with friends
Online shopping - woman looks at an app page showing clothes. Image credit: undraw.co

We already know how to use the web on our phone to connect to a website to look at for example special offers. There can be hundreds and thousands of different links and features and menus on a website that we can easily access using our phone or tablet by browsing and clicking or tapping on what we want.

But how does an app do that?  How do mobile apps actually work when it comes to the cloud? An app doesn’t work by clicking on a website.

Apps Connect to the Cloud via an API

The answer is something called an API, or Application Programming Interface. That’s a lot: just remember that the I stands for interface. 

The Zombo website server in the cloud serves up a page that is written in English so you and I can read it to access the menus and special offers there. But how can an app on a phone read a website? The answer is – via an API which is at its core a set of rules about how to store and retrieve data from that website.

The API provides an Interface so that each link and feature and menu and special offer on the Zombo server is specifically detailed in code written to the API so that the app can know how to access it. The Zombo iPhone or Android app is specifically coded to that API. 

And notice this one thing: these APIs have to be specified in advance because once the app is built and uploaded on to Alice’s phone it can’t adapt to changes.

Change the API & You Break the App

Imagine the server today has a link on the website for shirts. But then the developer changes it so that it says tops instead of shirts. You and I will be able to browse and click on tops just the same.  We know that that’s what we want. But an app that is already installed doesn’t know the tops and shirts are the same thing.

Broken connection between server and app? It could be due to API changes. Image credit: undraw.co
Broken connection? It could be due to API changes. Image credit: undraw.co

This is why APIs are important. API just means a set of rules that governs how the information is stored on the server; so that the developers who write the app can know how to connect to it and send the correct commands to it.

To answer the question of how do mobile apps work you need to think about how they interact via API’s to leverage cloud features, and how they need to keep pace with those same API’s. And how they can stop working when they fail to keep up.

Platform API Differences

The Apple App Store is different for every country so there’s actually hundreds of App Stores. Google play has one store but there’s lots of other android stores. All of these places where you can download apps are of course on the cloud.

When Zombo engineers write code and create an app they upload it to the cloud. They upload it to server computers which form the Apple App Store or Google Play Store ready for app users to download. 

App Store Package Downloads

Remember Alice with the Zombo app on her phone? After she downloads the app she can log in to see special offers for her from the Zombo website.

Think about that for a minute. The first download was an app. The Zombo app. The second download was special offers from the Zombo Website. 

That second download was human readable text information about clothes I can buy from Zombo but the first download was something else. It was an app package. 

Apps are not human readable. Apps are functionality wrapped up in a package that your phone can understand and install. To make mobile apps work a phone unwraps that package and maps the content out onto the storage of the phone, where it can then run as an app.

App Package Formats

We call that non-human-readable package a  “native app”, or a “binary”. It’s the job of Software Engineers or Developers to build this native app package & upload it to the App Store or Play Store. 

Packages for the iPhone are in an IPA file. Whereas packages for android are in an APK file. These details aren’t important but just bear in mind that the app package is a file that gets uploaded to a server. At the core of it the App Store and Google play stores are just servers.

We’ll talk more in the next post about how developers and engineers create apps and add packages. But there’s one more very important thing to cover and that is the differences between app platforms. 

Sidebar: Platform Wars

To make things simpler I’ll assume that there are just two platforms: Google’s Android, and Apple’s iPhone and iPad. Also I will refer to Android as being the “Google Android platform” even though Samsung HTC, LG and other companies make android phones. 

This is because from the developer point of view Google is responsible for all the APIs that are needed when working with android. In the Apple ecosystem the iPhone and iPad along with other devices like the Apple iPod and Apple TV I will collectively refer to as iOS. Apple controls those API’s.

These days there is iPadOS and tvOS; and of course WatchOS – but just for brevity I’ll go with “iOS” for the family of devices.

Apple's iPhone, iPad and Apple TV platforms are referred to as iOS. Image (c) Smithsoft 2020
Apple’s iPhone, iPad and Apple TV platforms are referred to as iOS. Image (c) Smithsoft 2020

Before I go on – one quick comment. It’s not really viable to say which platform is better.

If you are a business owner looking to build an app, the most important platform is what will serve your customers the best.

People will choose the platform that suits them. Android is more popular in the developing world, and has a very diverse set of configurations due to its many vendors. Apple is more popular in the USA but sales are growing in China recently. 

If you are a business owner looking to build an app, the most important thing is to look at what will serve your customers the best.

Android and Apple API Differences

We’ve already talked about how APIs are the rules that allow developers to know what is available on a website so an app can connect to it. Well there are also APIs so the developers can connect to the features on the phone or tablet itself. 

Think about it this way: The app can connect up to the Internet to access features on websites, and it can also connect down to the phone or tablet to access features on that device itself. This is how an app can play music, access payment systems, use the camera, microphone, bluetooth system or use many other features of the phone. It’s the different platform API’s that make mobile apps work with the hardware and software features of a phone or tablet.

Code is completely different for the Apple iPhone and Google Android phone platforms

One mistake that folks new to app development often make is not realizing how completely different the code is for the Apple iPhone and Google Android phone platforms. Not only are the two platforms written in different computer languages – Apple’s Swift versus Android’s Kotlin & Java – but the platform API rules are different as well.

Android uses Java and Kotlin for coding up apps. Android phone on organic background. Image credit: undraw.co
Android uses Java and Kotlin for coding up apps. Image credit: undraw.co

This means the rules for accessing down to the hardware, and functionality on the platform itself are different from iPhone to Android. And not just cosmetic differences – very fundamentally different in some cases. Notifications is a prime example.

Cross-Platform to the Rescue?

There are cross platform tools that can be used but generally these create problems of their own. Those tools – like Flutter, React Native or Xamarin for apps, and Unity for games – try to wallpaper over the platform differences by making their own API. But cross-platform tools introduce more dependencies, and require new tools for testing the apps. These tools in turn can make releases painful.

To make mobile apps work with their full functionality cross-platform apps have to mirror that new features that the platforms introduce. Sometimes this means that hardware acceleration and platform security features don’t work as well as when developers use the API’s provided by the vendor (Apple or Google).

Native Apps

So back to Alice: she can use the Zombo app to connect to the Zombo website and see special offers. Or on her phone she can use the phone’s web browser to connect to the Zombo website and see special offers as a web page rather than in the app. Either way, app or website, Alice is downloading human readable text.

Now we know that mobile apps work by using API’s and an app accesses its own platform and also cloud functionality via those API’s. And we know that app is a package.

Here’s the thing about native apps: they themselves are not human readable. After developers have built it, an app itself is a binary blob inside of a package, that it gets uploaded by developers to Apple’s App Store or Google’s Play store.

You may have heard that code is compiled into an app as instructions to the computer chip in a phone or tablet. That’s true but native mobile apps work by having efficient, super-fast binary instructions that are gibberish to the human eye.

Apps are binary blobs that are uploaded to the App Store or Google Play Store. Image credit: undraw.co
Mobile Apps are binary blobs, unlike web-apps which are more human-readable. Image credit: undraw.co

This makes native apps very different from web-apps – even though both wind up accessing the web – which is human readable, mostly – and are both part of the fabric of the internet.

In the next post I’ll talk more about the difference between web-apps and native apps. And I’ll cover then the in-between case – the hybrid app. But for now let’s just look at how an app works compared to a webpage.

Apps work Offline

If I turn on Aeroplane Mode and shut off my Wi-Fi I can still open the Zombo app and see it’s navigation bar at the bottom; and navigate through content that it still has stored locally.

But if I try to refresh, no new special offers come down because Internet connectivity is not available. But at least the app still works. 

If I tried in my web browser to go to Zombo’s website, because Aeroplane Mode and Wi-Fi is turned off I just get “you are not connected to the Internet”. So web-apps will usually give a big blank page of nothing if there is no internet. Or you might get a cached page. Or an error message.

Speed Advantages

Second big difference is that the native app launches really fast. Faster still if I was already using it and it was just backgrounded. Whereas sometimes the Internet can be slow and loading a webpage like Zombo’s homepage can take awhile.

Apps have a lot of tricks up their sleeve. They can use the phone’s barcode scanner via the camera; they can store login details locally in a secure keychain. And they can save recent copies of online information like the offers in Zombo’s app so that some functionality is still available even when off-line.

When you’re wondering how do mobile apps work so fast for things like image recognition, its because special image hardware on the phone can be accessed by native API’s to do the bulk of the work in hardware accelerated mode.

Some things like photo and movie editing, graphics, games, music, photography, Bluetooth and high-performance applications are only possible when you have access to the full power of the phone or tablet.

App Drawbacks

If apps are so good why isn’t everything in the app?

One reason is that updating apps is hard: engineers need to write code to make changes to the app. Even just changing Zombo’s navigation bar to a different shade of red would involve a change to the code; re-compiling the code into a package, and then uploading it to the stores. And then waiting. Customers might not download the update.

Woman and man wrestle with cloud upload. - Uploading new updates of an app is a lot of work for developers, compared to web apps. Image credit: undraw.co
Uploading new updates of an app is a lot of work for developers, compared to web apps. Image credit: undraw.co

With a website Zombo’s artistic web designers can get a brief about a new shade of red this afternoon and roll out the change to the website in minutes so that the next time customers click on the website tonight they see the new result.

Changing Cloud API Issues

Another super important problem with apps is that because they’re so hard to update, the website that they connect to can move on and change while the app remains the same. 

When that happens the app might not be able to download content the way it used to and it could display an error to the end user instead of displaying for example special offers or logging the user in.

Remember API’s? 

Those were the rules that were used to govern how pages and information was stored on the web server so that the apps could download it. 

API’s are rules for how apps and pages access information. Image credit: undraw.co

If the API has changed but the app hasn’t been updated by the developer then we can get errors. The developer might update the app but the end-user may not yet have installed the update. The app may crash.

Releasing App Updates

To get out changes that developers make to an app & put that update in the hands of customers on their phones means a new release. Version 1.2.3 becomes version 1.2.4 and requires a new upload to the app store cloud.

If you want the server to change its API a new app release has to be planned and executed, which can be costly to do. In some cases it will require a review by Apple or Google.

Alright to wrap up let’s go over how apps work. 

  • Apps these days are part of the fabric of the Internet.
  • They are more than just the icon or the install on the phone
    • Mobile apps typically contact the Internet  to provide additional functionality
  • Software engineers and developers have to write code to create apps
    • Once an app is created it is uploaded to the App Store or play store
    • The code is very different between Android and iOS
  • Apps can have problems related to Apis
    • The API’s are very different from Android to iOS
  • Native Apps can work off-line without the Internet
    • When off-line most apps are limited these days
  • Apps can have advanced functionality like cameras and microphones
  • They launch quickly and can save settings like custom logins
    • But apps are difficult to update

Images (where noted) are the work of Katerina Limpitsouni. Check Katerina’s stuff on undraw.co.

Woman works to slide a component in a mobile app. How to build an App - Image credit: undraw.co

How to Build an App: Series Introduction

Image credit: undraw.co

How to Build an App: Series Introduction

Have you ever wondered what goes into building an app? What different kinds of apps are there? How can I get an app built?

Follow this series of blog posts to find out the answers to these questions and all your other questions about building mobile apps.

Head shot of Sarah Smith. 20 year veteran app builder. (c) Smithsoft 2020
Sarah Smith, 20 year veteran app builder

I’m Sarah Smith and I have been working with apps for over 20 years. I worked for Google and Nokia and then began building apps for start-ups. I’ve been a start-up Chief Technical Officer and I’ve coached start-ups. I’ve built my own apps. It’s tough!

The good news is you can succeed with your app without a lot of technical knowledge. 

The most important thing is a good understanding of your business.

The most important thing in app development is not understanding tech: it’s understanding your business. This is true even if you plan for your business to flow from your app after it’s built. So if you understand your business that’s already a great start.

From there you need to know how apps work to connect your customers to your business. 

Apps seem simple. You probably have some favourite apps.

But search for “How to Build an App” and you get coding videos. Not helpful for folks who want to understand how apps are even built in the first place!

What does it mean to have an app built? How do they get into the App Store or Google play store? And what if you want to change it after it’s done?

That’s what we’ll cover, and more, in this series of articles.

Why did I create this series of articles? Because I want to help you avoid all the traps and mistakes that I have seen so many folks fall into when they go off to build an app. It does not help you – or folks like me in the app development business – when app-based businesses go south.

Why Would I Give Away Expert Secrets For Free?

You could go and pay for a online course in project managing apps or starting an online app business. But what I’m about to cover in these 6 posts will set you up with what you need to know to build a successful app – and I’m doing this for free, even though some of what I do is paid-for business & startup coaching.

Here’s why.

I started working on apps for my own business in 2012. All around me in the co-working space where my business was based were other business owners: people who did online training for thousands of students, a husband and wife team who took orders for their custom printed t-shirts. There were some folks who had a business for new parents, a pet sitting business; even Uber rolled out its Australian operation from right in this co-working space.

I worked alongside several hundred different businesses over those years. It was an amazing experience.

The most awkward conversations I had when coaching was with would-be app-entrepreneurs who did not have any business strategy for their app. I had to send them off to the Lean Business Canvas to plan their business strategy, before I could help them.

You have to have at least a basic business plan before you even begin your app journey (which is why I like Lean Business Canvas, not just because its free). There’s plenty of free resources to help you get started with Lean Canvas too, like this one from David Bland.

Use Lean Business Canvas to map your business strategy, then build your app.

During that time I helped out advising folks who were struggling to engage with the digital space, and spoke with a lot of business owners. 

I heard from some folks their stories of heartbreak after spending savings on tech, only for it to go horribly wrong. I had to do something.

What if I was able to give folks new to digital business a bit of free advice? That could end up saving them thousands of dollars due to costly but easily avoided mistakes.

So that’s what I did. And I’m continuing to do that in these articles. I’m going to record these as video tutorials as well.

In this series I’ll cover the mistakes that new app entrepreneurs make – and how you can avoid them. I’ll show you how to succeed in getting your first app built. And I’ll unpack the best business strategies for making your app a success.

Images (where noted) are the work of Katerina Limpitsouni. Check Katerina’s stuff on undraw.co.