Creative technology
is constantly evolving.
There is always
a new
way
of solving an
old problem
and in some cases
significantly simplifying
the solution.
@dwyl we periodically ask ourselves the question:
If I was starting my journey from scratch now
what tech would I learn/use?
If we could keep all the knowledge/wisdom and experience gained over 20+ years of programming but avoid any preconceptions and biases i.e. "sunk cost bias". Would we still choose the tech/tools we are currently using? Or would we pick something else completely different?
The people/teams/organisations that can objectively question why they use particular tech/tools can take advantage of all the advancements being made in the wider developer community.
The question we need to ask/answer before diving into any discussion of which technology/language/framework we should or shouldn't use is: What are problem are we trying to solve?
The last time we (informally) looked at Flutter
in early 2018,
it did not meet all our needs for a UI framework.
At the time, it was focussed on Android,
didn't support Web/PWAs
and only had partial/beta support for IOs.
In the last couple of years Flutter
has seen rapid
development both from the army of Google Developers
and the thriving community and it has matured considerably.
It excels at all of our requirements.
Google is using Flutter
for several of their cross-platform Native Mobile Apps
including Google Adds (their main money maker)
and Google Pay their popular global payments platform.
See:
flutter.dev/showcase
There are thousands more examples and more each day!
It's almost certain that you are already using an App on your Smart Phone
that was built with Flutter
whether you know it or not.
For a community list of Apps built with Flutter
including many Open Source ones, see:
itsallwidgets.com
Flutter is mobile first, has full/official support for Web/PWAs using the same code base as the Native Mobile and Desktop Apps.
Targetting all these platforms
with a single codebase
is a compelling proposition
and it's only getting better!
See:
medium.com/flutter/whats-new-in-flutter-3-8c74a5bc32d0
Google is investing heavily in Flutter, it's used for the Google Assistant, Google Ads and Stadia!
Returning to the @dwyl
guiding principals for technology selection
outlined in the README.md
We can see that Flutter
meets all of them:
- 1. Security: advanced security features: https://flutter.dev/security
- 2. Accessibility: Support for screen readers, high contrast and large fonts: https://flutter.dev/docs/development/accessibility-and-localization/accessibility
- 3. Open Source: Flutter was initially developed by Google but has since been spun out into an independent GitHub Org. Google still handles security reporting and that's a good thing because you know someone at Google is responsible for acting fast when a security report is made.
- 4. People Centric: the fact that it can ship to any device/platform makes it very people-centric because the UX will great no matter where the person is using it.
- Gorgeous Native User Interaction including built-in support for gestures, voice, transitions and animations. These might feel like "nice to have" but some people really love these micro-interactions.
- Native performance up to 120fps means buttery smooth UI anywhere (where there is a display with a sufficiently high refresh rate) because of the Dart compiler.
- 5. Mobile First: the first platform Flutter targeted was (Native) Android. Flutter is still predominantly used for Mobile UI but it can be used to build Desktop, Google Assistant, Web Apps and "Ambient Computing"! See: https://flutter.dev/showcase and https://youtu.be/NfNdXgJZfFo?t=884
- 6. Responsive: The Flutter UI framework is designed to work on any screen size without the Dev(s) having to jump through hoops to check the device width/height and debug random screen sizes! see: https://flutter.dev/docs/development/ui/layout/responsive
- 7. Offline First: SQLite https://flutter.dev/docs/cookbook/persistence/sqlite
- 8. Developer Effectiveness
- 9. Internationalisation: Flutter has been built for internationalisation from the start: https://flutter.dev/docs/development/accessibility-and-localization/internationalization
- 10. Custom UI: with Material Theming, Devs/Designers can have full control over the UI see: youtube.com/watch?v=NfNdXgJZfFo
As noted in the main README.md
,
we are using
Elixir
+ Phoenix
+ PostgreSQL
for the Web App.
By using LiveView
, Tailwind
and Alpine.js
(AKA the PETAL
stack)
to build features as a Web App first
we iterate fast
and maintain full control over
SEO
.
Once the feature is built for the Web
fast-loading and SEO-friendly HTML
,
we will port the feature to
Dart
+
Flutter
for a cross-platform offline-first native exeperience.
Dart
is a strongly typed object oriented
general purpose programming language.
It is the language used to build Flutter
Apps.
https://dart.dev/
If you know any JavaScript
(ES6
)
and TypeScript
then you will feel at home in Dart
More detail in: https://github.com/dwyl/learn-dart
We are recording our learning of Flutter
in:
dwyl/learn-flutter
All the practical detail is there.
We are building our App:
dwyl/app.
We selected Phoenix
for the Backend
because we find Elixir
easy to read, reason about and write.
(far more so than other major programming languages).
More detail in:
learn-elixir/issues/102
The data we are storing is relational in nature.
We are creating items
of text
that have an unlimited length.
We want to apply meta data to those items
and create rich interactions around them.
We will have many useful features in the App
but the core will be items
, timers
, lists
and people
.
As a small team with finite resources
(and no desire to "raise" money from outside investors),
we want to maximise our efforts
to build the App that most people want/need.
We are focussing on building the Web App initially
because the web is universally accessible.
Many companies have focussed their initial efforts on iOS
because it's the easiest platform to target,
iOS
users have more disposable income
and are more likely to pay for apps.
"Making an App for
iOS
is Faster and Less Expensive". "Android
users tend to be less willing to pay for apps thaniOS
users, so free apps with in-app ads are more common." https://medium.com/@the_manifest/android-vs-ios-which-platform-to-build-your-app-for-first-22ea8996abe1 There are fewer iOS devices to target and test on which dramatically shortens dev timelines. e.g in 2022 there are only 7 supported screen sizes for iPhone:
- 4" - iPhone 5S and SE (old screen size but still used by tens of millions people)
- 4.7" - iPhone 6, 7, 8 and SE 2020 & 2022
- 5.42" - iPhone 12 & 13 Mini
- 5.5" iPhone 6 Plus, 7 Plus and 8 Plus
- 5.85" - iPhone X, XS and 11 Pro
- 6.06" - iPhone XR, iPhone 11, 12 & 13 Pro
- 6.46" - iPhone XS Max and iPhone 11, 12, 13 Pro Max See: https://en.wikipedia.org/wiki/List_of_iOS_devices The full device feature compatibility matrix is lets developers see exactly what features are available for all iOS devices (including all iPads): https://developer.apple.com/library/archive/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/Displays/Displays.html
In 2015 there were already "more than 24,000 different
Android
devices from 1300 brands" https://www.zdnet.com/article/android-fragmentation-there-are-now-24000-devices-from-1300-brands That was before the explosion of new devices from Chinese and manufacturers. In 2022 there is no official stat for the number of devices or screen sizes (because Google is painfully aware of the fragmentation problem but doesn't want to surface it!) suffice to say that it's several orders of magnitude more complex to build an Android App that looks consistently good across all devices. Android development is considerably more complex, which is why devs preferiOS
for their MVP.
Flutter was first included in the 2020 dev survey and was the 3rd "most loved" framework: https://insights.stackoverflow.com/survey/2020#technology-most-loved
In the 2022 survey Flutter
has overtaken React Native
in popularity:
https://survey.stackoverflow.co/2022/#section-most-popular-technologies-other-frameworks-and-libraries