Flutter is the cross-platform framework for iOS and Android development.  It uses the Dart language. The installation process involves few steps to run flutter on macOS. If you want install only the Dart you can go to the Installing Dart language part.

Installing Flutter on macOS

Before installation make sure you have download Xcode or Android Studio. It depends what you want to use for the development. The official guide of installation macOS is here.

Here are several steps to install the Flutter:

1. Download the stable version of Flutter

2. Make the folder where binaries would be located. You can use development folder

mkdir ~/development && cd ~/development

3. Unzip folder:

unzip ~/Downloads/flutter_macos_v1.2.1-stable.zip

4. Update the path to enable flutter in the Terminal

export PATH="$PATH:pwd/flutter/bin"

To add this Flutter permanently to the path, go next:

4.1 For Bash

Open or create .bash_profile:

vi .bash_profile

And change [PATH_TO_FLUTTER_GIT_DIRECTORY]to the path you've chosen, e.g. development folder:

export PATH="$PATH:[PATH_TO_FLUTTER_GIT_DIRECTORY]/flutter/bin"

Example path:

export PATH="$PATH:/Users/yuri/development/flutter/bin"

Refresh bash profile:

source $HOME/.bash_profile

and finally, check it out with Terminal command flutter

5. Run flutter doctor in the terminal to get the current installation status

It shows now the current situation with installation. You just need to follow the instructions.

The brew is needed to install the tools for simulator. You can download it here.

The Visual Studio Code is the main IDE for Flutter along with the Dart extensionfor enabling all cool features such as hot reload.

After sorting out the iOS, Android, VS code setup you can check it again with:

flutter doctor

So far the installation process involves quite few steps. But the good thing that the setup can be easily checked and Flutter itself produces code for many platform. So it is worth its installation time.

Installing Dart language

Flutter itself contains Dart environment so this is a part where you want install only Dart. So let's install and play with it.

Installing the Dart language:

brew tap dart-lang/dart
brew install dart

Then you can start access the Dart SDK via command line.

Create a simple dart script using script.dart extension:

void main() {
  for (int i = 0; i < 5; i++) {
    print('hello, world ${i + 1}');
  }
}

Though Dart is not classical scripting language as Python, it can be used via the command line.

For accessing the arguments a programmer would need a library so it is not that handy.

The better approach to play with the language is DartPad . Where you can REPL read-eval-print loop over the code. It is a similar to Playgrounds on Xcode.

Cross-platform application development is one of the biggest issues when it comes to the creation and support of mobile applications. The cost of development is investment along with a support of the product. If iOS and Android applications share the code the business can cut the costs significantly. That's why there are many cross-platform frameworks. One of them is React Native (RN) open-sourced and developed by Facebook. At the moment it is one of the most performant, stable and developed tool.

In some cases, React Native is a reasonable investment in a technology and a product basis. The further analysis will reveal the pros and cons of the framework.

Pros: Native and Cross-platform

The first advantage is the cross-platform approach out-of-the-box. "Write once, run everywhere" (on iOS and Android and possibly Web). The web developers can quickly learn the framework especially with the knowledge of JavaScript and React. The contribution to the mobile project can increase significantly.

One layout system for iOS and Android - JSX and Flexbox (link, link) let you develop a unified user interface for both platforms. It is much easy to read and maintain than native code. It supports styling straight-away and validates the JSX layout schema on the fly.

Pros: Quick prototyping and a velocity of development

You might be an iOS, Android dev or Web developer and know your platform and frameworks on the highest level. But this limits you only to the one platform.

The React Native provides one experience with the layout system and routing between screens or components. Doing the development in one unified layout system such as JSX increases velocity and add a coherent approach to support the app.

Any change developer makes rendered instantly with a help of Hot reloading (another link). In contrast with native development, you don't need to rebuild the project to see the changes to the styling or the business logic of the app. Though Android has Instant Run feature, it is limited to the one platform and should be maintained and setup but the React Native works just from the start.

Pros: React Native has high performance

Using RN allows you to create any kind of application with fully native experience. The cross-platform code is written on JavaScript or TypeScrint and platform specific parts can be done with Native Modules. A developer can call any iOS and Android API or create a custom UI with simple class creation.

Native Modules iOS, Native UI components iOS,

Native Modules Android, Native UI Components Android.

The React Native is a real native framework. It uses JavaScriptCore framework which is thread-safe and leverages the speed of execution by providing the multi-threaded environment. In contrast with WebView based frameworks such as Ionic or PhoneGap where all elements are rendered in the web view and blocking the main thread of the application.

And all developers know that nothing should block the main thread except UI rendering. The RN can provide the ideal rate of 60 FPM (frames per second). Which is unbeatable by WebView rendering.

The React Native internal architecture uses the JavaScriptCore and Native Modules. So the code written on JavaScript or TypeScript is translated to the native code with existing React Native components or Native Modules.

As JavaScriptCore can execute code on the background threads this gives a boost to the performance and the application is almost the same performant as the native one.

Pros/Cons: The learning curve is short and high in different cases.

I would say React is a quite easy-to-learn framework with JSX, Flexbox if you are familiar with React web development in contrary with iOS SDK and Android where there a lot of different implementation cases and layout systems on iOS (e.g. XIB, Storyboard, and coded UI).

On the other hand, a developer would need to know the iOS and Android basics like an Xcode project structure or Gradle and Groovy for Android. This skill will be useful from time to time to setup the project, and a web developer can get a side help from a mobile developer or learn it with tutorials.

Pros: the ease of development

Since we have one entry point to the iOS and Android project and JSX as the JavaScript syntax for UI layout it simplifies a developers job a lot. One tool for everything. And in some cases, the shared code can be more than 90 percent.

For example, the creation of the project is a quite simple process using NPM tooling. Assume that we want to create an app named ReactBasicApp.

First, install create-react-native-app tool:

sudo npm install -g create-react-native-app

Then create a project:

create-react-native-app ReactBasicApp
cd ReactBasicApp
npm start

These commands have created two applications iOS and Android and the React app itself.

The first running  application is basically in one file App.js:

import React from 'react';
import { StyleSheet, Text, View } from 'react-native';

export default class App extends React.Component {
  render() {
    return (
      	<View>
            <Text>
        	The react basic application
	        Hello, world!
            </Text>
        </View>
      
    );
  }
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
});

The styles are created with StyleSheet and the whole screen is rendered in the render function. It is a most simplistic variant of the app but it shows that concept can be perceived with one look at the code.

Pros: open-source by default

The RN is fully open-sourced and supports the MIT license (link). It is supported by Facebook and implies a lot of factors for further development. The community can pick up the development of the framework. Being open-source from the start is the main reason for the good adoption. I personally using mostly open-source tools and if there are a couple of products the open-source is better because of open code and possible support of projects.

Cons: too many configurations and dependencies

Adding a library to the React Native project can be painful because it requires the support of both iOS, Android and React Native projects. It is three projects to setup and maintain.

For example iOS, the app will support Cocoapods for dependency management. These commands will install a library NPM library, iOS, and Android library and link it to the project:
npm install
react-native link

Most of the libraries have cross-dependancy and sometimes a developer needs to fix build issues linking additional dependent frameworks or fixing headers path.

This is a trade-off of shipping the app into the many platforms and once you setup a project with libraries you have everything running.

Cons: too many tools.

The cross-platform imply using native frameworks. So you need to know basics of iOS and/or Android development along with tooling such as Xcode and/or Android Studio, the build process, Google Store and Apple App Store submission, the Cocoapods for iOS and Gradle for Android. Too many things you can say. Yes, you're right. Whether you acquire the knowledge in process of development or you are already a mobile developer.

Cons: Young community

Te Facebook confirms its commitment towards React Native (an article). The RN is the quite a new technology. It requires time to answer, resolve issues on Github, follow the roadmap.
Some code and integration with native API would need to be written from the scratch in contrast with native development where most of the components are already written.

The growing pains are natural and it is already addressed by the community.

Cons: unexpected issues

When using React Native a developer would integrate a numerous number of JavaScript and native libraries. Some libraries are well sustained and some are new, there even fraudulent software which is not audited yet.
So awareness is a key to user React Native libraries. A developer can check the source code and the dependencies it brings. This practice can be applied to any other software platforms.

Conclusion

The implication of using young technologies would need additional time debugging or research on Github or StackOverflow community but it comes with a growth and maturing of the tool.

The React Native is a robust framework to build cross-platform applications. It can reduce development time and people resources. Basically, one developer does 2 applications and this is a real investment because a development process and support are very consuming expenses of businesses.]]></content:encoded>

Applications are ubiquitous. People use mobile applications every day, even they are not installing it on the phone. The development of any piece of software requires a lot of resources, man-hours, coffee, and meetings.

Reliability, scalability, and maintainability are ways to secure your investments into the development counting each dollar spent. But how the architecture of the application and well-designed code differs from conversion, marketing or any product development? These factors influence a speed of development, fast iterations, and validations of features and prototypes and thus, directly improve conversion and e-commerce metrics.

In case of the app development, there can be a situation when stakeholders think about the app working on a handheld device as a small thing. And sometimes the support of application or maintainability is not considered as an aspect of requirements and implementation.

What is mobile applications scalability and maintainability? I see it in two dimensions: a scale of the app usage by handling any possible number of users, events, client-backend services, and scale in the development (maintainability) by allowing developer deliver fast and robust features with minimum interaction with the legacy code.

The scalability of the app refers to handling any number of connections from user side, backend API interaction, error-handling. The maintainability is a way to iterate on software product by adding a new feature of fixing bugs in an efficient way.

One of the definitions of legacy as the code is any code which was written in the past even a minute ago. The scalable approach or architecture ideally allows adding a new feature and changing existing ones with minimum efforts.

In my experience, all projects where maintainability and architecture were first-class citizens the changes to the codebase and adding a feature were the seamless process because the legacy was a minimum part and extensibility was a goal.

Note: there are many types of architectures, the present ones are working, the new ones will be better but every approach is suitable as long as it gives a room for scaling and maintainability.

The point of architecture is the definition of scalability in all stages of development whether it is a kickstart or support.

The code is an investment and it is supposed to make a profit or be useful for non-profits needs. So knowledge of architectures is beneficial from the Return on investment side and the ability to extend, support, and modify is the key for successful software product.

The ability to iterate quickly on the product development is key part of the return of investments. By making an extensible architecture gives a way to produce product and receive feedback instantly.

So how we invest in architecture? Is there any way to secure our code for extensibility?

The first step is architecture becoming a contract between developers. No matter what architecture VIPER, MVC, MVVM since most developers of a project are working in the same coding architecture.

The example of maintainability lies in the basics of software architecture. One of the SOLID rules is Open/Close principle states:

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

One example is the CLEAN architecture for Android which gives basic rules of separation of responsibilities and boundaries for each level. Having boundaries and clear responsibilities among classes is always beneficial for scaling. It is widely used in Android development although I believe it is highly applicable to any other platform such iOS.

The example of CLEAN architecture:

Presentation layer: model view, presenters, controllers

UI layer: views

DB layer: repository or data access objects

Domain layer: use cases, business logic

An example of “clean” architecture is VIPER for iOS application. As stated from the acronym:

V: View layers that defines a user interface.
I: Interactor or Domain layer: use cases, business logic.
P: Presenter prepares views and processes user input or events. The analog: presentation layer or ModelView.
E: Entity. The same as CLEAN, it is the data layer
R: Routing manages navigation logic in the app.

The reader can notice the very similar structure in layers of iOS and Android modules. They come from using the same Clean architecture patterns.

The architectures or the app modular structure can evolve as well with ongoing changes as changing DB layer from one pattern to another. And it is a natural way of iteration for refactoring. The persistence layer can have Data Access Object pattern changed to the Repository. In my opinion, it would be beneficial to the project when a product owner would participate in this type of change, no matter if it is technical or commercial one. The architecture is still a part of a product.

The key issue is opinions of roles and neglect of the maintainability from the management and product side. In some situations, the management wants a quick minimum viable product then realizing that extension takes a place. And some development fails but not being able to iterate fast.

The agile development starts with iteration and adapting to requirements and feedback from a customer or users from one hand, and being able to iterate with a given codebase from another.

Here comes some math. We can define a feature of the product as b - time needed for feature development, the sprint as a set of features Σ b, where a ( a ≥ 1) is a complexity factor, t ( t ≥ 0 ) is time for adjusting feature to the architecture, with next formulae:

Using defined architecture with defined module structure helps to reduce a time for adjusting architecture to zero and set the complexity to the minimum. If we consider the most optimal variant where the architecture is well defined we have the next simplified definition:

So knowing how to iterate on a project adding modules with a minimum change of architecture helps to understand the development time and improve life in a planning perspective.

The conclusion here is simple. A team who want to iterate fast can use one bespoken architecture and use it until stakeholders feel it is enough for quick iterations. To simplify, each iteration has the number of features per sprint in the agile environment. When a team sticks to the architecture which fits current needs and gives enough room for iteration the process becomes easier.