[HN Gopher] 100 Days of SwiftUI
___________________________________________________________________
100 Days of SwiftUI
Author : sanketpatrikar
Score : 137 points
Date : 2023-06-16 16:43 UTC (6 hours ago)
(HTM) web link (www.hackingwithswift.com)
(TXT) w3m dump (www.hackingwithswift.com)
| zengid wrote:
| Tangent 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 all four but I have kids, so it'll probably just
| be React Native for me.)
| jb1991 wrote:
| No, it won't be Reactive Native or any other. There are no
| cross-platform UI wars any more. There are efforts at this, all
| with huge compromises, but working with a native UI toolkit on
| any platform will always offer a superior developer experience
| and a superior user experience; that's just the way it has
| always been, still is, and I'd predict always will be.
| jeremy_wiebe wrote:
| The problem is that developer experience (and often user
| experience) aren't always the highest priority. For many
| businesses that want to ship a mobile app, cost is by far the
| biggest constraint. And "writing once, shipping everywhere"
| pushes out native development.
|
| We at Khan Academy have moved much of our app to React Native
| and overall it's a great experience and much easier to
| maintain than two native apps.
|
| Of course, the constraints and requirements vary by business
| and so what's right for us may not be right for you.
| nicoburns wrote:
| Add Rust to your list. The Rust UI ecosystem is still very
| immature, but it has a tendency to implement things very well
| once they are implemented and the potential is huge.
| zengid wrote:
| Speaking of Rust UI, do you have any favorites? I've been
| casually watching for a long time but haven't seen a clear
| winner there besides Iced or egui.
| zengid wrote:
| That's another one I'm watching for sure!
| 037 wrote:
| While we were waiting for the perfect cross-platform solution,
| we underestimated the web standards that we've always had in
| front of us, and are slowly becoming the perfect, powerful
| common denominator.
| dwaite wrote:
| sort of. From a user perspective, the app security model is
| brokered (by a store) while the web security model is a
| direct ad-hoc relationship to whoever [you _think_] owns the
| domain you are on. Apps tend to need reviews for
| republication, while a website could change owners (through
| acquisition, domain expiry or other exploit) at any given
| time.
|
| Modern systems sandbox both application access for security
| exploit reasons as well as user privacy reasons. The web lets
| apps talk to one another arbitrarily, embed one another in
| frames, and so on.
|
| Because of this, hardware access will always be significantly
| more constrained than store-reviewed apps.
| Mertax wrote:
| Why not include C#/MAUI on this list to make it 5?
| Dennip wrote:
| From my experience with Xamarin i dont have high hopes. Every
| time i needed to some do something slightly interesting I had
| to write wrappers for both the iOS and Android API's to get
| anywhere.
| sirwhinesalot wrote:
| The moment it went with Catalyst on macOS and forgot Linux
| exists entirely it was dead on arrival. It's Xamarin Forms
| but worse. Well done Microsoft _slow clap_.
| pjmlp wrote:
| Ignoring Linux I can even understand, given the Year of
| Linux Desktop meme, but the Catalyst shortcut, what were
| they thinking.
|
| Not even the new VS4MAC UI uses MAUI, they used their own
| bindings.
| criddell wrote:
| > it was dead on arrival
|
| I understand holding out hope for year of the Linux
| desktop, but ignoring Linux has never really hurt anybody,
| has it?
| sirwhinesalot wrote:
| Well, depends. If I'm evaluating cross-platform UI
| libraries, Linux support is a must have, even if the
| market might be small.
|
| Electron, Qt, Anything Java, Avalonia, wxWidgets, all the
| native webview wrappers, etc. All have Linux support.
| dangerboysteve wrote:
| Tauri looks great (Rust, webkit & js)
| sirwhinesalot wrote:
| Oh yes, it is my preferred solution these days. Web crap
| is annoying as heck to work with though...
| zengid wrote:
| I'm a C# dev but I don't really have faith in Microsoft
| sticking with any UI library longer than 5 years. They even
| seem to have embraced React Native to make their own
| products. I'd go with Avalonia if I picked a C# UI, but I
| prefer Typescript and JSX over C# and XAML.
| lobstrosity420 wrote:
| Swift had no horse in that race whatsoever. It was made to
| interface with Cocoa and it excels at pretty much exclusively
| that.
| snyp wrote:
| I've been writing mobile apps since 2013. Cross Platform UI is
| a myth. Just use a framework and language you are familiar or
| comfortable with. I prefer native so I just stick to that. You
| are sure to be most productive in languages you are familiar
| with rather than any new/old cross platform UI framework. Just
| be cognizant of the fact that all of them have trade offs.
| nwienert wrote:
| A lot of people saying it doesn't exist or work, but as the
| creator of Tamagui, I have to vouch for it. I think it works
| pretty amazingly, and we have some really beautiful apps in
| every App Store (plus web).
| rudedogg wrote:
| Sorry but what you say just isn't possible. Especially with
| a browser-based cross-platform solution, you're gonna pay
| on the performance and native integration front.
|
| What you built looks nice and I'm sure it works well for
| many classes of apps though.
| nwienert wrote:
| React Native renders to native views on iOS, Android,
| Windows and Mac!
| waboremo wrote:
| It certainly exists/works, but is it productive? With my
| time using Tamagui I would go with no.
|
| There are just so many traps everywhere. 99% of it isn't
| your fault, just the name of the fragile RN game. Install
| another package here to handle one use case on one
| platform, avoid this component on one platform because RN
| doesn't support this thing, entire blocks of very simple
| styles commented out due to performance cost. List goes on.
| It's a never-ending game of your codebase feeling horribly
| fragile, and that's if you remain within the RN = Android
| and iOS realm. As soon as you start trying to get it to be
| truly cross platform with desktop apps - endless
| nightmares.
|
| I so desperately want cross-platform development to feel as
| smooth as people proclaim, but it's really like playing
| russian roulette with every new component added. At the
| end, you question if it was really worth it due to how much
| you've had to rewrite anyways. You become sort of delirious
| after working on a project that uses such solutions,
| wondering if you traded user experience for developer
| experience and wound up messing both up in the long run.
|
| Beautiful site/docs though.
| zengid wrote:
| Hey that looks pretty cool!
| https://github.com/tamagui/tamagui
| marcellus23 wrote:
| Do you have a link to an example iOS app built in Tamagui
| to check out?
| nwienert wrote:
| The beta https://beta.aidungeon.com is pretty nice, not
| sure if the app is public yet or still on TestFlight.
| krembanan wrote:
| > 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.
| brailsafe wrote:
| It's just reps no matter how you do it.
| waboremo wrote:
| 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
| also not be up to user expectation most of the time, so
| you're having to rewrite things that comes easy for native
| apps, to ensure consistency and accessibility.
|
| Such moves makes sense for Facebook. Given who they hire,
| what they work on. Same for Microsoft, but not sure using
| them is a good example considering their app experiences
| are universally terrible. For a lot of other places though?
| There has been a grand total of zero proven demonstration
| of increased productivity or dramatic savings. You still
| have to hire android/ios/windows/mac/linux devs
| respectfully whenever you eventually want to expand to
| those platforms.
| wk_end wrote:
| I don't know if I was using React Native "wrong" or what,
| but when I tried it out I found it to be a miserable
| experience. There's almost no usable components "built-
| in"...there seems to be an expectation that you cobble your
| UI together using one of a variety of different third-party
| components or component libraries, and every single one I
| tried was incomplete, buggy, poorly-maintained, poorly-
| documented...
|
| Based on that trial: I'd much rather work on two sane
| codebases instead of one in React Native that's a
| maintenance disaster. As a bonus, since your apps will be
| native, they'll probably be faster, feel higher quality,
| integrate better with the platforms, etc.
| pjmlp wrote:
| Because when problems come up you need an iOS and Android
| developer to sort them for you.
| johnthuss wrote:
| The only cross-platform UI that is likely to be feasible to use
| long term is HTML/CSS/JS. That comes with significant downsides
| in terms of display fidelity. But that is going to be the case
| (to some degree) with any cross-platform toolkit.
| afavour wrote:
| 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.org/server/)
| danielvaughn wrote:
| Yep. The only real option is that each platform agrees to
| abide by a common protocol for describing GUIs. I don't see
| that happening.
| criddell wrote:
| > there will be no good cross-platform mobile UI story
|
| Generally (IMHO) there are no good cross-platform stories,
| mobile or otherwise with the notable exception of some game
| engines. The closest you can get is choosing the web browser
| as your platform and writing a web app (Electron).
|
| If you want to make the best app you can, use the native
| toolkit directly or via a framework for your UI.
| koito17 wrote:
| For web apps on desktop you're not even restricted to
| Electron anymore. Thanks to Tauri, I feel a lot more
| comfortable shipping web apps beyond the browser (and React
| Native) since I don't have to pay the cost of bundling
| Chromium _and_ Node.js. The Rust ecosystem is large enough
| that any backend-related task I would use Node.js for has
| an equivalent in Rust.
| pjmlp wrote:
| We were never restricted to Electron.
|
| There are browsers already installed, and MSHTML apps and
| XUL predate it for a decade.
| waboremo wrote:
| Seconding this. The cross platform experience has been so
| abysmal for so long, that I question whether the benefits of
| "easier to support" are even real considering the generally
| worse experience, longstanding bugs that are harder to nail
| down, and the added time of having to switch mental models
| between cross platform and the native code you're going to
| have to eventually write.
|
| I'm at the point now where native apps are still back in
| heavy consideration, as it's far more straight forward to
| cascade launch your products on different platforms than it
| is to half-ass everywhere.
| chasing wrote:
| Learning one will make learning the others easier. They have
| conceptual differences, of course, but there's also a lot of
| overlap.
|
| Regardless, the "cross platform UI wars shaking out" will mean
| there are three or four options with high market share that
| each have plusses and minuses depending on the specifics of
| your project. There won't be a single winner.
| dlivingston wrote:
| I wouldn't hold your breath. It's very explicitly tied to Apple
| APIs and OS conventions; I doubt it will ever be cross-
| platform.
|
| If you want a cross-platform SwiftUI, QtQuick/QML is probably
| your best bet.
| danielvaughn wrote:
| I really like Flutter's approach, I just wish they weren't so
| wedded to (a) Dart and (b) Material Design.
| tarkin2 wrote:
| I was put off my React Native and Flutter since they don't give
| a native experience and some native features. Good and fast at
| the start, but after a while they'll be lacking.
|
| Kotlin multiplatform--with the business logic shared but UI
| native--seemed like the best bet, backed by an impressive stack
| and company. And KM has gained traction in quite a few
| companies, slowly moving shared logic to Kotlin, while keeping
| separate iOS, Android and web teams.
|
| Yet I feel more companies value Flutter, or even React Native,
| because it allows companies to reduce the number of employees
| they need, and many companies will value that over than having
| a perfect native experience.
|
| I can't see there being a winner anytime soon. Web-savvy
| companies will favour React Native, companies with native
| developers will move some things to Kotlin Multiplatform,
| companies looking to reduce head counts more than improve user
| experience will favour Flutter or React Native.
| imachine1980_ wrote:
| for what understand (im not a mobile developer) the best of all
| of this is react native, works well most time the ux of expo is
| great and you can "port it to web" like twitter, all the people
| who use xamarin cry, all the comments who hear about kotlin
| multi platform is the ecosystem isn't there, and flutter is
| lots harder when thing make more complicate and google is
| unreliable they already kind kill flutter desktop or at leas
| the cut most funding, i feel react native is the only really
| companies beat real money in it, you have multiple app in your
| phone using it discord, instagram,pinterest, microsoft teams,
| they aren't perfect but they aren't bad, also the comunity is
| huge, also i hear lots of bad things about swift so there too,
| the lack of docs and that.
| egberts1 wrote:
| Let us not ignore Electron GUi kit.
| cush wrote:
| The Browser Company is currently working on a Swift on Windows
| MobileVet wrote:
| 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.
| zengid wrote:
| [flagged]
| rapsey wrote:
| 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.
| CrimsonRain wrote:
| 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 (worst case). We don't
| upgrade as soon as a new flutter version is released. We
| give it a month at least and then upgrade.
|
| During upgrade, most of the problems usually come from 3P
| dependencies which interact with native such as package
| info plus. Also, we don't add dependencies unless we really
| need to. I think we are at ~30 total between all modules.
|
| On the other hand, our react projects are forever in
| dependency hell. Much larger project, yes but way too many
| dependencies and too many things break during upgrade.
| dan1234 wrote:
| I have the same problem with react native.
| com2kid wrote:
| I stopped supporting an open source React Native library
| because keeping the sample code working in Expo was
| taking too much of my time.
|
| This was years ago, maybe things have calmed down since
| then, but Expo always felt like hanging onto the horns of
| a bull, so long as you didn't fall off it was a fun ride!
| lockhouse wrote:
| The biggest problem with Flutter is Dart. Not the language
| specifically (it's a nice enough flavor of C-family
| language), but the ecosystem. Even Swift is better in this
| regard. Flutter ported to TypeScript and sufficiently
| distanced from Google would actually be very compelling.
| [deleted]
| danielvaughn wrote:
| Yep, I just commented the same thing before I read this.
| I'd say it's both Dart and Material Design. Dart doesn't
| seem bad (I've only glanced), it's just not very compelling
| or interesting.
| Vt71fcAqt7 wrote:
| I have to agree. Also I feel like those complaining about
| dart just have a bad taste in their mouth from dart 1.0. Dart
| has named parameters (so better than java) and null saftey.
| It's a pretty standard GCed OOP language. I also don't
| understand when people complain about the dart ecosystem.
| Seems fine to me.
| mikhael28 wrote:
| Dart and Flutter are totally fine, and great in production. I
| really don't understand the hate.
| M4v3R wrote:
| Flutter is mostly fine. Until you need to implement text
| input in your app. And it turns out that autocomplete
| doesn't work properly on iOS for non-English phones and you
| discover there's a bug filled on their tracker for 5 years
| already and it's still open [1]. Or you encounter another
| similar issue that is niche enough that the developers
| ignore it completely but is frustrating for your users and
| there's nothing you can do.
|
| Don't get me wrong, I would really love Flutter to be THE
| solution to the cross platform mobile app problem, but
| sadly it only gets you 95% there and if you really care
| about the last 5% you're out of luck.
|
| [1] https://github.com/flutter/flutter/issues/12920
| jononomo wrote:
| Isn't getting 95% of the way there better than getting 0%
| of the way there? What are you going to do instead?
| waboremo wrote:
| Your equation isn't complete. You can't only care about
| getting 95% of the way there if the final 5% takes
| substantially more time than it normally would or worse
| halts development entirely.
| M4v3R wrote:
| It depends. For some use cases it's definitely enough and
| if you're on tight budget it might get you far enough.
| But eventually it might fall short and you'll have to
| either fight the framework or switch to a native
| solution.
|
| I believe it's good for knocking out an MVP if the mobile
| app is not critical to your business. I would not choose
| it otherwise though.
| kitsunesoba wrote:
| 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.
| martinald wrote:
| It's because unlike a lot of frameworks like React Native
| and Xamarin, it doesn't use native UI components under the
| hood (unless this has changed recently). It's a bit like
| using a canvas element in HTML and drawing your own
| toolkit, or old Java GUI apps.
| cush wrote:
| I'm still holding out for Xamarin
| madeofpalk wrote:
| More specifically, there are a bunch of efforts, but the
| Swift ecosystem doesn't seem too interested in this.
|
| Even Apple can barely get it with SwiftUI being a dumpster
| fire on macOS.
| pshirshov wrote:
| > 100 Days of Swift: Final Exam > Question 1/100: Which of these
| statements are true?
|
| > Hint: Click to show.
|
| > Option 1: The @unknown default case is there to catch cases
| that get added to an enum after we wrote our code.
|
| > Option 2: UIDevice.current refers to the model number of the
| most recent iPhone
|
| this is not about "hacking" nor learning programming or
| engineering. Seemingly that's about monkey coding.
| brailsafe wrote:
| How myopic. Pull out one question from the exam and use it to
| try and dismiss the product of a relatively well-respected
| content producer.
|
| Hacking with swift is one of maybe 4 really solid sources of
| material on swift and swiftui, many people have been helped
| tremendously by his work.
| erokar wrote:
| It's a good course, I went through it and soon after had an app
| published in the App store. (I assume it's still not updated with
| the improvements that came to SwiftUI with iOS 17, but not 100%
| about that.)
| ericmay wrote:
| I agree. I went through it as well though I didn't publish any
| apps to the App Store (lack of ideas :( ) but I personally
| adore Swift and SwiftUI and Hackingwithswift is such a great
| resource!
| collenjones wrote:
| Same sentiment here. Absolutely incredible (and consistent)
| quality from Paul Hudson.
| Apocryphon wrote:
| What's your app about?
| erokar wrote:
| It's a mood tracking app. Saturated market, but it was a good
| first app for me because it's fairly simple.
| runjake wrote:
| Near the very top of the page, Paul says that there is a newer
| version[1] and that if you're not sure, you should go with the
| newer version instead of this.
|
| I think with the target audience for this, you should just go
| immediately to the newer version[1].
|
| 1. https://www.hackingwithswift.com/100/swiftui
| dang wrote:
| Ok, we've changed to that from
| https://www.hackingwithswift.com/100 above. Thanks!
| jshier wrote:
| Yeah, 100 Days of Swift is actually an introduction to UIKit,
| not the Swift language (aside from the first 10 days or so), so
| anyone starting fresh should do the SwiftUI version. I do wish
| Paul (or anyone) would write a good intro to Swift the language
| without any of Apple's frameworks.
| runjake wrote:
| Paul has many, many videos focused on just Swift, the
| language. I'd post links but I am on mobile. The "Swift In
| One Hour" video is good along with his few multi-hour series.
| lockhouse wrote:
| Apple has a really good first party book about the Swift
| language.
|
| https://www.swift.org/documentation/
| lostgame wrote:
| I'd like to recommend this - I had to learn SwiftUI recently for
| my work and I found these courses to be absolutely perfect for
| learning.
|
| I've also found SwiftUI to be a fantastic little language, I
| think especially for prototyping it would be fantastic.
|
| One thing I preferred with these courses to so many similar other
| courses is that the video is not _required_. I much prefer to
| read, I don 't like videos in tutorials unless completely
| necessary - screenshots and text work just fine, and for myself;
| these exercises just hit the nail on the head. :)
| dwmbt wrote:
| i used this to learn swift myself and wished there was a
| newsletter to send out a reminder for me. instead, i used this
| apple script to generate a reminder every day for me. you can
| open Script Editor on your mac and run this. it will start today
| and schedule a new alert with the appropriate link :)
|
| ```AppleScript
|
| set baseURL to "https://www.hackingwithswift.com/100/swiftui/"
|
| set numberOfDays to 100
|
| tell application "Reminders"
|
| set swiftList to make new list with properties {name:"100
|
| Days of Swift"}
|
| repeat with i from 0 to numberOfDays set
| dayNumber to "Day " & i set dayLink to baseURL & i
| set reminderDate to (current date) + (i \* days)
| tell swiftList to make new reminder with properties
| {name:dayNumber, body:dayLink, due date:reminderDate}
| end repeat
|
| end tell
|
| ```
| marcellus23 wrote:
| note that Swift != SwiftUI, and there are "100 days" courses
| for both of them.
| solarmist wrote:
| The URL is correct for SwiftUI.
| marcellus23 wrote:
| 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.
___________________________________________________________________
(page generated 2023-06-16 23:01 UTC)