University-level computer science courses had a strong theoretical feel to them and little practical application. At the time, I had an Android smartphone, so it was a simple choice to consider creating an app for it.
It was a very rocky beginning. This was primarily due to the poor technical solutions that were available for creating an Android app, not my lack of programming expertise. Eclipse with a problematic Android plugin that broke after each straightforward update was an option, or you could try using an even more problematic early version of Android studio.
I chose to port one of my apps to iOS after it had some success on Android. I had never used Xcode before. Compared to Eclipse + plugin/Android studio, Xcode felt a lot faster and better at this point. While working on my first iOS app Apple released the auto layout feature. I didn’t use it cause there were bugs in it and the documentation was, may we say, not that clear.
As you can see I had to create two completely different apps on completely different platforms. On Android, I had to use Java and on iOS, there was Objective C. Despite the fact that my apps didn’t make extensive use of system features there were no good options for cross-platform development. I took a look into PhoneGap (today known as Cordova) but decided not to use it. React Native was not available in 2014.
Because of better success on Android As I spent most of my time working on Android, I didn’t think about cross-platform development. I was employed by a small communications business after earning my university degree. The business offered iOS and Android (native) apps. Each feature/bug had to be developed/fixed on both platforms. To fix this waste of resources we were testing Kotlin multiplatform to share „logic“ code between iOS and Android. We also tried to use Swift to share code with Android but this feature wasn’t/ isn’t officially supported. There was another problem with this approach, you still have to create your views on both platforms. This was the time I first looked into Flutter.
Recreate existing views with Flutter, SwiftUI, and Jetpack Compose:
To test Flutter a little bit I recreated some of the views of the company apps with Flutter, SwiftUI, and Jetpack Compose (Alpha/Beta at this time. Middle/End 2020).
|Good||– IDE (JetBrains know how to make good IDEs)||– Good documentation||—|
|Bad||– Too many state management approaches (BLoC, GetIt, Redux, Provider, Stacked, GetX…)|
– Dart (missing a lot of modern features)
|– Awful IDE (Xcode was much ahead, but in comparison to modern IDEs it feels like using a typewriter. It is slow and buggy and is missing a lot of features)||– was not usable|
(Alpha version –> slow and buggy)
Flutter is a game-changer. IMO every company that wants to develop mobile apps or has already mobile apps should look into it. I converted one of my old applications to Flutter and the cross-platform approach is working for me in 95 % of the cases. In some cases, there is an exception on iOS or Android, but I could quickly fix it. So most of the time I didn’t have to use „bad“ old Xcode. For sure some things are not (yet?) that great in Flutter (Dart could have more modern features like Swift or Kotlin, the state management options are confusing, build sizes bigger than native builds, lack of experts in Flutter), I had a great overall experience with Flutter, and if it had been available in 2014, I would have used it.
The next thing I want to try with Flutter is to create a cross-platform application for Web, Windows, Mac, and mobile. I am curious if it is also that easy to create software for all of them and reuse most of the code.
See you at work.