How Kotlin & Swift Re-energize the Case for Writing Native Mobile Medical Apps

Mobile apps have, without a doubt, changed the world.  The innovation, ease, and accessibility they offer has not only benefited users but also businesses who have taken the leap into the mobile marketplace.  However, mobile development does not come without its challenges (which we’ve outlined in one of our previous posts).  And for those of us developing mobile medical apps, the complexity expands as the need to support multiple mobile OSs and devices grows.

Creating a mobile app across platforms is not an easy task, even when using cross-platform solutions.  However, with the release of the Swift and Kotlin programming languages, we’re finally seeing a convergence in mobile development tools that re-energizes the native app debate.  Could it be that developing “duplicate” native apps is no longer as onerous as it once was?

Cross-platform Solutions: Where they fall short

In the quest to make mobile development more efficient, cross-platform solutions such as Xamarin, PhoneGap, and React Native have proven to be powerful tools.  The concept behind these solutions is to be able to develop as much of a universal mobile app using a single codebase as possible.  Publishing the app still requires using the respective platform tools, but for less complex apps, the bulk of the work can be done just once.

The problem with these cross-platform solutions is that they work on top of the official platform tools, which results in some drawbacks:

  • Complex apps that utilize advanced features such as Bluetooth or Augmented Reality may rely heavily on native tools, and therefore require that you develop these features natively/separately. In this situation, the overall efficiency gains from using cross-platform tools is significantly diminished.
  • Because these solutions work as a wrapping layer, any updates to the underlying native tools and/or platforms can only be adapted by the cross-platform solution after the updates have been released. If anything in the app were to be broken by the updates, fixes may not be immediately available. For mobile medical apps, this could present issues.
  • Crafting custom and innovative user experiences (interactive charts, layouts, etc) can go beyond the more basic offerings (text fields, sliders, etc) provided by these solutions. To accomplish the experience you envision, native code may still be needed.  Supporting a cross-platform codebase mixed with native code increases code complexity.

The Native Revolution

Until recently, Objective-C and Java have been the primary native languages for iOS and Android, respectively.  In terms of syntax, support, and functions, the two come from very separate worlds.  Further, they were each shoe-horned into the mobile space, which was beyond the original vision for these languages.  The net result is that doing separate native development for each platform using these languages requires much more effort than it seems it should ever take.

It is not surprising, then, that new languages would emerge to change native mobile development for the better.

Both Swift (developed by Apple, now open-source) and Kotlin (developed by JetBrains, and also open-source) were born with very similar visions/goals.  Essentially, both languages meet modern software engineering standards, while also being able to evolve and adapt as technology and engineering change.  Because of the shared vision and timing, these languages look and feel extraordinarily similar.  Personally, as someone who developed iOS apps in Swift for years, Kotlin made my transition to Android quite easy.  Using these languages actually helps me develop clean, readable, and efficient code on the health care app projects I’m working on, no matter the platform.

Swift and Kotlin do, of course, have some differences. Implementing Bluetooth in iOS will be different than it is in Android, that is certain. However, the syntax and concepts for implementation in Swift and Kotlin are much more syntactically and fundamentally aligned than was the case with Objective C and Java. Because of this similarity, writing two separate native apps can now be accomplished much more quickly.

Conclusion

At Syncro, we have added Swift and Kotlin to our development toolkit.  While implementing truly native applications still requires writing separate apps, we have found that these new languages have made the process better in a number of ways:

  • The architecture and design of these two native languages match better than ever both syntactically and in practice. As a result, the amount of documentation to be written for both platforms is dramatically reduced.  This is a real bonus, especially when developing mobile medical apps subject to regulatory approval.
  • Compared to their predecessors, Swift and Kotlin offer modern language features, resulting in more readable, efficient, and maintainable codebases.
  • Accessibility to advanced mobile features comes naturally, opening the door for more innovative and rich possibilities for mobile medical apps.
    On a personal note, I have found that using Swift and Kotlin has made development more enjoyable in general. I think my colleagues at Syncro Medical would agree.

Swift and Kotlin are both born out of the same concepts, ideas, and visions. While hope for a truly universal/cross-platform solution will need to hold out longer, this sort of sibling rivalry significantly helps businesses and users enjoy the benefits of stable, secure, and quality native applications.  Consider these advantages when planning your next mobile application project.

Syncro Medical has many years of experience developing mobile medical apps. Whether you’re considering cross-platform or native development for your next mobile medical project, we’d be happy to talk about your project and share our insights regarding platforms and development tools, contact Syncro Medical.

Danny Bolella is a Software Engineer at Syncro Medical with a focus on mobile development. His software engineering experience includes industries ranging across energy, finance, and medical. Danny is an experienced Certified Scrum Master, which he leverages to lead team agile processes and continuous improvement. Danny holds a BS in Computer Science with a minor in History from Stevens Institute of Technology. Outside of work, he enjoys tinkering on his own mobile and web projects as well as going through agile blogs and community posts. When away from his keyboard, you’ll find him reading a biography, playing a board game with friends, or volunteering in the local community.

Comments are closed.