A few times I looked into Swift development but got a little confused on where to start - Swift? SwiftUI? Both? I don’t really have a desire to make an iOS app but would love to cut my teeth making a macOS app, maybe something like an RSS reader to start.
100 Days of SwiftUI
91–100 of 110 posts
Re: 100 Days of SwiftUI
#92A few times I looked into Swift development but got a little confused on where to start - Swift? SwiftUI? Both? I don’t really have a desire to make an iOS app but would love to cut my teeth making a macOS app, maybe something like an RSS reader to start.
I'm working through the book Hacking with macOS from this same author (Paul Hudson), which is a Mac-focused Swift/SwiftUI book. It's not free, but it's extremely well-done so far.
Re: 100 Days of SwiftUI
#93A few times I looked into Swift development but got a little confused on where to start - Swift? SwiftUI? Both? I don’t really have a desire to make an iOS app but would love to cut my teeth making a macOS app, maybe something like an RSS reader to start.
Apple's tutorials have a good mix of teaching both, along with a section "Creating a macOS App": https://developer.apple.com/tutorials/swiftui.
Re: 100 Days of SwiftUI
#94Earlier quoted context omitted.
From our experience Flutter apps are easy to start with but quite hard to maintain. The core system keeps changing so much you are constantly having to fix things and dealing with broken dependencies. Would never use it for anything important.
Our experience is opposite. We started with GetX because we were new. Then moved to Riverpod/Go-Router as we gained experience. We have a set-up of four modules (shared lib; shared ui; app1 and app2) for two apps targeting web+ios+android; about 50k LoC @ 160 line length. Obviously there were a lot of friction when moving out of GetX, but upgrading things have always been easy. Usually at most one day worth of work (…
> Also, we don't add dependencies unless we really need to
I think this is the trick. I've worked for a client whose coding standards basically forbade 3rd party clients. Turns out, it often is not needed at all. Do you need to include a library for a bar chart? No, a bar chart is often just a bunch of rectangles and labels.
When you have stupid-simple project setups, you can have huge projects but they'll compile fast and upgrade quickly.
Re: 100 Days of SwiftUI
#95Earlier quoted context omitted.
The URL is correct for SwiftUI.
Yeah, I know, but the comment mentions Swift everywhere else, including in the name of the list being created in Reminders. The conflation of Swift and SwiftUI also shows up a few other times in the comments here.
This course includes Swift language tutorials and the author has said it replaces the original 100 days of Swift course in most cases, which was UIKit-centric.
Re: 100 Days of SwiftUI
#96I wonder how feasible it is do the course on Linux - I am interested in learning mobile dev but don't own a Mac.
Re: 100 Days of SwiftUI
#97A few times I looked into Swift development but got a little confused on where to start - Swift? SwiftUI? Both? I don’t really have a desire to make an iOS app but would love to cut my teeth making a macOS app, maybe something like an RSS reader to start.
Swift is the language. SwiftUI is one of the UI frameworks. You need to know the language before you can build apps using the UI frameworks.
Re: 100 Days of SwiftUI
#98Earlier quoted context omitted.
I've worked in mobile since 2004 (not a typo, '04). The 'one platform to rule them all' has been just around the corner the entire time. As was already said, don't hold your breath. All of that said, if you are time constrained and really want to look at a single thing, I would go with Flutter. It impressed me when I cranked out a side project with it a year or so ago. Hopefully they continue to put effort towards it…
In my experience the issue with Flutter apps is though they aren't too bad on Android, they have an odd off-putting feel to them on iOS, more than is typically visible with competing cross-platform UI frameworks.
Especially when you need a date picker that doesn't scream Android
Re: 100 Days of SwiftUI
#99Tangent but I'm holding out from learning Swift until I see how the "Cross platform UI" wars shake out. We've got at least Kotlin, Dart, and JavaScript all battling it out (via Kotlin Multiplatform, Flutter, React Native) to be the king of UI languages across all platforms. I really like Swift though (from the little I've learned), so it's too bad it doesn't really have a cross platform UI story yet. (I could learn a…
I’ve been dabbling in this space for a long time and I’ve become convinced there will be no good cross-platform mobile UI story. The UIs are too different for there to be a one size fits all solution. (as an aside I really like Swift too and have been enjoying noodling around with it as a server language. Probably rarely a wise choice given that it isn’t their focus but there is some attention given: https://swift.or…
There’s a good cross platform mobile UI story, it’s called browser.
Re: 100 Days of SwiftUI
#100Earlier quoted context omitted.
> Cross Platform UI is a myth How can you say this when many of the worlds most used apps are written in React Native? Same with Electron and desktop apps. I find it hard to believe you can be more productive writing native code when you need two entirely different codebases, compared to a single one, no matter how good of an iOS and Android developer you are.
You do realize you still have to write a lot of native code in cross platform apps, right? It's what all the most used apps do. This idea that individually you can be more productive on a cross platform app has no basis in reality. You're still having to concern yourself with platform specific aspects, except now you're also throwing in another layer into the mix for your shared aspects. These shared aspects tend to…
> You do realize you still have to write a lot of native code in cross platform apps, right? It's what all the most used apps do.
You asked from cross platform UI framework, not for abstracted away mobile development framework.