I made the mistake of choosing iOS and SwiftUI for the first platform of a niche app, a few months ago. Trying to do things in the way Apple wants seems a good strategy in general, but the experience was bad in countless ways. The developing&publishing approval barrels don't help. I succeeded, but only by throwing vastly more experience and energy at it than should've been necessary.
One of the engineering culture surprises was realizing that a lot of iOS developer chatter seemed to be repeating PR talking points, rather than the frank critiques that I'd expect in analogous situations in many other software development communities.
Besides a theory of fandom or Stockholm Syndrome, or dreaming of a job at Apple, or fearing being deplatformed... maybe there's an incentive for someone with hard-earned knowledge in something marketable to play along and be reassuring about their own expertise in it?
And SwiftUI is at least one level above that, so it’s going to be some time before it’s stable enough to get that spit and shine properly.
I’m off to muck about in the internal view hierarchy of a navigation bar to animate its button label..
This tends to be overestimated. There's rarely a good reason to fear criticism. Apple is too huge to notice you, unless you're famous yourself. Also, Apple is a very bureaucratic organization especially now. The App Store editorial team is in its own silo and doesn't necessarily pay attention to this, and isn't influenced by other teams within Apple (except when top executives step in, of course).
Ironically, the rational fear of criticizing Apple comes not from Apple retribution but rather from all the random little Apple fans jumping all over you for criticizing Apple.
You've already made up your mind if you're just going to slap such labels upon anyone who disagrees. Frank critique doesn’t thrive in echo chambers, and your preemptive polarization is just as guilty of such bias, just in the other direction.
What term should we use for your camp? "Haters?" "Lazy devs who don't bother to learn the intricacies of a new platform and expect stale knowledge they studied 10 years ago to apply everywhere?"
Electron is that way and have a nice day.
> Your comment is refreshing.
jamil7's GP comment was literally 2 sentences just saying "I'm disappointed, half-baked, bugs."
Disappointed how? Half-baked how? No details, just a string of some negatives and that's enough to make you happy. "Someone who agrees with me! Everyone else must be an Impostor!" (little Among Us reference there)
SwiftUI is a monumental project. Does any serious developer with real-world experience expect long-standing technologies like AppKit/UIKit/Cocoa/etc. to be completely supplanted within 2 years?
Any developer worth their bits would immediately notice the extensive support for incrementally adopting SwiftUI in legacy projects, or selectively falling back to existing tech in SwiftUI projects. You’re not supposed to go all-in if you're not fully comfortable with it, or if it doesn't serve all your needs yet.
And anyone even casually glancing at Apple SDKs will sense that this -is- the future. It's honestly fucking amazing to be able to target macOS, iOS, iPadOS, tvOS, watchOS and soon the rumored AR glasses with like 70% or more of the same code. Best of all, it not just spits out native widgets on each device (unlike Flutter or Qt), but also automatically adapts to the paradigms of each form factor (like navigation pages on phone/watch/TV versus sidebars on Mac/iPad).
Not to mention the rich support for adding internationalization and accessibility features to your app at a low cost, something that other major frameworks and companies generally ignore.
Yes, there are bugs. Yes, the documentation is appalling in many places. Yes, Apple doesn't communicate very well.
But hot damn, SwiftUI is the most refreshing UI framework I've seen since WPF, which Microsoft didn't even dogfood as much as Apple has done with their tech (both Swift and SwiftUI are already being used in core features of their OSes).
Shit that would take me a week on other frameworks I can now throw together in a day with SwiftUI, live previewing and incrementally improving and targeting multiple devices as I go.
I am not going back to any other framework. I would rather put my projects on hold if SwiftUI cannot handle them in its current state, than the other way around. The grass may seem greener on the other side for now but only because it's growing from a pile of rotting cow turds.
How's that for Frank Critique
Fundemental building blocks of SwiftUI are broken and have been since it's annoucement, List, NavigationView and NavigationLink for example – these are the basis of SwiftUI apps and need attention from Apple developers, I've reported bugs, memory leaks and performance issues with these and they've been acknowledged, maybe they fix them during iOS14's lifecycle but maybe not. We got some much needed features at this years WWDC but I would have also liked to see these fundementals addressed and maybe even rethought (navigation). It's not like we're talking about a volunteer open source project here, we're talking about the future flagship UI framework for 2 trillion dollar company. Run and profile Apple's own Fruta example app if you want to see what I'm talking about.
When it works, then yes like I said I can't imagine a faster way of building for Apple platforms. But right now I would warn others not to adopt it at any meaningful scale for another 2 years.
Apple's lack of documentation and communication doesn't help; the best resources have been from fellow developers who were groping around in the dark like the rest of us and managed to figure things out by themselves. [0,1]
But again, I've already been able to do many things in SwiftUI that I don't even want to attempt in AppKit/UIKit/other frameworks.
Right now I think it's good enough for small apps or personal convenience tools. One surprising application for it is in games, where it actually works quite well, compared to all the other alternatives for drawing scalable/animatable HUDs and text etc. [2]
In an year or two I don't think anyone would willingly choose to fumble around with legacy frameworks if they want to target phone, tablet, computer, watch, TV and glasses all with one codebase.
[1] https://swiftwithmajid.com
[2] https://twitter.com/InvadingOctopus/status/12792872846265794...
I'm just starting to work on apps and I feel the same moral imperative, but have no special love for Xcode &co.
React Native is a pain to work with when the scope of your app becomes any larger than an agency level project (e.g. an app for an event that's only going to be used one weekend).
Once you start getting into requirements for a prime time production app (setting up APM tool, setting up tracking, setting up Google Analytics, native specific features that don't have a React Native hook yet) React Native is an extra layer of abstraction that slows you down. The experienced native developers hate working with it because they'd rather just use the related native platform themselves, but at the same time for any slightly complicated app you still need their expertise. Also, out of the box animations in React Native is difficult to work with, especially with less experienced developers, so you end up having to do a variety of work arounds to get animations between screens to look nice which you'd get out of the box just using Kotlin/Swift.
In 2020 if I needed to make an app quickly, cheaply, that worked on both platforms, I'd make a great mobile website and wrap it in a native shell. Any screen that needed a little bit extra "magic" I would do 100% native code for both platforms. This also allows you to ship updates to screens as you go without a complicated "codepush" JavaScript setup, as it's just a webview on the other end.
I'm still maintaining the React Native search app now, it works fine, but if we need to create an iOS version of it I'd definitely pitch doing it in native code.
Compared to SwiftUI it was far easier and even faster. Granted, I’ve worked with React a lot. But it’s really quite nice, I’m impressed with the whole ecosystem and how it’s grown.