Why PDF SDKs Fall Short as Fillable Form Solutions
The title of this article might provoke strong reactions from some developers, and understandably so. However, we feel obligated to look out for our fellow developers by exposing important limitations to consider before adopting a solely focused PDF SDK for a broader forms use case, which we will share in the following sections.
In delving into the realm of PDF SDKs, it becomes evident that their suitability for fillable forms use cases is far from optimal. While originally conceived as a solution for document portability and accessibility, PDFs now face significant hurdles when it comes to modern digital interactions, particularly in the context of modern-day forms.
Why PDF Was Created
The first version of the PDF specification was released by Adobe in 1993. Adobe’s co-founder Dr. John Warnock launched the paper-to-digital revolution with an idea he called, The Camelot Project. The goal was to enable anyone to capture documents from any application, send electronic versions of these documents anywhere, and view and print them on any machine.
The Limitations of PDF SDKs
Developers grappling with PDF SDKs often encounter a myriad of challenges, chief among them being the outdated nature of the format itself. The binary data structure inherent to PDFs proves to be cumbersome, necessitating complex and costly solutions to abstract away this inherent complexity in manipulating or extracting data. Even with such measures in place, developers find themselves constrained by the limited scope of functionalities supported by traditional PDF services. A lightweight PDF form filler SDK compared to a much heavier PDF SDK results in a significant reduction in the binary size of the target apps.
PDF SDKs only support a select number of common field types, whereas more fields and the opportunity to create custom fields might be needed. Basic form elements like text input, images, and annotations may be supported, but more advanced features such as dynamic graphs, formula-driven tables, and other rich media (just to name a few) remain elusive within the confines of standard PDF SDKs. This stagnation in innovation is further exacerbated by the slow evolution of the PDF standard (ISO 32000), leaving developers with few avenues for meaningful progress.
Furthermore, the rise of mobile devices has underscored the inadequacies of PDFs in delivering a seamless user experience. Attempting to visualize and interact with fillable PDF forms on mobile platforms often results in frustration and inefficiency, highlighting the fundamental disconnect between PDFs and the demands of the modern mobile landscape.
“SDKs should support modern tech stacks -Kotlin, Swift, and React Native- with highly customizable UI, supporting features like light and dark mode, accessibility, and custom themes right out of the box.”
Vishnu, Senior Mobile Developer at Joyfill
Designing ISO 32000 for Today
Why do software companies keep rolling the same form solutions over and over again instead of just using the PDF standard? We see it time and time again. By looking at modern form tools you can obviously see that the PDF standard falls far short of what they’re trying to achieve. These companies have been forced to roll their own standards internally since the previous PDF standard is so limited, slow, and outdated.
Solution: The JoyDoc Standard
Response from the Joyfill team:
Joyfill is going to create a standardized e-form format in JSON. The goal is to create an engine/data model that can handle any kind of form. The engine and data model should be able to evolve rapidly, be extended (third-party integrations), and be usable on any device.
We’re determined to invent what should exist in today’s digital age. We’re not interested in simply building tooling around a format that already exists and accommodates an outdated solution. We will create what should exist! What PDF did for desktop/PCs is what Joyfill will do for web and mobile.
We are going to build really amazing on/off ramps to support all the legacy data that will be migrated. Then we are going to build really incredible tooling and products to support the new Joyfill standard and eliminate the need for anyone to ever go back to the old PDF standard.
- We must be able to evolve the standard very quickly to keep pace with innovation.
- Needs to be backwards compatible to support existing integration and allow for optional upgrades.
- Needs to be extendable. There is no way to accommodate all scenarios or niche use cases. So we have to be extendable or customizable to accommodate niche requirements. Even if we don’t solve 100% of the problem due to some niche use case we still probably solve 80% of it and still want the user to get those gains.
“My theory is that we can pioneer the new standard for these web and mobile interfaces. We can provide the form standard and tooling to solve this problem for the modern digital era.”
Josh Pagley, CTO at Joyfill
At Joyfill, we recognize the inherent limitations of traditional PDF SDKs in fillable forms use cases, which is why we’re pioneering a new approach at Joyfill. By transcending the constraints of PDFs and embracing a multi-device-first philosophy, Joyfill empowers developers to create dynamic, user-friendly form interfaces without being tethered to the antiquated confines of the PDF format.
While PDF SDKs have served as a cornerstone of document management for decades and still service a wide landscape of use cases, their efficacy in fillable forms use cases is increasingly called into question. As developers strive to deliver intuitive, adaptable form experiences, it’s clear that a fresh form technology perspective is needed. With Joyfill, we’re proud to offer a modern solution that redefines the possibilities of form experiences and interaction in the digital age.