5 Reasons Why You Should Know Native Android or iOS Before You Start to Learn Flutter

We all like shortcuts. So, no wonder that when you’re at the beginning of your journey as a mobile software engineer, learning Flutter may look like an easy way into the world of the mobile app development.

If someone tells you that you can learn one technology to create an app that works both on iOS and Android, why would you even consider Kotlin or Swift?

Let me tell you this – when something sounds too easy to be true, there’s probably a catch.

There are at least five important reasons why it’s a good idea to get familiar with native technologies and only then dive into Flutter. Find out why this approach is worth your attention.

1. It takes more time to learn Flutter

What makes Flutter different from its most popular cross-platform alternatives? They are often based on well-known web technologies – React Native uses React.js and JavaScript, and Xamarin is built on top of .NET environment and C#.

Flutter, on the other hand, utilizes its own technology stack, with Dart programming language as a primary one. The solutions Flutter is based on are mostly unique, so it can be difficult to find the tutorials and other resources you could learn from.

What’s more, Flutter shares some elements with mobile development (e.g., statically typed language, theming system) while others are coming from the web development side (declarative UI, package system, asset configuration). This combination doesn’t make it easier to learn Flutter for people with no previous experiences in the development of native mobile apps. Besides learning the framework itself, they also have to understand mobile-specific paradigms for routing, notifications, deep-linking, etc.

2. Setting up some external services and integrations can be tricky

You can build simple Flutter apps pretty easily, but writing the code isn’t the only thing that software engineers do.

Besides the development, there are other important stages in the process of creating a mobile app. Take quality assurance or deployment, for example.

When you work on a project, you usually configure CI to build iOS or Android app. That build later goes through the deployment platforms, such as TestFlight or Firebase App Distribution. Finally, you send the build to production stage on Google Play or Apple App Store.

All these services need a proper setup – a separate one for each platform. Their configuration may be an overwhelming task for someone without a strong background in native app development. Especially given the fact that most tutorials or documentation files haven’t been written with a Flutter developer in mind, but rather for specialists who know native platforms.

Code signing and launch in app stores

Another mobile-specific component is code signing.

To upload iOS and Android apps to the stores, they have to be signed. For Android, the process isn’t too complex, but for iOS, it’s required to generate a development certificate that is bound to Apple Developer ID and used to sign the iOS build. Without a code signature, there’s no way to deploy and install the iOS app.

Developers with no mobile application background may struggle with figuring out how to properly manage signing certificates and sign the applications. Particularly, when they need to do it for both platforms at the same time.

3. It’s hard to understand how some elements work without native background

Despite Flutter’s efforts to maximally distance from the platform, not everything can be done without touching the native code or app configuration files. A good example are `flavors`.

When you want to build an app with a different environment, you can use the `--flavor <something>` parameter with `flutter run` in order to select a specific build configuration. But for flavors to work you also need to configure them in both iOS and Android projects that Flutter creates.

For Android, you must change Gradle configuration, defining `flavorDimension` and `productFlavors`. For iOS, you need to define custom schemas for each flavor and change project configuration to point to the right schema files.

As the project grows, the complexity of changes like these increases. For example, configuring separate instances of Firebase for different build types or setting different Package Name / Bundle ID depending on build variant.

Developers without native platform knowledge can of course follow tutorials and implement required changes. But the truth is that they may have problems with understanding how those changes actually affect the project, and why they are required.

There’s a large probability that experienced mobile developers will be able to perform such tasks faster and the quality of the results will be better.

The thing with libraries

Knowing how the platforms work may be beneficial during the process of development, even when using libraries.

You can use one of the most popular storage libraries, SharedPreferences, without touching the native code. But it’s much easier when you know what’s happening under the hood of each platform.

If you look at the code underneath the Flutter library, you see it’s built on top of `NSUserDefaults` on iOS and `SharedPreferences` on Android. And thanks to that, you can get to know more about how the storage will actually behave if we clear application data, for example. Such knowledge may turn out useful in the long run and have a large impact on dependency choices during the development.

4. Knowledge of mobile technologies saves you time

The behavior of web apps is mostly unconstrained – a big part of creating them is based on figuring out good UX and applying correct interface design principles. This is completely different for mobile applications. They need to adapt to system behavior and requirements unique for each platform – iOS and Android. That may be an unknown concept for developers coming from outside of the mobile world.

Applications running on smartphones have to:

• respect the system-dependent lifecycle,
• pause and resume current actions when they’re put into the background or restored,
• maintain low battery usage,
• expect that the system can turn them off when they become too power-hungry.

Mobile app developers are familiar with those problems, as they’re present in both native and cross-platform development. So, it’s easier for them to handle all system events.

But people coming from different tech backgrounds may find this difficult to understand. With simple apps, it may not be a big issue, but in more complex cross-platform projects knowing the app lifecycle can save a lot of time.

Platform-dependent components

There are more platform-dependent components that may be difficult to understand without knowledge of iOS and Android. Let’s take location access as an example.

Both platforms require the app to request access to location, and there are multiple Flutter solutions that allow you to do it without touching the native code. But it takes a lot of time to understand those permissions, get to know what parameters to use and how to set everything up, so our app doesn’t get rejected during Google Play or the Apple App Store review process.

5. Sometimes, native code is the only option

Although Flutter handles most of Android and iOS platform configuration by itself, sometimes it’s necessary to alter the way that native apps are built. Let me explain it to you with the Firebase setup.

Configuring Firebase libraries in a Flutter project requires not only changes in Dart code. In some cases, it’s also necessary to make changes in the per-platform configuration of build systems of Android and iOS. For developers coming to Flutter from a web environment, build systems utilized by Android Studio and XCode may be difficult to understand and maintain.

Mobile developers, on the other hand, won’t have too many issues here, because they’re already familiar with Gradle or XCode Build System. Knowing how the native app is built can save a lot of time spent on the development.

It also comes in handy when you’re struggling with dependency problems – developers with Android and iOS experience are often familiar with dependency management systems on their platforms. So, they know how to handle the most common problems with Gradle dependency management or CocoaPods configuration.

In Google’s technology, many elements of the development are designed differently from what web and mobile developers are used to. But it doesn’t really matter, as long as the team is willing to learn Flutter and understands that some things have to be approached with a different mindset. But in the end, when creating mobile apps for iOS and Android, it’s good to have someone who knows those platforms and all the bits and pieces needed to handle the development process.