100 Days of SwiftUI
hackingwithswift.com
hackingwithswift.com
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. :)
```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
```
(I could learn all four but I have kids, so it'll probably just be React Native for me.)
If you want a cross-platform SwiftUI, QtQuick/QML is probably your best bet.
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.
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!
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.
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.
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.
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.
Even Apple can barely get it with SwiftUI being a dumpster fire on macOS.
I understand holding out hope for year of the Linux desktop, but ignoring Linux has never really hurt anybody, has it?
Electron, Qt, Anything Java, Avalonia, wxWidgets, all the native webview wrappers, etc. All have Linux support.
Not even the new VS4MAC UI uses MAUI, they used their own bindings.
(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/)
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.
There are browsers already installed, and MSHTML apps and XUL predate it for a decade.
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.
Any equivalent of the above has to be hacked together using JS, which ties up the main thread and can never fully match the host OS.
At this point, the most straightforward technical road to cross platform UI seems to be building high level UI toolkit that runs on browser runtime (ONE specific browser run time), and "platforms" slowly integrating this runtime as their native and only behavior. Note that I say "most straightforward", not "easy".
Personally, I don't see any viable *business* road for this, but happy to read some fan fiction on that.
I think you'd be surprised! There are some big names using it at scale[1].
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.
Or vice versa, do you use RN-Web or plan to?
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.
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.
Recently, I really enjoy running containerized apps locally and accessing the GUI as a website on localhost. It feels like there’s a lot of room to build on that model.
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.
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.
You asked from cross platform UI framework, not for abstracted away mobile development framework.
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.
What you built looks nice and I'm sure it works well for many classes of apps though.
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.
When did you last try it? Because it’s improved dramatically since January.
But of course you have to compare it to the alternatives.
Aka have you tried to build a SwiftUI app? There’s endless problems. And then you have to rewrite your whole app three times.
Building any app will leave you delirious, but I’ve found myself far more productive in React Native than the alternatives - and I’ve tried them. I would happily challenge anyone to ship a cross platform app using their framework of choice and compare on time to ship and ultimate UX. I think there’s a clear winner.
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.
It feels like Apple’s reflexive parochialism is limiting their influence, and that is something only leadership could overturn. I doubt they feel any financial incentive to do so.
I think with the target audience for this, you should just go immediately to the newer version[1].
> 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.
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.