Skip to content

Flutter vs. Native iOS Development

Hey, it’s Tom! I already talked about the pros and cons of Flutter from a perspective of an iOS Developer, but I didn’t compare it directly with native iOS SDK. I think it’s worth doing this, so let’s start 🙂

At first, it’s worth to compare languages, they are an essential part of development either in Flutter or iOS SDK. Objective-C is rather a domain of old, long-term projects, so we will compare only Dart and Swift. In the case of learning, both Apple and Google provide tons of tutorials, code samples, and videos. You can learn both of them for free and the learning curve seems very similar in my opinion, it’s pretty easy to quickly learn enough basics and use this knowledge and build your first project. I would say that in the case of learning there is a draw.

However, things get different when you play with both frameworks a little bit more. It’s easy to notice that Dart, even it was released 3 years before Swift, is definitely less mature, probably because it wasn’t so popular for most of its life. A good example might be null safety in Dart, which was added just a few months ago, same with generics. A thing that annoys me the most and one that I find really dangerous is a very common usage of dynamic type, which is really error-prone. It’s good to see that version 2 of Dart added generics, null safety and enforces more static typing discipline, but still, it’s far behind Swift in the case of everyday work convenience, and security of written code. In my opinion, Swift wins as a more mature, safer, and simply easier to use language, not only because of semicolons ;).

During development, we rarely write the whole app from scratch, either we have to use some external SDK, or we just need to import some library that handles some logic and saves our development time. In this case, it’s worth checking how many 3rd party libraries the community created. In the case of SDKs, Google is of course supporting Flutter, so Google Maps, Firebase, Google Analytics, all that stuff from Google offers SDK that works with Flutter. As Flutter gets popular more and more companies also offer dedicated SDK, like for example OneSignal or AWS. On the other hand, there are still many big and popular tools, that doesn’t offer dedicated SDK and we have to use API wrappers created by independent developers. Mixpanel might be a good example. Please keep that in mind because using this kind of wrapper means that at some point you might be forced to maintain this code on your own, that’s always the risk of using libraries written by single developers. iOS SDK is much longer on the market and as a result, there are obviously way more SDKs and popular libraries available for this framework, it could change in the future, but as for now Native iOS Development definitely wins this category.

Another important part of everyday work is an IDE. Writing native iOS apps means we have to deal with XCode, which is getting better and better every year, but it’s not the easiest tool to learn and use, I really like it, but I’m also aware that a lot of people hate it and there are many reasons why you also might not be a big fan of it. Things look different in the case of Flutter, as you can use Android Studio, Visual Studio Code, or IntelliJ, depending on where do you come from, you can still use your favorite IDE and this is a huge benefit. In the case of IDE Flutter wins without any problem.

We talked about IDE, so let’s talk about time needed to actually see the results of our development. In case of clean build, native project compiles way faster than the one written in Flutter, but when we do some small changes and need incremental build there is not much difference anymore. However… Flutter has an ace up his sleeve, it’s hot reload, small incremental changes are immediately visible on simulator and it improves developer productivity a lot. In case of iOS SDK we have to create a new build every single time we want to test our changes. Of course there is Swift Playground to play with the code and there is SwiftUI which also offers hot reload, but in case of bigger apps using Swift Playground is usually impossible and not efficient at all and SwiftUI is not very popular yet, most of commercial projects still use UIKit. In this category Flutter wins thanks to hot reload, which is simply cool feature and makes development faster.

Ok, so we’ve finally developed our simple, multiplatform app and we want to deliver it, we create the final build, and… you might be surprised by the size of the app written in Flutter… It won’t be smaller than about 5 megabytes even if it has no assets and only 1 blank screen. There is a reason for that, apps written in Flutter are not native as some might think, they have to be delivered with an own engine, because of that there is a minimum size of the app. In the case of native iOS SDK, there is absolutely no problem to deliver apps smaller than 1 megabyte, as long as there are no 3rd party frameworks and big assets. This is worth taking into consideration, as in some conditions you might want to deliver as small app as possible and with Flutter it’s simply impossible. Of course, the more assets and additional frameworks you put into the app the smaller gets the difference, but in the case of app size native SDK wins.

So we built and released our lovely app and now it’s time to see how good it is, let talk about performance. I have my personal observations, but I planned to do some dedicated testing, however, to not reinvent the wheel I checked if there are maybe some official benchmarks done by Google or the community and I’ve found that someone already did a great comparison and there is absolutely no point to repeat the whole experiment. Link to this post will be in the description of this video, so no worries, but for those who don’t like reading I will quickly summarize it. In most cases, there is absolutely no noticeable difference between native app and the one written in Flutter. You may notice the way better performance of the native app while handling multiple sophisticated animations, but let’s be honest, it’s cornercase. I think that in this category there is a draw, native SDK offers better performance, but for most cases, user will not notice it at all.

Ok, I think we compared the most important parts of both Flutter and Native iOS SDK, so it’s definitely time to sum it up. Flutter popularity is still growing and there are many reasons for that, it’s performance nearly matches the native one, it’s easy to learn, the community is huge, and is constantly creating tons of new widgets, libraries, and tutorials. So should you stop learning Swift and focus on Dart? Definitely not. As I mentioned in my previous video, Flutter is a great tool to rapidly prototype MVP, or build a simple app, that mostly consumes REST API. It might be also an awesome solution if you have to deliver the app ASAP to get more time to work on a more polished native solution. However, if you want to build something more sophisticated, native is still the way to go, it offers more control over the device, more 3rd party libraries, more SDKs, and better performance, at least in some cases. Last but not least, both Swift and iOS SDK are definitely more mature and the more you work with both frameworks the more you see it. Native iOS Developers… don’t be afraid 😉

Ok, I hope this post helped you, if you agree or disagree with my insights feel free to let me know in the comment section below. You can watch the video version of this blogpost on my Youtube Channel:

Leave a Reply

Your email address will not be published. Required fields are marked *