Navigating the world of app creation is complicated. Developing an app is a tough undertaking, so making good choices about how it’s going to be built is crucial. Here’s a quick overview of the main options for developing a mobile app.

Native apps

“Native” apps are compiled and installed on devices. They are usually installed through the App Store or Play Store. Because they are installed and run on the device, they can work well offline. Data generated through the app can be saved in the apps storage area.

There are 2 general approaches to creating native apps with different benefits: standard toolset provided by the platform provider and 3rd party compilers.

Standard toolset

Apple’s standard languages for creating native apps are: Swift, SwiftUI, and Objective-C. Apple also provide Xcode as a tool to edit and manage the code.

Google supports Java and Kotlin as languages for use with their editor Android Studio.

Using the standard tools has major benefits:

• Most popular option. This means that it will have the best documentation, and many people will have had similar issues to you.
• Less risky. It is likely to have the most longevity as the setup is provided by the platform provider. Other options are more likely to stop operating.
• Open source libraries. A large amount of open source libraries are available to help with some basic tasks such as API communication and UI animations.

Negatives:

• Learning curve. It’s possibly not a capability you have in house and the learning curve can be tough.
• Duplicate logic. A different app has to be developed for the different platforms. This approximately doubles the effort.

Cross-platform 3rd Party app development tools

Companies provide tools which allow developers to generate native apps using other languages.

There are 2 primary benefits:

• Developers can use a familiar language. This can avoid a costly learning curve.
• Cross platform support. A lot of the providers allow compilation to both iOS and Android. This can save lots of duplicate code between the different platforms.

The negatives are:

• Dependency on new framework. This approach depends on another layer of code.
• Masked access to hardware. Although access to the hardware will be available, it will be through this layer. That means that support of features on the device isn't guaranteed.

Some examples are: Xamarin for developing apps in C#, RubyMotion for developing in Ruby, and ReactNative for developing in JavaScript.

Web apps

These are apps that can look and feel like native apps but aren’t built in the same way. They are essentially smart websites. This can have fundamental implications on what you can do from the app. It can limit use of the device’s hardware.

The pros are:

• It’s simpler. Developing for the web is simpler than native.
• It’s cross-platform by default. Every smartphone support displaying web content. This also means that you’ll be able to provide a web based solution for desktop with little effort.

The cons are:

• Limited functionality. Web pages can be limited in its access of the smartphone’s hardware. Such as certain aspects of storage, bluetooth, location, camera.
• Not as nice for the user. It doesn’t always feel as good as native applications. The interfaces can feel a little slower and clunky.

Hybrid Native-Web apps

A native app can be built to show a web page within a native ‘frame’. This will feel like a native app but will be always online. It’s quite a nice option if the app is expected to always be online. The app can still make use of the hardware where needed, and the user interface (UI) is generated on the web.

This approach is slightly less usual but we’ve done this for a couple of project with success.

Conclusion

Each of these options can be the right option in the right situation. It’s important to know what those options are and hopefully this helps towards that a little.