Hybrid technologies allow you to develop cross-platform applications faster. They also enable web developers to create native mobile apps.
In this article, we’ll provide an overview of every hybrid technology that we support, and we’ll discuss the various aspects that you and your team should consider when evaluating the adoption of a hybrid technology for your project.
So let’s get started!
ℹ️ Note: This blog post was updated on 22 July 2021 to remove mentions of Titanium, as Axway announced End-of-Support for the Titanium SDK effective 1 March 2022.
Take a look at the table below which shows the programming language and the supported platform for each wrapper:
|Wrapper||Programming Language||Supported Platforms||PSPDFKit Platform|
|Flutter||Dart||Android and iOS||PSPDFKit for Android and iOS|
|Microsoft Xamarin||C#||Android, iOS, macOS, and Windows||PSPDFKit for Android, iOS, macOS, and Windows|
Most of our hybrid wrappers are centered around mobile app development. However, there are a few hybrid technologies, like Electron and Xamarin, that allow you to develop desktop (macOS and Windows) apps using PSPDFKit for Web and PSPDFKit for macOS, respectively.
The choice of which hybrid technology is right for your project is a decision that you and your team will ultimately have to make. Committing to a specific hybrid technology can be a tough decision to make. In this section, we’ll discuss the questions you should ask when evaluating a hybrid solution.
It’s important to note that some big companies back some hybrid technologies. For example, Xamarin is backed by Microsoft, Facebook is behind React Native, and Flutter is supported by Google.
Most hybrid technologies are open source, which is great, because you have a clear view of the known issues and pull requests, and you can also contribute. We recommend that you look at the open source repositories for each technology and see how active the community is at fixing bugs and adopting new features.
We also suggest looking at the Stack Overflow topics and the official documentation for each technology.
In our native SDKs, we expose a lot of APIs so that they can be fully customized. However, we cannot offer all of our native APIs in our hybrid wrappers for reasons like the native design patterns being very specific to the platform and different from the wrapper. So we generally expose a subset of the native APIs, which allows you to develop a fully functional app for most use cases. For advanced use cases, we recommend that you extend our wrappers.
There are two ways of extending our wrappers:
Pull Request Contributions — If the requirement is generic and would benefit other users, then we recommend contributing with a pull request.
Forking — If the requirement is unique — for example, you need to add a custom stamp button that uploads the document to your backend — then we recommend forking the repository and making the change in your fork. For more details, please take a look at how we did it for our React Native wrapper in customize-the-toolbar-in-native-code.
With each new update of our native SDKs, we test our wrappers to make sure that the newly changed APIs don’t impact our wrappers. It’s essential that you use the most recent versions of both our wrappers and SDKs to ensure a consistent development environment.
Our Xamarin wrappers use all of the native APIs, and it involves a considerable amount of effort to update the wrappers to match the SDK release. This process can take a few days and sometimes a week, depending on the extent of the update.
We noticed that React Native is the wrapper that has gained a lot of traction lately, and we recently extended its API and wrote blog posts like How to Extend React Native APIs and Advanced Techniques for React Native UI Components.
We hope this article will help you when deciding which hybrid solution to adopt in your next project. We recommend that you explore our open source repositories and our documentation. We always welcome pull request contributions from the community.