If you have arrived at the junction of I have an idea and I am ready to build it, you probably have some idea of your vision for it as either a web/browser-based application or a native mobile app.

Before you dive into coding, actually implementing, and spending money on your idea, we encourage you to consider the following 6 questions, to make sure you are picking the most appropriate solution and getting the most bang for your buck, especially as you are starting out.

1) Is this something people will use every day?

Thinking about this question, and being honest with yourself when you answer it, can help you figure out if a native mobile application (iOS/Android app stores) is the correct route for you. Think about the apps you download, and more importantly keep, on your phone. When I make this list it includes things like: my favorite weather app, my Garmin watch app for syncing my running and workouts, messaging applications, Instagram, Waze, etc. These are apps that I use frequently or are important and worth the storage space. If I purge my phone when organizing or freeing up space, I have strong reasons to keep them. Think about the idea you want to build: does it meet any of these criteria? Would it honestly stand a good chance of surviving a phone purge by your target users? If yes, native mobile may be the way to go. If the honest answer is no, you may be better off with a web application.

2) Is this something your users will need/want to access outside of a mobile device?

If you are picking between implementing mobile or web, and are not planning or able at the moment to do both platforms, this is an important question to ask yourself. Who are your target users? Will they want to access your platform and content/functionality from a laptop or desktop computer? If the answer is yes, they will, then you should probably consider building a web application that is accessible from any browser with an internet connection. At this point you may be thinking, “but people want to use it from their phones too,” and the answer there is what we like to call “Mobile-first” design for your user interface. This is a way of designing interfaces and user experiences for web applications that start with the smallest screen sizes first and move up designing for larger screens last. This helps ensure that when you make decisions about what to display, where, and when, you are prioritizing the experience of a mobile user, while not limiting yourself to just the app stores and allowing you to service desktop-based users too.

3) Is this a paid service?

This matters more for your income and is a personal choice. Apple can be very strict about in-app payments and if you plan to use their built-in app store payment platforms, it’s very expensive compared to a regular credit card payment processor. If you plan to use a separate payment processor within your app and not an app store-sponsored method, you should verify the rules of any app store (Apple/Google Play) you plan to publish in, and make sure your payment processor usage abides by their guidelines. Otherwise, they could reject your application when you try to publish it on their platform(s).

4) Does this idea require access to device hardware or sensors?

If your app is dependent on collecting data from hardware devices or sensors such as the accelerometer, Bluetooth connections, etc on a phone. Accessing that hardware can be much more challenging from a browser-based application than a native application. As you are likely familiar with prompts to access your microphone or camera, location data, or Bluetooth when using native applications on your phone, there is a well-defined method for gaining the user’s permission and then subsequently gathering information from those sources. If the functionality of your application depends on more complex information from a device than your location or photo library, it may be much easier to access those information sources and sensors if your application is a native app.

5) What’s your timeline?

In our experience, generally it’s faster to put together a web application and get that to market than it is to create a mobile application and get it to market on the app store(s). This is partly due to the flexibility and wide array of implementation options for web as compared to the relatively rigid requirements of the app stores, but also because anyone can deploy a web application with little to no approval time, as long as you know how to deploy it. With native mobile applications, Apple and Google must review and can approve or reject your app based on specific features, the information you wish to collect from users, or a variety of other factors. This review process stands between you and going to market, which depending on your goals, your timeline, and if you think you are creating something that they could end up rejecting, may be a deciding factor in choosing between implementing your idea as a web-based application or a native mobile app.

6) Do you have important content or features an app store may reject?

We recently experienced a temporary rejection from the app store because they didn’t like a single, voluntary and optional question on the user profiles that would have allowed a user to share with others whether or not they had been vaccinated. Despite the fact that people are sharing photos of their vaccine cards en mass on all forms of social media, the entire app was rejected citing this one optional question. Getting to market in a timely manner was important so we removed that question and are re-thinking how we might allow users to communicate either their feelings about or status with covid so they can decide if they want to meet in person— as this is currently a big consideration for many users. This temporary setback was a bummer, and while it wasn’t a show stopper for us, had the same exact application functionality been built as a mobile-first web app, it would have been totally free of any judgment or curation by Apple, and we could have included whatever questions we wanted (assuming you maintain any applicable data protection standards for the information collected). So it’s worth giving some thought to what type of application you are building. If you think submitting to an app store has the possibility of rejecting one or more features that may be a show-stopper for you, then native mobile may not be the way to go.

We hope these questions can serve as food for thought and a discussion starting point if you have to decide between implementing your idea as a native mobile app (iOS/Android) or a browser-based web app. Once you pick, we wish you the best of luck in your endeavor to turn your idea into a reality, and if we can help, drop us a line!