Embarking on a new project is exciting. So many possibilities, so many choices! But you better get them right from the start, otherwise, your project might suffer in the long run.

Choosing a platform to build your mobile app can be a daunting task. For some apps, a simple responsive web or PWA will suffice, whereas for others only native solutions will do. And there’s of course a range of popular cross-platform or hybrid technologies like Xamarin, React Native, Flutter, or Kotlin Multiplatform, to name a few.

Evaluating all these alternatives is difficult. There are no universally right or wrong answers, but to make the choice easier, we offer you a list of questions that, when answered, will help you make the right choice.

Lifespan

1. What is the planned lifetime period of your app? Short-lived marketing or event apps have different requirements than apps that need to live happily for years.
2. What is more important: Time to market, or sustainable development over time? Sometimes quick’n’dirty solutions make perfect business sense, sometimes they are poison.
3. Will the chosen technology still exist when your app approaches the end of its life? Obsolete or abandoned technology will severely hinder your ability to support and expand your app.
4. Will the technology be supported by its authors? Will it be supported on target platforms? Open source technology can be theoretically maintained by anybody, however, in practice, the majority of work often rests on a surprisingly small number of individuals.
5. How will the technology evolve over time? There is a significant difference between a technology that the authors primarily develop to serve their own needs (even if it’s open-sourced), and a technology that is truly meant as a general-purpose tool.
6. Is there a risk of vendor lock-in? If the technology is currently free to use, will it still be free in the future? What is the cost of moving to an alternative solution?

Runtime

7. What runtime environment does the app need? The app may be compiled to native code, it may need bridges, wrappers, interpreters, etc. Those can differ wildly in various regards, sometimes by an order of magnitude.
8. How is the performance? Nobody wants sluggish, janky apps.
9. Is it stable? Frequent crashes destroy an app's reputation quickly.
10. How big are deployed artifacts? Do they need to be installed? A complicated or slow installation process lowers the chances that users will even launch your app, while every extra megabyte increases churn.

UI

11. Does the technology use native components, or does it draw its own? Can the user tell the difference? Non-native components may look similar, but users are surprisingly sensitive to even small inconsistencies.
12. Does it respect the look’n’feel of each platform? You don’t want your app to look unintentionally alien on the target platform.
13. Are all platform-specific components available? Custom UI components often demand a lot of work and if many are not available, your app can get very expensive, very quickly.
14. How difficult is it to create custom components? Even if all platform components are available, there will be times when you’ll need to create your own—and it needs to be reasonably effective to do so.
15. How difficult is it to create animations? When done right, animations are a crucial part of the UX, but implementing animations can sometimes be exceedingly difficult.
16. How are the components integrated with the target system? Appearances are not everything—you also need to consider things like gestures, accessibility, support for autocomplete, password managers, etc.

Compatibility and interoperability

17. What level of abstraction does the technology bring? Some try to completely hide or unify the target platforms, some are very low-level. Both can be good, or bad.
18. Which system functionalities does it support directly? UI is not everything—chances are your app will need to support at least some of the following things: biometry, cryptography, navigation, animations, camera, maps, access to user’s contacts or calendar, OCR, launcher widgets, mobile payment systems, AR/VR, 3D rendering, sensors, various displays, wearables, car, TV, …
19. How difficult is it to access native APIs? Every abstraction is leaky. There will come a time when you’ll need to interact with the underlying platform directly. The difficulty to do so can vary greatly.
20. Are cutting-edge platform features available right away? Especially when using bridges or wrappers, support for the latest features can be delayed.
21. What other platforms does the technology support? The ability to run your app on other platforms can sometimes be very advantageous, just keep in mind that the extra investment required can vary.

Paradigm and architecture

22. How steep is the learning curve? Your team needs to be up-and-running in a reasonable amount of time.
23. How rigid is the technology? Some frameworks try to manage everything—painting by the numbers can be simple and effective, but at the same time, it may limit your ability to implement things for which the framework doesn’t have first-class support. On the other hand, libraries may be more difficult to wire together, but they grant you greater freedom.
24. How distant is the given paradigm from the default way of doing things? Nonstandard or exotic approaches can steepen the learning curve significantly.
25. Is the technology modular? On what levels? Usually, you need the ability to slice the app across various boundaries (e.g., features, layers), and at various levels (e.g., code, compilation, deployment, etc.).
26. How does it scale? Nowadays, even mobile apps can easily grow to hundreds of screens, and the app mustn’t crumble under that weight for both its developers and users.

Tooling

27. Is there an official IDE? What does it cost? Can it be extended with plugins? Developer productivity is paramount, and the best tools pay for themselves quickly.
28. Which build system does the technology use? There are many of them, but they’re not all equally simple to use, fast, or extendable.
29. How is the CI/CD support? It needs to integrate smoothly with your CI/CD system of choice.
30. What about testing, debugging, instrumentation, or profiling? Your developers and QA people need to be able to quickly dissect your app to identify and fix potential problems.
31. How mature and effective are the tools? Your developers should focus on your app, they shouldn’t be fighting the tools.
32. Does the technology support hot reload, or dynamic feature modules? These features usually greatly enhance developer productivity.

Ecosystem

33. Is the technology open source? There are countless advantages when it is.
34. What is the availability, quality, and scope of 3rd party libraries? The ability to reuse existing, well-tested code can make or break projects.
35. Is the official documentation up-to-date, complete, and comprehensive? While learning about particular technology by trial and error can be fun, it certainly isn’t effective.
36. Do best practices exist? If there are many ways to do a thing, chances are some of them will end up with your developers shooting themselves in the foot.
37. How accessible is community help? Are there blog posts, talks, or other learning materials? Search StackOverflow, or try to find newsletters, YouTube channels, podcasts, or conferences dedicated to the technology in question.
38. Are consultants available if needed? Some of them are even helpful.
39. What is the overall community sentiment towards the technology? Dedicated fans are a good sign, but be careful not to fall for marketing tricks.
40. Do other similar organizations have experience with the technology? Learn from the successes and mistakes of others.

Human resources

41. What primary programming language does the technology rely on? It isn’t enough that developers are able to edit source files to make the machine do something—they need to be able to write idiomatic and expressive code that can be read by human beings.
42. Do you already have suitable developers? Why change a whole team, when you might already have a stable, well-coordinated one?
43. Will mobile developers be effective using the language? There could be great friction when switching developers from one language to another, especially when the new language is significantly different (e.g., statically vs. dynamically typed, compiled vs. interpreted, etc.).
44. Will non-mobile developers be effective on mobile platforms? For example, some technologies try to port web frameworks to mobile platforms, so it might look like a good idea to assign web developers to the project—but the reality is not that simple.
45. What is the current market situation? What is the market profile of available developers? You usually need a suitable mix of junior and senior developers, but they might not be easy to find, or their cost might not be economically feasible.

Existing codebase

46. Do you already have some existing code? Rewriting from scratch is tempting, but it isn’t always a good idea.
47. What have you invested in it so far? It may be very cheap to throw away, or it may represent a major asset of your organization.
48. What is its value to your organization? It may earn or save you a ton of money, or it may be a giant liability.
49. How big is the technical debt? The value of unmaintainable code is not great, to put it mildly.
50. Can it be maintained and evolved? The software must be, well, soft. If yours is rigid, again, its value is not that great.
51. Can it be transformed piece-by-piece? Some technologies allow gradual migration, some are all-or-nothing propositions.

Final questions

Each app has different needs, and there will always be tradeoffs. In the end, you’ll need to prioritize the various viewpoints implied by the aforementioned questions.

Which qualities are most important for your project? Which properties bring you opportunities? Which increase risk?

When you put the alternatives into the right perspective, you certainly have a much better chance at success. May your apps live long and prosper!