5 Questions to Ask Before Beginning Mobile App Development

Consider these five questions to ask before beginning your mobile app development project—from choosing between cross-platform mobile development or native, to investing in the right vendors.

When you’re evaluating different mobile development solutions, you’ll often see head-to-head comparisons like “Cross-Platform vs. Native” or “Low-Code vs. Full-Code”.

These comparisons provide feature checklists, performance reviews, and other helpful info. But to pick the right mobile app development approach, you need to dig much deeper.

If you’re actively evaluating mobile solutions, this guide is for you. The goal of this article is to help you address the key app development questions that you might not think to consider (beyond the feature checklists), in order to find the right approach for you and your team.

Here we go.

Purple image of purple computer

1. Do you have the talent in-house or do you need to hire for the right skills?

People are arguably the most important ingredient in any development project. Before you pick a solution, you’ll want to think about the talent on your existing team(s), and whether you’re willing to go hire for new skills if necessary.

Native Development

If you’re thinking about building with the native iOS development kit, for example, keep in mind that only about 8 percent of the world’s developer population is skilled in Swift, the programming language used to build iOS apps (according to the most recent Stack Overflow survey). If you don’t already have that kind of talent in-house, you will need to enter the highly competitive market for developers, and recruit people who do have that skill set. Keep in mind that the outsized demand for developers has resulted in a tremendous talent gap. In fact, in a recent Stripe survey, enterprise executives rated access to developer talent as a greater threat to their business than access to capital.

If that doesn’t sound appealing, then look for solutions that match the skillset of the people you already have in-house. In fact, many of the mobile app development approaches available today exist because of the scarcity of native talent. This problem is solved in one of two ways.

Cross-Platform Mobile Development: Build Native Apps with Web Skills

Solutions like React Native, Xamarin, and Ionic, allow you to build native mobile apps using JavaScript (the most widely used programming language in the world), or C# in the case of Xamarin, which is widely used among Microsoft developers. The idea behind this approach is to give web developers—and anyone else with JS skills—the power to build real native mobile apps with the knowledge they already possess, instead of going out to hire native developer talent.

Low-Code: Empower Citizen Developers

The other alternative is a low-code platform like Mendix or Outsystems. By abstracting much of the complexity of application development using visual app building environments and data modeling techniques, these solutions make it possible for a much broader range of talent, including non-developers (or “Citizen Developers”) who reside in the business or IT departments, to build applications on their platform.

To sum it up, whichever approach you choose, think about the talent you have in place. If you don’t have the necessary skills for native mobile app development, will you find a solution that matches the skills you have in-house, or are you willing to hire new people to do the work?

2. Choose your platform: Walled garden or open ecosystem?

If based on the people dimension you’ve decided to explore a cross-platform mobile development or low-code development solution, the next thing to consider is what type of platform you’re looking for. Before you begin developing your mobile app, ask yourself these questions: Do you care about convenience and speed most of all? What about flexibility and control? Your answer to these questions will help you decide whether you should build within a single platform or an open ecosystem.

Closed Platforms

Examples of closed platforms are vendors like Kony, Mendix, and Outsystems. While these platforms do integrate with third-party services, you generally rely on them for all of your application development needs. That usually includes a mobile app front-end development environment with a library of components, a data management or API mediation layer, and access to third-party services via their platform ecosystem.

Think of it as a “walled garden”. Everything you need is contained within the platform, and controlled and licensed by the vendor. This is a big selling point if you don’t want to think about how all the pieces fit together. It also helps to get a new project off the ground in a relatively short time, since everything you need is right there. Plus, as noted above, low-code solutions like Mendix and Outsystems offer a layer of abstraction that allows non-developers, even people in the business, to participate in app creation. This can be a big selling point if you’re looking to address a large backlog of simple, CRUD (Create, Read, Update, Delete) apps. On the other hand, you are generally beholden to the vendors for the lifetime of your app. Plus, the closed platform approach often limits the flexibility and control of your development teams, in terms of which tools they can use, and which services they can integrate with.

Open Ecosystems

Contrasted with the all-in-one approach to mobile app development are the open ecosystems and platforms like React Native, Xamarin, and Ionic.

In this scenario, you build the front-end UI and the logic of your mobile app using the vendor’s SDK, and then program backend connections for any services you need to connect to. For example, if you want to connect a React Native app to an existing legacy system, you would program the API connection in a data access layer that your team manages.

Some vendors, including Ionic, offer pre-built solutions for common use cases like user authentication, secure payments, offline storage, and more. Ionic Identity Vault, a complete biometrics-based authentication solution, is a good example. This gives you the same time-to-market advantage that you get with closed platforms, without giving up control.

In that sense, there’s no limit to what you can connect with. Another benefit of the open ecosystem approach is that the open platforms have much larger developer communities, with millions of developers all over the world, and hundreds of events and meetups. Plus, nearly all of the computer science programs in universities throughout the world instruct their CS students on these open development approaches, rather than closed platforms, so you’ll have no trouble finding talent to build with these solutions. This all makes it much easier to hire and train people to use the platform, with a vibrant developer community to provide mutual support and education over time.

3. What kind of partner are you looking for?

When you’re choosing a mobile app development approach for one project or your entire development organization, you should think about your choice as a long-term commitment. After all, you’re about to tie yourself to one particular vendor or ecosystem for the duration of your project. That’s a pretty big deal. Think about what type of partner you want in that type of relationship.

Vendor Services & Support

Will you need access to advisory services to help you through your project? Is vendor support important? Does the solution offer any sort of service-level agreement (SLA) regarding the timeliness of bug fixes? Do they offer long-term version support so you don’t have to migrate every time there’s a new version?

If any of these are important to you, look for a vendor that is willing to back their solution with support and services. According to a recent Gartner survey, a majority of enterprise teams (75%) end up requiring some type of assistance for their mobile app development projects, especially if it’s their first time building with a new solution, if they’re new to mobile development in general. As they put it:

“If your organization is implementing a [mobile application development platform] for the first time, we recommend using professional services from the vendor and/or a certified partner. This is especially important if mobile app development is also new to your organization, as starting from scratch could cause significant delays while new skilled staff are hired and existing resources are retrained.”

Roadmap Visibility & Influence

Another consideration is the ability to have access to, and/or inform, the roadmap for the solution. Large open source projects like React Native, backed by Facebook, are unlikely to grant that type of influence, but there are some solutions, like Ionic, that will allow their enterprise customers to participate in customer advisory boards or other channels of influence, to make sure their solution continues to be optimized for key uses cases valuable to their most important customers.

4. How important is design & UX consistency across teams and projects?

The inability to share components and enforce design standards across an enterprise has created inconsistencies that hurt users and brands alike. An increasing number of enterprises are recognizing the need to adopt a design system: A single design spec, or library of reusable components, that can be shared across a team or company.

Sharing UI Components Across Platforms, Teams, and Projects

When you’re choosing a mobile app development approach, think about how important it is to have a single UI library across not just mobile, but desktop as well. If you’re evaluating a solution, find out whether you can share components across different devices. Also, does the UI library work across front-end frameworks, or is it compatible with only one type of framework?

If you want to enforce design consistency across teams and projects, you’ll want to pick an approach that is compatible with multiple frameworks. Otherwise, you will need to get every development team in your organization using the same stack.

But, even if you do that, you still often have approaches where native components are running in your native mobile apps, and browser components are running in your web applications, so that components are not truly shared across platforms and devices. At that point, the only way to enforce design consistency is to provide design recommendations to developers and hope they comply.
Bottom-line: If design consistency is important, we recommend picking a solution that can be shared not only across mobile and desktop, but also across front-end frameworks, delivering a truly universal UI library or design system for all of your teams and projects.

5. How will the ecosystem evolve over time?

The last question to ask before beginning mobile app development: What will the future hold and how will the ecosystem that you’re going to standardize on evolve over time? After all, if there’s one constant in the mobile app development landscape, it’s change. That’s especially true in the world of mobile app front-end development, where framework favorites rise and fall over the years. At one time, Backbone and Ember were hot. Then came Angular. Then React. And more recently, Vue. What will tomorrow bring? Who knows!? But you can bet that there will be new contenders down the road.

Future proofing your development

With that in mind, give some thought to whether the solution you choose will give you the flexibility to choose new tools and frameworks over time. You may love React today, but will you love it 3-5 years from now?

At Ionic, after seeing the constant framework churn in the front-end development market, we decided to standardize on web components, instead of picking one particular JS framework to pair with. By doing so, Ionic now works with any framework. We offer versions of our solution for Angular, React, and Vue today, and we’ll be ready for whatever the hot new framework is a year from now. The point is, you don’t have to worry about it because the core of your mobile solution won’t depend on the underlying framework.

The choice is yours

To summarize, choosing a mobile app development approach is a lot more nuanced than a simple feature checklist or performance comparison. To find the right solution for your next project, you need to think more deeply about what’s best for you and your goals:

  1. Do you have the talent in-house or do you need to hire for the right skills?
  2. Do you prefer an open ecosystem or all-in-one platform?
  3. Will your chosen solution provide the advisory services and support you need?
  4. Is design consistency across teams and projects important?
  5. Will you be locked in to a single approach over the long term?

Once you’re able to answer these app development questions, it should be easier to spot the solution that’s best for you. And while you’re at it, be sure to check out Ionic’s enterprise offerings to see how we can help you find success with your next development project. If you're ready to launch your mobile projects with Ionic, connect with an Ionic App Strategist!

About Ionic

Ionic is an open source UI toolkit and developer platform that makes it easy to build, test, and deploy stunning, high-performance apps for any platform or device—all using a single codebase.

Since its inception in 2013, Ionic Framework has become the #1 adopted cross-platform mobile development framework in the world, serving a vibrant community of more than 5 million developers in over 200 countries.

Ionic’s open source Framework is best known for its developer-friendly tools and services, which have helped build and power notable cross-platform apps for consumer brands like Sworkit, Shipt, and MarketWatch as well as mission-critical apps for companies like NASA and Nationwide.

You’re in good company. Ionic powers millions of apps at some of the smartest companies in the world.

See all Customers →
Community Forum →

Stop by and say hello. The Forum is the best place to connect, ask a question, or help out other Ionic developers!

Explore the docs →

Take a look and get coding! Our documentation covers all you need to know to get an app up and running in minutes.