171–180 of 216 posts
Earlier quoted context omitted.
Apple tried to solve this with @AppStorage, but if you lean on MVVM... it doesn't really work. Hoping we get some new CoreData + UserDefaults stuff this upcoming WWDC
No, @AppStorage just does scalars, as I said
Earlier quoted context omitted.
Could be worse, they could have adopted RIBs https://github.com/uber/RIBs
One recurring issue I see on native Android navigation is, when you open an image in a file manager, switch back to the file manager and open a second image in the same viewer, sometimes pressing Back takes you to the first image. As a specific example, in Foxy Droid, if you download 3 apps in the background, get 3 "app downloaded" notifications, and click each one in sequence, you have to press Back 3 times to get b…
The other half of the equation is: don't override Back behavior unless you "own" the current task (it's rooted at one of your activities). When handling "Up" navigation and deep-links, you want Back to behave like "Up" and go to the logical parent of the current screen. When being launched in someone else's task, "Up" should launch a new task at the logical parent and "Back" should perform the default behavior (usually, Activity.finish()).
I started developing with UIKit for a year, hated it, then switched to SwiftUI and have built multiple apps over the past few years. IMO the "last 10%" bugs are not that big of a detractor compared to the benefits. Of course some of this is my bias; I'm more likely to spend time trying Stack Overflow hacks on SwiftUI bugs when the UIKit solution is better. I have to "work with the grain" sometimes if something just isn't possible in SwiftUI, but I'm fine making that tradeoff. I feel lucky not having the bias of years of UIKit, it's hard to let go of something when you're so used to it. I'm also lucky to not be working on apps with backwards compatibility issues, but I do think SwiftUI is the way to go for new consumer startups.
My team has two green field apps that we started a few weeks ago. The leads on the iOS team and Android team both spent a week evaluating the new UI systems in each platform, SwiftUI and Jetpack Compose. The conclusion was that Apple made a huge mistake tying it the iOS version and effectively limiting updates and it's real world use for years at a time. Both leads liked the design paradigms, but we are only going to…
Yeah iOS is one thing as you can generally wait it out as Apple is pretty aggressive about upgrades there but on macOS I think this limitation has really killed it's viability, people just don't update their desktop OS.
I was also baffled to find that TestFlight can't be installed on pre-Monterey Macs. I mean... WTF? That makes no sense. Sure, we can pass DMGs around, but my company is new to Macs and standardizing our QA team on TestFlight on all devices would've been simple.
Earlier quoted context omitted.
I'm targeting iOS 14+ for most projects and planning to drop when iOS 16 drops as well. Thankfully async/await was back-ported to iOS 13 (can't live without it!)
What kind of work are you doing with async/await that is so improved? Very interested in what kind of code on the client that is.
I also recently did some work with Vapor on the server side. Night and day difference there. The old Vapor EventLoop stuff was doable, if you squinted just right and concentrated really hard. The async/await version is as delightful as anything else I've ever used. Nearly as easy as writing Python.
I'm doing an app integrally with SwiftUI, as always happen with new frameworks, if you stay in the happy path everything is nice and easy, but if you start tweaking things, you are lost in the forest really fast. To give you an example, it's quite easy to add the swipe to delete function (within a list) just adding .onDelete() but if you want to add swipe to delete to a LazyVStack (similar to a List) you need to impl…
I'm probably just getting a bit old, but I like to layout my views manually. I've got a few helpers so I can write `view.left = otherView.right + 8` or `view.moveLeftEdge(to: margins.left` etc. I find it just so clear and easy to understand. I've not tried SwiftUI yet because my app needs to work on older devices than this allows, but it's also a solution for a problem I don't really have. It can't be as bad as AutoL…
Non-Apple programmers are probably shocked to learn that to this day there's still no graceful way to scale an Apple UI up. You can't just set "scale symmetrically" on a view. It comes down to positioning things with multiplication factors and literally trying and retrying those decimal numbers on every goddamned control/label combo. Over and over and over...
Then we needed to build a cross-platform desktop app, and went with Qt and QML. I expected to dislike QML, but no; it's really nice to work with, and our app looks great. QML has been around for years, so it's disappointing that SwiftUI has turned out to be such an apparent fiasco.
Earlier quoted context omitted.
What kind of work are you doing with async/await that is so improved? Very interested in what kind of code on the client that is.
I'm not the OP, but I'm updating my iOS app now to use async/await instead of callback hell for all of its networking code. It is much, much nicer. I also recently did some work with Vapor on the server side. Night and day difference there. The old Vapor EventLoop stuff was doable, if you squinted just right and concentrated really hard. The async/await version is as delightful as anything else I've ever used. Nearly…
On recent versions of iOS it's capable of doing 99% of the stuff I'll ever want to do and it will look nice. Just as long as I don't want to step too far outside of what Apple thinks is the right way (tm).
macOS - on the other hand - is far more more buggy/inconsistent e.g. Focus with List's of TextFields. It is also missing a lot pretty basic macOS functionallity e.g. no way to implement drag 'n' drop in Finder'eque recursive outline views, open tabs or windows - in fact window management and routing is just not much fun.
So for iOS I'd not hesitate. It's good, better than React Native and getting better. It does't really feel like a half baked abstraction layer over the top of UIKit.
For macOS on the other hand; it's much less clear. It's missing so much. And then there is the Catalyst auto-translate iOS app's stuff, which is kind of a worry that the grand plan is the moment it's feasible to dump it on macOS, it'll be dumped. So still not sure I'd use it for anything sizeable. Hopefully though will have a clearer picture of Apple's intents for the platform after the next WWDC.
I'm really looking forward to what comes of it, but I have chosen to do my current major project in UIKit. A couple of reasons: 1) The documentation for SwiftUI, when I started (about two years ago) was awful . I was shocked at how bad it was. I believe that it has since improved. 2) I knew of no major apps (even Apple ones) that had been done with it. I already knew that UIKit was up to the task, and held my nose, w…
Yeah UIKit is deeply MVC. It may not be the most conceptually elegant but in my experience you're almost always better off cutting with the grain of the underlying platform's abstractions instead of trying to superimpose a new leaky abstraction on top of them. I worked on one large iOS codebase that went all in on the VIPER architecture and it was one of the most unweildy and baroque codebases I've ever had the misfo…
I've seen all the horrors, and i can now safely claim that all the problems i've seen on iOS development come from not designing the model layer properly in their MVC app. Because most developers start by coding UIs and later end up wondering where to put that business logic and make it reusable.
And now every time i see another pattern that claim to facilitate refreshing the UI upon model change ( and vice versa), i know it's going to be a failure.