Want to Build an App? Try This Instead
Do you really need an *app*?
By “app,” I mean a program that you download onto your phone (or tablet) from the Apple/Google Store.
You can probably accomplish the same thing by making a website.
A website may be considered a “web app,” but for simplicity I’ll use the term “app” in this article to reference a “native app” — i.e. code written or compiled into a language native to the respective operating system, and thus accessible only by downloading from the Apple/Google Store.
First let’s go over the types of “apps”.
Three Types of Apps
There are 3 approaches to take in building an app:
100% Native
You’ll write code that is “native” to each operating system. You’ll need one for Android (Google) and one for iOS (Apple). You’re basically building two apps, so that could hypothetically double the time and money.
Hybrid
Use a single coding language that can compile (i.e. create) the “native” version for the respective platform.
Personally I’ve used NativeScript, but I have friends who prefer React Native (made by Facebook).
- Pro: Easier/Cheaper than the fully-native approach. Write the code once, deploy to multiple platforms.
- Con: Extra processing involved that converts the code. May be a little slower as there’s more going on behind-the-scenes that does the converting of non-native code into native code.
I’m a big fan of NativeScript. I didn’t even really want to say anything bad about them. The Con mentioned above is only an assumption and I have no proof that a truly native app would be more efficient. I do highly recommend this approach for a Minimum Viable Product (“MVP”).
Website in an App Shell
I do not recommend this approach, but mentioning it for completeness.
Users still download an “app” from the App Store, but the content simply displays your website. I’ve done this a few times, but the user experience is “clunky” and simply not as smooth as a real app. I suggest avoiding this.
Another option: make a website, not an app
Alternatively you can build a website, and not have it in an “app shell”. It would just be a regular website that people access from their browser.
If you’re focusing on building a Minimum Viable Product (as mentioned in Part One), I strongly recommend considering this possibility.
Advantages of a website vs a “native app”
A lot of developers, myself included, are already familiar with making websites (or “web applications”). This could potentially be cheaper and faster. More specifically, it may be easier (and cheaper) to find a web developer than find a (native) mobile app developer.
The current standard for website developers is to make mobile-friendly sites. The industry term is a responsive website, as the site will “respond” to the different screen sizes (ex. phones, tablets, laptop screens, huge computer monitors). Web developers/designers are making sure that their website will appear “right” on multiple screen sizes.
Disadvantages of a website vs a “native app”
Sometimes you need the functionality of a phone:
- Do you need to access the user’s contacts list?
- Do you need to take a picture with the user’s phone?
- Do you need GPS functionality?
- Do you need gyroscope capability (i.e. physically tilt your phone and something happens)?
While there are ways to get phone-based functionality from website code, such as the items above, it tends to not be as good of a user experience. It’ll work, but it may not work as well (i.e. “friendly” from a user’s perspective — or it’ll be “clunky” as I previously described).
The concept of a Progressive Web App (“PWA”) is starting to gain in popularity. This is where website code is created specifically to resolve the issues above, and more.
Another example is “swiping.” While you can write website code to accomplish this- and I’ve done it- it’s just not as smooth as compared to the native approach.
The biggest disadvantage of a website over a truly native app will be the difficulty in having your app appear on the user’s home screen. If it were a native app, it’ll automatically just be there once it’s downloaded from the App Store. But as a website, users will have to explicitly find the option for “Save to Home Screen” from their mobile browser.
I use Chrome on my iPhone. In iOS, I think this option is only available in Safari — alas, another barrier.
The Review Board: Prepare For Headaches
The biggest difference (advantage? disadvantage? ) is a website won’t be accessible from the Apple/Google App Stores. Eventually you’ll want it in there if it gains popularity, but if you can delay this- for the purpose of creating the MVP- you’re better off.
Both Apple and Google have people (real humans!) that review your app, and it must be approved before it’s allowed in the App Store.
Apple Hates Developers
It seems like every time I go to publish an app to Apple, something goes wrong. There’s usually some sort of “required software upgrade,” be it in the version of the software used to submit to the App Store, my operating system, or something else.
Personal bias: I don’t launch apps/updates frequently, so the delay may be why I experience these types of issues.
More than once, and this happened to more than just me, I recall Googling issues that several other developers run into; all trying to have their code become compatible with Apple’s latest system requirements.
Apple Loves Users
The app store submission process is rather rigorous. Apple wants its users to have a pleasurable experience, and will nit-pick at everything (as they should)!
One time that, even though the app itself was acceptable, Apple found issues with my marketing images (the pictures you see in the App Store). Thus it got rejected and was prevented from going live.
Apple can reject your app for a variety of reasons. One rejection I received, which I’m paraphrasing here as my interpretation, was that the app was “not useful enough”. 😫
Google Loves Everyone
To date, I have not had any issues with uploading my app to the Google Play Store nor having rejection issues.
What Will It Cost?
Website Fees: Domain
If you want a custom domain (ex. yourapp.com) then it’ll cost ~$10/year.
Website Fees: Hosting
You need somewhere for the public to access your app. You won’t want to use your computer for this, so it’s better to hire a company to use their servers.
There are free hosting options out there, but there may be limitations. For example Heroku has a free hosting tier but there’s a delay when a user first loads up the website. After there’s some activity, everything will work as normal- for a bit.
Or you can pay a company to host your site. For an MVP that isn’t expecting a ton of traffic at first, you can probably find one for about $5/month.
Whether you build a native app or a website app, you’ll probably need a website, in some form.
App Costs
To have your app listed in the App Store, that costs money.
At the time of writing:
- Google charges a one-time fee of $25
- Apple charges an annual fee of $100
When people to go download your app, it’ll say Made by [so-and-so]. It’s a little more professional to have it Made by [some company] vs Made by [some person’s name]. The cost for setting up a company varies by state (for those in the U.S.), but be aware that there will be a potential cost associated with creating a company (whether it’s an Inc, LLC, etc.).
Years ago I used Legal Zoom to set up a company. They made it pretty easy, but in my opinion, it was not worth the several hundred dollars I ended up spending. Since then I’ve established a separate company “manually” through my state that was significantly cheaper and it was only slightly more effort.
Paying For Technical Services
If you need to hire someone to perform a technical service (ex. coding), it could potentially cost hundreds or thousands of dollars. It depends on what you need done / the complexity of what you’re trying to build. It’s not uncommon for people to charge $50/hour, $100/hour, or even more!
I mentioned in my previous article that you get what you pay for. Sometimes if you find designers/developers overseas (I say this, being based in America), then the hourly rates may be lower. Be sure to look at that person’s previous work and reviews left by others.
Share The Wealth: A Requirement
If your app costs money for the initial download or has a subscription platform that users are consistently paying you a monthly fee, Google and Apple will take a cut of your profits.
In late 2020, there was a company that processed subscription payments only through their website and didn’t use in-app payments; thereby avoiding the need to give Apple 30% of their profits. Apple got mad and removed the app from their store. Work-arounds were made such that it’s now available again, but it was a big deal in the app developer community.
At the time of writing, both Apple and Google will take 30% of your sales. However they both offer a program such that they’ll only take 15% if you earn less than $1million/year.
Enough about websites: I want a native app 📱
No problem, just be aware of what’s involved. You’ll most likely need to make an app for both Android (Google) and iOS (Apple). Unfortunately the code for each of those is different; you’ll need to hire two coders (or someone that is familiar with both programming languages).
You could also use the “Hybrid” Coding Approach, mentioned above, to have a single codebase for the app. Keep in mind you’ll still have to deal with both Apple and Google separately in the Submission/Review process.
Summary
If you’re starting a business that requires an app, consider having the MVP be a website instead. It may be quicker and more cost effective.
Pros of making a website instead of a native app
- Potentially quicker/cheaper to build
- No need for approval to be listed in the App Store
Cons of making a website instead of a native app
- People want an “app”. They want to download something from their respective App Store. They don’t want to manually create a shortcut for their home screen.
- Unless you use something like NativeScript or React Native, you’ll have to build two apps: one for Google and one for Apple. This will potentially add to the time and cost it will take to build.
- There’s some functionality (ex. swiping) that performs much better if native.
This is the final part of a mini-series for non-technical advice in app development.
Previous sections are:
