I was playing around with some UI frameworks to develop some hobby projects. I wanted to publicize my logs and thoughts.
On Reactivity
When I last coded something, I was using controller methods to alter UI elements. When I became aware of Reactive frameworks thanks to SwiftUI, it was like a magic wand to control things, in simplest words, a reactive framework makes the UI react to your changes, instead of dictating the change to the UI. You’re just setting the change = state of the app. We’re using more resources to manage it, but nowadays computers and phones are powerful.
On Component-Based Development: Design Systems
As humans, we’re good at taking one step at a time. When we’re dealing with complex problems without an approach things start to become overwhelming. The best practice is dividing. So for frontend development.
Establishing a design system seems like an important investment for me. Whenever I hear people, they cannot invest in accessibility topics, I usually ask whether they have a design system or not. If their product derives its view from components, their effort would be 4-5 lines of code correction or addition per component. So investing in accessibility is not an additional effort, but creating consistency is. Today it’s not a question of how to achieve accessibility, it will be an always remaining question of how to invest in consistency.
Astro, Hugo, and React
When I started a static page project for my friend, I downloaded a theme developed with Astro, within a few hours I loved the experience of Astro. And I feel like Young Sheldon’s first computer experience.
I was using Hugo for my website, and I used React before. (and I’m not counting other frameworks I didn’t develop something went online) The Astro experience was fruitful from interactive CLI to high-scored Page Speed Insights.
I developed a frontend stack like this, and I feel like these are best practices for me;
→ Styling: Tailwind-based themes or components, pay attention to the colors and contrast.
→ Framework: React for web apps, Astro for content websites
→ Accessibility: Most themes are accessible. Plus prefer native HTML elements with styling, avoiding libraries; you’ll be shocked to see, that there won’t be so many remaining accessibility task
+Mobile: Native Technologies (no cross platforms, hybrids, etc.); iOS and Android platforms can and should differ, it’s good to accept this. For example don’t insist on having the same date picker. An Android would feel consistent if you’re using an Android-like picker on Android. To relieve more, every day, platform experiences are close to each other. Even for the simplest app, cross-platform technologies have a perception of bad apps; whenever I see an app written in React Native, I feel like they’re a startup and they cannot afford good quality. Whenever I see a good Flutter app, I feel like they might lack developers but they pay attention to details. So there is no good area to use multi-platform frameworks for a good-feeling application.
On SwiftUI
Whenever I use SwiftUI I find myself complaining about the immaturity of the SwiftUI. One year ago, everything was so much pain, so we were required to wrap classical UIKit views to use with SwiftUI. Nowadays, there are more solutions available in SwiftUI, but if you increase the minimum supported iOS version. It’s a real annoyance to obey the marketing versions while iOS versions are technically the same. (Btw, if my phone was not stuck at iOS 15, I maybe wouldn’t complain, I don’t know.) I saw some good app ideas in AppStore but I noticed that they require a minimum version of iOS 16 or 17.
Serious App Developers still cannot put 16 as a minimum version, there is still a huge portion of the market for iOS 15 users. So when Apple announces and encourages a framework that is not backward compatible, they’re not aiming at serious makers, because they cannot use this novelty. The purpose of SwiftUI was to catch up with the Reactive / Declarative framework’s speed and make developers develop and monetize faster. Faster monetization of 3rd party apps contributes to Apple’s commission revenues. So in plain sight, Apple is damaging its flywheel model with a suboptimal decision-set of investing in these technologies, in other words; bullshit.
On Apple’s Sports Score App
I saw a video where a user wants to dismiss a score result from the screen. The app was strongly against Apple’s design guidelines. Button layouts are different, dismiss logic, loading states and animations are against the best practices they pioneered so far. It seems like an intern’s work. After you find the data sources, how much effort will it take to develop this app? Apple’s inconsistent designs make me question their quality of design and their perception.