131–140 of 257 posts
People nowadays praise Apple for their hardware, mainly their silicon - not their software. Maybe it's time for Apple to shake things up and promote someone else to VP of Software engineering?
Earlier quoted context omitted.
>Then why use it anywhere? To write code quicker, and make it easier to maintain. If it's a moderately complicated UI, then I could code it up much faster in React (my guess is around 10x). IMO, React isn't about functional programming, it's just a good DSL for writing UI.
> To write code quicker, and make it easier to maintain. Yes, it's faster to write. Is it easier to maintain? Doubtful. Especially when you inevitably run into issues that your whole UI re-renders a couple of hundred of times a second, and you have to go in and butcher everything with useMemos, caching etc.
It sounds like SwiftUI is capable, but not performant for his use case. Fair enough.
It's also not capable right now (macOS 12/iOS 15/Xcode 13) for some parts. For example, there is no simple way to declare initial focus for a text field in a view. One has to resort to "onAppear" hacks, such as: .onAppear { // 0.05 is a guess. anything lower seems to run too early // and does not have the desired effect. DispatchQueue.main.asyncAfter(deadline: .now() + 0.05) { focusTextField = true } } Similarly, dis…
On Android, at least, Compose feels fully baked to us. Our shop is fully committed to new development on Compose UI; bridging tools for legacy components work great, and they work great for hosting new Compose views in our legacy framework as well. The Compose team is engaged with the community, and is generally ahead of the ball on problems real engineers are having.
In addition to all that, the structure of Compose has led to its new tooling being used in a variety of other domains. Engineers outside of Google are wiring Compose up to TUI frameworks, to platform-independent view APIs, and even running Compose without any UI at all as an asynchronous programming framework.
I don't have any experience with SwiftUI to compare it to. As an outsider, I know that the naysayers are sometimes louder than happy consumers of a new technology. But I will say this: there's a whole narrative in the Android world pointing out that Compose and Compose UI are two different things. Compose is available to use and work with even if you never touch the concrete UI framework Google has built.
Does any equivalent narrative exist in the iOS world? Or is SwiftUI mostly just a UI framework?
Earlier quoted context omitted.
It's a great idea but not fully baked yet. My former colleague is using it for internal apps and it seems to work fairly well (UI is not fancy), but not for anything going into the high volume apps, which has much more complex behavior (designers are asking for stupidly complex UI). It's much better in the upcoming OS since they added better navigation, but requires the latest OS, which is not supportive for many com…
At my company we've been slowly rewriting our UIKit app in SwiftUI. We were due for a rewrite when SwiftUI dropped. I'd say we're about 75% done. For those "stupidly complex UIs", SwiftUI just doesn't have enough hooks for customization. And the improvements are too slow. Using SwiftUI has been bitter-sweet. It feels like you just can't use it to craft a high quality app that doesn't look like a generic iOS app.
To be honest, as a user, I'd really rather see more "generic iOS apps". I think too many design teams are self-centered and do not consider that users need the apps not to admire their wonderful creations, but to get certain things done. In other words, your app is the center of your world, but it is not the center of mine. It's something I want to use to get stuff done quickly, with minimum effort, and with minimum cognitive load. Generic is good.
Earlier quoted context omitted.
I’m with you, however mac os remain the best dekstop OS and iOS remain the best mobile one, even after all those years. So, they must be doing something right..
iOS lacks many features that have been standard on Android for years and the only reason it feels so smooth is because the UI thread has pretty much the highest QoL that anything can ever have. iOS would rather drop your network call than drop a single frame. Android variants all have things that iOS can only dream of having in five years (notifications was a fun one), just spread very unevenly throughout manufacture…
This discussion feels incomplete to me without a mention of developments in the opposing camp: Google's Compose UI framework. On Android, at least, Compose feels fully baked to us. Our shop is fully committed to new development on Compose UI; bridging tools for legacy components work great, and they work great for hosting new Compose views in our legacy framework as well. The Compose team is engaged with the communit…
Earlier quoted context omitted.
Won't work at all for left-handed people, as opposed to now where it works for no one during the same period? Seems like an improvement, despite my doubts that it truly wouldn't work for left-handers. Anyway, hopefully we can avoid wild mischaracterizations here. My expectation obviously isn't that things work 24/7 indefinitely. Think about how the typical user is going to discover that the battery is low. Either the…
A few observations here. The first: this product is an optional thing. There are many mice manufactured, they all work with Macs. I, personally, have a Kensington. The last Apple mouse I had possessed a tail, and was only okay, not, for instance, good. The next one: the charge lasts a month to six weeks with normal use. Next one after that: it's your unlucky day and you didn't idly think "oh, hey, I'll plug this in o…
Anyways I'm not irritated. This conversation was started because I asked what the good reasons behind obvious design issues are. So far the conversation has been about how you can work around them. That's great, but not the point.
Earlier quoted context omitted.
At my company we've been slowly rewriting our UIKit app in SwiftUI. We were due for a rewrite when SwiftUI dropped. I'd say we're about 75% done. For those "stupidly complex UIs", SwiftUI just doesn't have enough hooks for customization. And the improvements are too slow. Using SwiftUI has been bitter-sweet. It feels like you just can't use it to craft a high quality app that doesn't look like a generic iOS app.
> It feels like you just can't use it to craft a high quality app that doesn't look like a generic iOS app. To be honest, as a user, I'd really rather see more "generic iOS apps". I think too many design teams are self-centered and do not consider that users need the apps not to admire their wonderful creations, but to get certain things done. In other words, your app is the center of your world, but it is not the ce…
It’s not released yet, but my beta testers seem to love it. Most of them are non-technical. I haven’t written the on boarding stuff yet but the generic UI/UX means they get up to speed quickly even without a tutorial. I’ve received considerable praise for how intuitive it is.
It’s developed in SwiftUI. My first time working on iOS. My experience is similar to others. 75% of the time, it’s a joy to use. 25% is spent pulling my hair out over internal bugs and bad documentation.