Nowadays, there are many pro­gram­ming lan­guages and frame­works to choose from. The choice of a par­tic­u­lar one depends on many factors like busi­ness goals, avail­able resources, time, the type of applic­a­tion, and its require­ments. In this case study, we’d like to show our jour­ney from cross-plat­form devel­op­ment based on Flut­ter to a nat­ive pro­gram­ming lan­guage approach.

Our cus­tom­er PROXESS GmbH

PROXESS GmbH is a lead­ing pro­vider of doc­u­ment man­age­ment and pro­cessing sys­tems with a wide tool­set of solu­tions serving over 2.800 cus­tom­ers and 100.000 users.

Proof of concept “PROXESS Now”

Dur­ing the pan­dem­ic, many people were work­ing remotely. But print­ing, scan­ning, and upload­ing hun­dreds of doc­u­ments on a daily basis can be quite a chal­lenge when work­ing from home and without the right toolset.

That’s why our cus­tom­er decided to devel­op a user-friendly mobile scan­ning applic­a­tion. The App was sup­posed to work on both Android and iOS, allow to log into the sys­tem using a QR code that can be down­loaded from a web portal, allow users to take pho­tos of a doc­u­ment, send the doc­u­ment to the appro­pri­ate data­base, and save it togeth­er with cor­res­pond­ing attrib­utes. For this, we cre­ated a proof of concept based on Flutter.

What is Flut­ter and why did we choose it?

Flut­ter is an open-source frame­work inven­ted by Google for cre­at­ing applic­a­tions on vari­ous oper­at­ing sys­tems. Ini­tially avail­able only for Android devices, it cur­rently allows you to build applic­a­tions also for iOS, macOS, web browsers, and more.

Flut­ter allows for effi­ciently imple­ment­ing attract­ive-look­ing, respons­ive user inter­faces. It enables the sim­ul­tan­eous use of UI com­pon­ents and design pat­terns from vari­ous plat­forms — includ­ing Mater­i­al Design wid­gets derived from Google design lan­guage and the Cuper­tino set, derived from Apple’s oper­at­ing systems.

You can read more about Codelab’s applic­a­tions based on Flut­ter in the pre­vi­ous art­icle.

The most sig­ni­fic­ant advant­age of Flut­ter apps is one code base for all plat­forms. This means that the devel­op­ment and test­ing are faster, more fea­tures can be added to the scope, and the main­ten­ance is easi­er and less time-con­sum­ing. Using Flut­ter can give you the edge in effect­ively bal­an­cing pro­ject time, cost, and scope.

But is Flut­ter always the best choice? Is it bet­ter than nat­ive apps? Our use case showed that some­times you have to think twice before going for a cross-plat­form solution.

The final product “PROXESS Now”

Devel­op­ing a proof of concept in Flut­ter at first gave us already a lot of insights and led us to the con­clu­sion to go for a sep­ar­ate devel­op­ment on iOS and Android instead of a cross-plat­form approach for this spe­cif­ic use case. And here is why:

  • iOS-level build-in features

iOS has a great build-in solu­tion for doc­u­ment scan­ning (VNDoc­u­ment­Cam­eraView­Con­trol­ler). As scan­ning was the cru­cial fea­ture of the mobile applic­a­tion we wanted it to have seam­less func­tion­al­ity and strongly recom­men­ded the iOS build-in solu­tion. iOS also provides oth­er import­ant fea­tures that were cru­cial to our solu­tions such as doc­u­ment pre­view­ing (QLPre­view­Con­trol­ler) and bio­met­rics (Face ID, Touch ID).

  • Android third-party libraries

Third-party lib­rar­ies and pack­ages have a sig­ni­fic­ant impact on soft­ware devel­op­ment as they are usu­ally open-source, pre-tested, and eas­ily avail­able. Since Flut­ter is still rather new for mobile app devel­op­ment, the avail­ab­il­ity of such pack­ages and lib­rar­ies is lim­ited. The frame­work is still in a grow­ing stage and con­tinu­ously improv­ing. It’s hard to pre­dict if there will be any lib­rar­ies miss­ing in the future. In our case, we used the fin­ger­print bio­met­ric authen­tic­a­tion provided by the Android frame­work. On the oth­er hand, we had to use an extern­al solu­tion provided by Pixel­net­ica for scan­ning the documents.

  • A grow­ing scope of func­tion­al­it­ies for future releases of the application

At pro­ject kick-off, we developed a clear pic­ture and detailed under­stand­ing of all require­ments and func­tion­al­it­ies for the ini­tial ver­sion of the product. How­ever, the future fea­ture set was very unclear and many ideas were float­ing around. In order to assure a future-proof solu­tion and reduce the risk for fur­ther devel­op­ment, a nat­ive devel­op­ment approach seemed the best move.

  • Pos­sible delayed adjust­ments for new Android and iOS ver­sions — Flut­ter developers must take time to adjust

New fea­tures imple­men­ted in most recent iOS or Android ver­sions nor­mally are not avail­able for Flut­ter at the time of release. It takes time for Flut­ter developers to adapt and adjust their pack­ages and lib­rar­ies. It might be not rel­ev­ant for most of the products (since apps must be back­ward-com­pat­ible) but it has to be taken into con­sid­er­a­tion when choos­ing tech­no­logy for the next months or years.

  • Developers avail­ab­il­ity

Developers’ avail­ab­il­ity is also an import­ant factor to con­sider before start­ing a new pro­ject. In gen­er­al, more nat­ive (iOS, Android) developers are avail­able than people spe­cial­ized in Flut­ter development.

Wrap­ping Up

Thanks to the cus­tom­er­’s trust in our exper­i­ence and expert­ise, the devel­op­ment was a big suc­cess. “PROXESS Now” is avail­able on Google Play and the iOS App Store. It sim­pli­fies the scan­ning, upload­ing, and pro­cessing of doc­u­ments in a DMS wherever you go.

There are many types of mobile applic­a­tions on the mar­ket, and dif­fer­ent frame­works and tools avail­able. The choice is often more com­plex than between Flut­ter and nat­ive languages.

Not sure what is the best approach for your product? Then bet­ter con­sult Codelab’s expert developers.