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.
- 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.
- What is more important: Time to market, or sustainable development over
time? Sometimes quick’n’dirty solutions make perfect business sense, sometimes they
- 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.
- 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
- 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.
- 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
- 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.
- How is the performance? Nobody wants sluggish, janky apps.
- Is it stable? Frequent crashes destroy an app's reputation quickly.
- 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.
- 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.
- Does it respect the look’n’feel of each platform? You don’t want your app
to look unintentionally alien on the target platform.
- 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
- 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.
- 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.
- 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
- 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.
- 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, …
- 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.
- Are cutting-edge platform features available right away? Especially when
using bridges or wrappers, support for the latest features can be delayed.
- 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
- How steep is the learning curve? Your team needs to be up-and-running in a
reasonable amount of time.
- 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.
- How distant is the given paradigm from the default way of doing things?
Nonstandard or exotic approaches can steepen the learning curve significantly.
- 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.).
- 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.
- 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
- Which build system does the technology use? There are many of them, but
they’re not all equally simple to use, fast, or extendable.
- How is the CI/CD support? It needs to integrate smoothly with your CI/CD
system of choice.
- 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
- How mature and effective are the tools? Your developers should focus on
your app, they shouldn’t be fighting the tools.
- Does the technology support hot reload, or dynamic feature modules? These
features usually greatly enhance developer productivity.
- Is the technology open source? There are countless advantages when it is.
- What is the availability, quality, and scope of 3rd party libraries? The
ability to reuse existing, well-tested code can make or break projects.
- 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
- 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.
- 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.
- Are consultants available if needed? Some of them are even helpful.
- What is the overall community sentiment towards the technology? Dedicated
fans are a good sign, but be careful not to fall for marketing tricks.
- Do other similar organizations have experience with the technology? Learn
from the successes and mistakes of others.
- 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
- Do you already have suitable developers? Why change a whole team, when you
might already have a stable, well-coordinated one?
- 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.).
- 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.
- 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.
- Do you already have some existing code? Rewriting from scratch is tempting,
but it isn’t always a good idea.
- 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.
- What is its value to your organization? It may earn or save you a ton of
money, or it may be a giant liability.
- How big is the technical debt? The value of unmaintainable code is not
great, to put it mildly.
- Can it be maintained and evolved? The software must be, well, soft. If
yours is rigid, again, its value is not that great.
- Can it be transformed piece-by-piece? Some technologies allow gradual
migration, some are all-or-nothing propositions.
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!