41–50 of 216 posts
Things were easier when it was just Objective-C and UIKit / AppKit. Swift killed my joy of making iOS apps.
How is Objective-C easier than Swift.
$0.02 on this is that I see a great many people doing the typical “all or nothing” with SwiftUI. I think this is a mistake. Like every single other engineering tool in existence, this one has costs and benefits. For the people saying it doesn’t work: use UIKit for those pieces. Otherwise, use it where it makes sense, and no more. I see this in Compose in Android too - lots of devs doing wholesale refactoring to repla…
When you support a range of tools, or introduce a new one, you often do it to support different audiences. I'm not an iOS dev. Is it a case that SwiftUI is really intended for a different audience and set of use cases with no expectation of a 100% overlap with the UIKit use cases?
$0.02 on this is that I see a great many people doing the typical “all or nothing” with SwiftUI. I think this is a mistake. Like every single other engineering tool in existence, this one has costs and benefits. For the people saying it doesn’t work: use UIKit for those pieces. Otherwise, use it where it makes sense, and no more. I see this in Compose in Android too - lots of devs doing wholesale refactoring to repla…
Arguably, its original sin is simply not being open source, and on top of that is trapped behind one of the most opaque bug-reporting mechanisms in the industry. Every minor hack involves tremendous reverse-engineering, which may then have to be replicated throughout the community, instead of being a GitHub issue and PR request like in Electron for example. There are of course upsides to the closed-source model, but in 2022, you have to deliver on those upsides if you want to make a strong case for your framework. But as I've mentioned above, SwiftUI hasn't. It has none of the aura or magic of AppKit from the 2000's: a framework used by amazing apps at Apple that can get just about anything done. In fact it is the poster child of all the downsides of this model.
And this doesn't even touch on the fact that Apple seems to repeatedly demonstrate that they don't take these technologies very seriously:https://twitter.com/stroughtonsmith/status/15294383578346332...
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, while I set things up. It's working out extremely well, but (of course) I'd like to rewrite the whole thing (a sure sign that I'm approaching ship).
I like things like the MVVM pattern, but it's been my experience that it's really not such a good idea to implement it in UIKit, because UIKit was designed explicitly for MVC. I have learned that those ugly-ass UIViewControllers are really important, and I circumvent them at my peril.
I'm able to release fairly basic Apple apps in UIKit, in just hours, so speed of development isn't compelling.
What is compelling, is the ability to design a reactive system for a complex app (like the one I'm writing now). AppKit has allowed this for some time, and it's possible to force UIKit to do it (but it isn't really designed for that).
I really wish that SwiftUI had been a bit more mature, when I started this system, but I would have also needed to rewrite the two server SDKs I use, anyway. It wouldn't have worked, no matter how hard I bang my heels together.
But I'm looking forward to it.
One thing that I've learned, is that it's really OK to wait for things to mature. Companies always screech about how we need to jump on the bandwagon, but that's all hype. I have taken OpenDoc courses at Apple DU. I also busted my ass, getting my app ready for Copland. I have scars from Apple hype.
I did take a big chance, by jumping directly into Swift, but that has turned out to be a good decision.
...no comparison with Flutter or at least remarks of what would also apply to it?
Wouldn't be surprised if no one quoted there has ever used Flutter. The Apple dev comment-sphere is quite insular.
For cases where portability or development time is valued more than having perfect Apple-HIG-compliant UI polish, there are lots of better options. Since Apple has flattened their Aqua interface out of existence down to mostly just gray text labels, even Electron apps started looking good-enough.
Things were easier when it was just Objective-C and UIKit / AppKit. Swift killed my joy of making iOS apps.
How is Objective-C easier than Swift.
I don't work in the iOS/macOS dev field anymore, but I've tried learning Swift in a similar fashion over weekends, to no avail. Incidentally, do you have any recommendations for learning Swift for someone coming from a C/ modern C++ background?
[1]: https://developer.apple.com/library/archive/documentation/Co... [2]: https://developer.apple.com/documentation/objectivec/objecti...
That's kinda like my story. Covid started and I wanted to learn something new so I started with Swift/SwiftUI. 2 years later I've been doing tons of crazy custom stuff in my portfolio tracker app https://stocketa.com (not launched yet) - I kept a thread with my progress since the first day I started my journey: https://twitter.com/Stammy/status/1527288954935922688 (scroll up).
This was last june but I wrote about my experience with SwiftUI at the time: https://paulstamatiou.com/getting-started-with-swiftui/
Earlier quoted context omitted.
Part of that is untrue. You can add SwiftUI to an app that starts with the UIKit lifecycle. In fact, you can jump back and forth between UIKit and SwiftUI as many times as you like throughout your app's view hierarchy. The current project I'm working on involves slowly porting an older UIKit+Storyboard app over to SwiftUI, so I'm seeing this in practice every day.
What's involved in the "jumping back and forth"? Is it pretty cumbersome or no? Do you use a UINavigationController at all in your app, or do your UIViewControllers do all of the navigating/presenting themselves?
Crossing the boundary from UIKit to SwiftUI involves instantiating the SwiftUIView, handing that over to a UIHostingController, then presenting that controller. Something like this:
let myView = MySwiftUIView()
let hostingVC = UIHostingController(rootView: myView)
navigationController.present(hostingVC, animated: true)
Earlier quoted context omitted.
If you use SwiftUI at all, the app has to start with the SwiftUI lifecycle (Edit: May not be true, see replies). But then you can wrap any UIView or UIViewController in a SwiftUI wrapper (UIViewRepresentable and UIViewControllerRepresentable). So that view/controller will be presented by SwiftUI's navigation logic, but inside that view/controller, you can write a whole UIKit app if you want.
Part of that is untrue. You can add SwiftUI to an app that starts with the UIKit lifecycle. In fact, you can jump back and forth between UIKit and SwiftUI as many times as you like throughout your app's view hierarchy. The current project I'm working on involves slowly porting an older UIKit+Storyboard app over to SwiftUI, so I'm seeing this in practice every day.