What It Was Like to Write a Full Blown Flutter App
1. Porting an iOS App to Flutter
Since my last post about Flutter months ago, I felt that the logical next step was to really really get in depth with Flutter. I’m huge fan of tutorials with battle tested, end to end examples (think Digital Ocean or even Auth0 tutorials). End to end, detailed, high quality examples are what made me get hooked on new technologies in the past because I was able to really see near-production ready code and feel secure that I was implementing things the right way. So I wanted to do the same writing Flutter tutorials.
So with those goals, I decided that the perfect app to cut my teeth on was to simply re-write an existing iOS app that I already had in the App Store. Steady Calendar (homepage, Product Hunt), is a habit tracker that my wife Irina and I designed and developed while we were living Berlin a few years ago. Since then, it has been a product that made us hooked on how satisfying it was to design, implement and release a product that helps others improve their lives by adopting healthy habits.
2. Thoughts on Flutter Thus Far
Although I’ve been writing backends and webapps for more than 17 years now, 4 of those years were heavily involved with iOS development and as of the past year at work I’ve needed to ramp up with React Native heavily (throw in a few React projects last year too).
- The developer experience, support and community spirit is amazing. Everything from Stack Overflow, Google Groups to blog posts are high quality naturally because of the enthusiasm for Flutter. Google Engineers go out of their way to stay heavily involved in answering question on Google Groups and this makes for a great community. They’re super polite and professional when working with engineers from all backgrounds, something that’s hard to say for a lot of other companies out there. There’s also a lively community where members are super active and provide really thoughtful answers. Documentation is fantastic. The libraries are very stable and with Flutter being based on Dart, a language that’s been around for years, learning is very easy as it is more established and battle tested. All around, great developer experience.
- As expected, there there is less availability of third party libraries written in Dart. Yet these are not deal breakers, at least in my experience. 95% of the features I’ve needed to use were there and available, just one exception was say, some third party integration with a popular analytics tool but nothing that a simple HTTP wrapper couldn’t take care of.
- Material Design widgets, something that the Flutter framework is heavily comprised of, is great for cranking out simple apps yet for professional, cross-platform apps, it will alienate iOS users. I cannot present Material Design widgets to my iOS users because it would make my app look alien to them. Flutter does indeed provide its own set of iOS widgets, but these still have a way to go in terms of comprehensiveness. Luckily, with the Steady app I wrote, most of the UI was already custom. But for things like forms, that was more of a challenge. So at the end of the day, the documentation, examples and overallFlutter SDK is heavily oriented around Material Design which is great but there needs to be more of a balance for folks like me.
- Developing custom UIs in Flutter was a breeze. I have high standards too after being spoiled by leaning CocoaTouch / iOS back in the day. After diving through lots of Flutter code and judging by the experience of writing customer UIs, the Google team really has their act together. Sure, there are some widgets I really think are super overkill and can make the learning curve a bit more convoluted (i.e. the Center widget), but it’s not a huge deal. After writing a real app one quickly starts to see a pattern of what the most critical widgets they’d probably be using on a regular basis (and hey, I’ll be covering that in my future tutorials).
- As an iOS user, taking a few months to write my original iOS app Steady Calendar, I’ll never forget the sheer excitement of running it for the first time on a physical Android device. I guess it’s just because I always was super turned off by other cross platform mobile frameworks. If you take months of your spare time, lots of hard work developing something and realize you can run it on two major platforms, you will get hooked. This is probably not very insightful feedback for most people but I needed to share it anyway!
- Writing cross platform apps will throw more design challenges your way but this hasn’t really anything to do with Flutter itself but more to do with getting into development for multiple platforms. When you plan out a Flutter app, make sure you have a good designer and a nice custom UI mocked up or be ready to write your Flutter app so that your code conditionally uses either Material Design or Cupertino widgets. In the former case though, this is less of a Flutter issue and more of a challenge writing cross platform apps, you need to make sure the UI is designed to be good looking for Android users and iOS users based on the conventions they are each used to.
- Dart is a pure pleasure to learn and use. I love the stability and reliability I get vs using something like TypeScript or Flow. To put this into context, I have a bit of a React background and have been learning React Native heavily for my day job (heavily) for the past few months. I’ve also worked a lot with Objective-C and then Swift for years. Dart is a breath of fresh air because it doesn’t try to be overly complex and has a solid core library and packages. Honestly, I think even high school freshmen can use Dart for basic programming. I just can’t believe how many I hear complaining they’d have to learn a new language, which for Dart would take between one or two hours or a day max.
- Flutter rocks. It’s not perfect by any means, but in my own opinion, the learning curve, ease of use, tools available make it by far a nicer experience than other mobile frameworks I’ve used in the past.
What Google Should Do
- Google team members and friends should to continue to provide thoughtful, friendly and responsive support in its Google Groups. This is a big plus and is what makes the framework standout in terms of approachability and support. The team supporting and cultivating the community are really likable guys and have a good, positive attitude and that’s huge.
- Get a poll from community members to see which Widgets may simply not be useful. For the not so useful Widgets, just remove them from documentation tutorials or deprecate them altogether. For example, the ‘Center’ widget is nice for a Hello, World container but I never understood it. Why can’t ‘Container’, something that’s way more prevalent have a property to do the same thing? This is a super trivial example but I think that’s part of the reason why Go was so successful, because it’s core library was simple and lean (and stayed lean).
- Devote more focus on iOS users. Material Design is great to get going quickly or if you’re only building something for Android users. I’d never use Material Design in an iOS app. With that said, I’ve found Flutter to be a nicer, less complex developer experience than learning Swift and all the one million library features one has to know to write iOS apps nowdays. I think a lot of iOS users would love to learn Flutter if Flutter had just even a bit more iOS style widgets.
- More tutorials on building realistic features and screens. I’d love to see more tutorials like this one: https://flutter.io/get-started/codelab/ but also “end to end” ones, where an example of integration with a backend is shown.
- Theming apps should be less focused on Material Design. Again, I don’t want to use the ‘MaterialApp’ widget if I’m writing an iOS app. Theming seems tightly coupled to this and it should be more generic.
- Less prevalence of Firebase in the documentation or pushing it so often. I realize Firebase really useful to get going fast and it helps bolster the approachability for new developers, but a significant amount of folks out there already have a backend ready or would not ever consider using Firebase. So I think more emphasis on how to work with simple web services and JSON would help. I had to read a lot of third party tutorials on this because I felt the documentation wasn’t realistic enough. I can elaborate when I write a future blog post about this.