An enticement for the local iOS and Android developers of the world — there is a better way.

Google’s  Flutter is a mobile application development system that allows you to build applications for iOS and Android quickly. Learn about why is Flutter progressive.

A Little Background

My days of local development go back to Installer where I  first developed a Digital recording application. Over the course of the last ten years, I’ve made many applications for clients like Comcast and Related Press. I’ve been a native developer to the core.

Over the course of my career, I’ve spent a lot of time building custom enterprise programming. These experiences led me from office/provisional work to try to solve a problem… endeavor programming is strangely difficult to construct, convey, and support and terrible to use. I helped to establish AppTree Programming and we set out to make enterprise programming easier.

We set out to build a platform to make it easier for developers to build support and convey enterprise applications. We built mobile clients and SDKs so that your applications could inherit answers for the intricate issues of big business programming from the outset. Our goal is that you’d only have to worry about your particular business logic.

Taking the `native` approach

Because of the idea of big enterprise software, we needed to handle hundreds of thousands of records, work offline, and be very secure. Normally, we wrote our applications locally using iOS and Android SDKs. Every step of the way, I rejected cross-stage systems. They were too slow, the tooling was bad, and your UI actually must be written twice.

While native development provided the final product we wanted, it was a great deal above in both initial coding and ongoing support. Getting the performance and control we wanted with local application clients meant writing everything twice, everything twice, hiring was difficult, and the incorporate times… my god the order times (looking at you Swift). 

I set out to find a language and tooling for our web client that met the demands of our platform and arrived on Dart.

We proceeded to take all the capacity in our mobile applications and build it again in Dart so our clients could run their applications in a browser.

Hitting a wall

Feature development started to drag. Presently we were writing every feature three times. We had three specific groups and as with all startups, we were trying to move quickly. Our general productivity eased back, my time was all spent synchronizing elements and thoughts across groups, architecture started to separate, QA time increased and quality suffered.

As a part of the Dart community, we heard the thunderings of Flutter. Being a native developer for a long time, I had grown a solid suspicion towards cross-platform systems. However, this appeared to be changed. We loved our experience in Dart so far and the approach that the Flutter team was taking to the cross-platform issue felt right.

Our excitement about Flutter developed at the Google Developer Group meetup in Portland regarding the matter of Flutter. Coming out of the meetup, we were intrigued. Flutter felt like it could work for us.

I went to work that night building a show so that I might see where I arrived on the  Flutter question. By the end of this activity, I was convinced that our company should move to Flutter. And we should do it immediately.

Here it is…browser.

The Pitch

My presentation began with the cons of using something like Flutter.

Why we should not use Flutter

• New technology, APIs can change
• No inherent Flutter support for things like Guides, and Camera. Should use local APIs
• No help for Domain. We should reevaluate constant capacity.
• Not much outsider library support. We use Pusher, Mark Catch, Photo editing, etc.

Do the above reasons matter?

• New technology and APIs can change — Not actually, Google has been using inside for creation, there are multiple applications in the application stores. I truly just see them adding missing APIs.
• No built-in Flutter support for things like Maps, and Camera. Should use native APIs — No, We’ve already written these in iOS and Android. That code can be generally re-used by means of a module. See our resulting maps plugin.
• No help for Domain. We should rethink persistent storage — Yes, this matters and it will be a larger part of our work in the rewrite.
• Not much outsider library support. We use Pusher, Signature Photo editing, etc — Like guides, we can write a plugin wrapper around the outsider libraries so they can be used in  Flutter. Which we did here, here, and here.

Why Flutter: The UI Framework

• Modern API. The  Flutter group has worked really hard to concoct an API that addresses our most normal mobile needs all while keeping it highly customizable. 
• Perfectly fits our navigation needs. Additionally allows us to share navigation ideas across the web.
• Open Source
• Reactive Views
• Current and fast tooling
• Does it deliver using Skia? It at last implies that your UI and navigation can be written once and shared across iOS and Android.

 The development cycle

• Android Full Compile — 2:10 sec
• Android Gradual Assemble — 20sec
• iOS Full Compile— 2:40 sec
• iOS Gradual Compile  — 40 sec
• Flutter Full  Compile — 25 seconds. On iOS, this includes building the Dart code, running the pod install, and the xcodebuild order. The results are similar on Android since it uses the Gradle build process.
• Incremental Compile — sub-second on thanks to the amazing hot reload.

 Unit testing

Android Unit Testing

• Great help. Can run on the JVM without Android if you mock
•  Android-specific classes.
•  Compile time 5 sec
•  Run time 1.5 sec

iOS Unit testing

• Can run on the iOS test system. ( There are ways of getting around this         
•  moving non-iOS-dependent code into subsystems, would 
•  have  been a significant re-work for us.)
• Compile time 40-2:40 sec
• Run time 10 sec.

Dart

•  Fantastic help. Simple to specify which tests can run on VM.
• Sub-second compile time
•  Runtime 1 sec.

But of course, the best advantage is we are just writing our tests once.

 Code Sharing

• 95% code reuse across iOS and Android. Our own plugins are the main special case
• 60% code reuse among Flutter and Web.
• Significant architectural changes happen once, not across 3 unique stages.
• Since Flutter is its own UI/Gadget library, we don’t need to manage implementation details of iOS and Android (ie. Android Action, Parts, message passing and etc.)

 QA Testing

• Very high confidence that tests of iOS will be valid for Android & Web.
• Specific Platform QA can be limited to when native components are used
• 50% reduction in QA time

 Team Scalability

• A lot more straightforward to hire. We presently look to take the best candidate regardless if they are from Web, iOS, or Android.
• We have 3x the transfer speed now that our groups are all solidified on a  single code base.
• Information sharing is at an all-time high

Giving it a go

Having sold myself on Flutter, I gave a similar show to my CEO. He was likewise convinced. I then, at that point, gave the show to the group and got everybody in total agreement.

The best way to let us know if this would really work for us is to try it. We set a multi-week cutoff time to perceive how far we could get with flutter.

In the span of three weeks, we had a working prototype application client. We were able to do it quickly due to the huge amount of code we were able to share from our Dart web client project.

To give some point of view, our Android application assumed control for north of a year to write after our iOS application was already done.

Not only is this since there is just a lot of code to write, but you also have to find the right people to finish up a group and then train them on the complexities of your item. That’s it. Presently we are one group and adding another part can be a significantly more incremental process.

Likewise, instead of dividing our abilities among three unmistakable stages, we zeroed in on colleagues’ on various parts of Shudder; UI, engineering, and modules.

Our productivity on new feature improvement has generally significantly increased. Here’s why: 

Besides the fact that we have the obvious gains from having just a single code base between iOS and Android, we can share ~70% (right now as of this writing it’s 67%) of our web client code with the mobile clients. 

But, it doesn’t end there. At the point when we test a feature in any of the stages, except if it’s a stage-specific UI change, we are really trying across every one of the three stages immediately. We didn’t expect this addition, but entirely it’s genuine and it’s huge. 

We also found that since we were able to merge what was a divided group into one group with a common skill set, we invest less energy being blocked by one another and can all the more easily cooperate. What’s more, truly, we are happier. 

While it’s enjoyable to build a new feature, it turns into an errand to then need to recreate it two more times. Then I need to write the stage-specific unit tests. Then, at that point, QA did exactly the same thing again.

Mobile improvement is fun again.

conclusion

Essentially, Flutter is the speediest method for conveying a well-performing cross-stage versatile application. I can clearly tell that it’s simply a question of time when Flutter will formally turn into a definitive cross-stage UI structure.