14 ms·
SwiftUI tutorials rewritten completely
- bitcurious 6y ago> https://news.ycombinator.com/item?id=25046691 https://news.ycombinator.com/item?id=25046691 Some relevant discussion.
- Austin_Conlon 6y agoYes it's unfortunate that these tutorials and WWDC transcripts are effectively the replacement of core documentation, regardless of their quality. Overviews, code listings, and conceptual docs are being added, but at a slow pace and it's hard to find which ones have been updated outside of some people posting about it on Twitter.
- egonschiele 6y agoCool, but this documentation wasn't really the issue. Apple seems to be taking the tack of explaining a few core concepts really well while ignoring the long tail of documentation. Why are there questions like this[1] on Stack Overflow? That's a clear sign that other documentation is lacking. [1] https://stackoverflow.com/questions/65173861/saving-a-file-to-icloud-drive https://stackoverflow.com/questions/65173861/saving-a-file-t...
- favorited 6y agoThere's certainly a lot that could be said about the gaps in Apple's developer docs, but the answer to that question is literally, "handle your errors instead of ignoring them, and it will tell you what went wrong." They ignored errors, so didn't know there was no "Documents" directory, and their file write therefore failed.
- timtimmy 6y agoIs it my imagination or has Apple been quietly improving and expanding the documentation for SwiftUI over the last few months? It's becoming decent, though there are still dark corners. Apple used to be awesome at documentation. I hope this effort extends to Apple's other frameworks.
- Austin_Conlon 6y agoIt's been expanding ever since the WWDC 2019 release, same with other newer frameworks like Combine, and it mostly goes unnoticed. They should have some way of showing what docs have been updated, currently in the Apple Developer app I think it only highlights new articles.
- extraduder_ire 6y ago>They should have some way of showing what docs have been updated Back when I used wrote iOS crap, I used dash as a quick reference for APIs.That was pretty good at alerting me to documentation changes, since it has to download an update. https://kapeli.com/dash https://kapeli.com/dash I only started using it (never did buy it) because I was used to using zeal, a free-software alternative. https://zealdocs.org/ https://zealdocs.org/
- torarnv 6y agoI like Dash, I bought it. But unfortunately the version upgrade from 4 to 5 introduced some mandatory UI changes that made documentation lookup much more cumbersome. Looking up a function now takes several user interaction steps, instead of just one in Dash 4. I'm still on version 4. If anyone have alternatives, I'm all ears.
- nhojb 6y agoYeah, I feel the same way about Dash 5. Eventually had to upgrade to 5 when 4 became incompatible with the latest Apple docets. But I much preferred the Dash 4 search.
- wool_gather 6y agoThe developer of Dash is very receptive to feedback (in fact I think this change was called out as something that he was interested in hearing opinions on).
- nanagojo 6y agoMan I wish Xcode was a decent IDE
- an_opabinia 6y agoIf there's anything you can credit the Google team for, it's using IntelliJ as the basis of the Android IDE.
- pjmlp 6y agoWhich is one of the reasons I am happy not having to deal with it every single day. Android Studio requires a gaming rig to run properly, Android developer forums are filled with discussions on how to not use it in pain.
- jolux 6y agoIntelliJ is amazing though.
- Aaargh20318 6y agoI would have preferred them sticking with Eclipse. Sure, the Android plugins for Eclipse were pretty bad, but that was all Googles fault. They could have just fixed their plugins.
- Jakobeha 6y agoI used Xcode recently and it's gotten a lot better. It's still not as good as IntelliJ or AppCode but it's usable. I remember around when Swift came out, Xcode was so bad that I couldn't even use it because typing was ~1 character/second and it would crash every few minutes. It's definitely recovered from that and I can actually type without lag now.
- pavlov 6y agoXcode had no such problems with Objective-C though... Maybe Swift's design deserves some blame here for years of subpar developer experience.
- spideymans 6y agoThis is so much better than the old guide. Highly recommend following along even if you’re familiar with SwiftUI. At a bare minimum, it’s a gentle introduction to some non-obvious (and perhaps undocumented) best practices. This guide would’ve saved me countless hours had it been available in the summer.
- friedman23 6y agoI'm actually learning swiftui and finished the old version of the tutorial a few days ago. I'm glad they are fixing up the documentation. SwiftUI is pretty powerful, you can make really nice "cross platform" (within the mac ecosystem) apps.
- rubicon33 6y agoWhy learn SwiftUI? If you want a declarative UI framework wouldn’t you be better served for your time to learn something like React Native or Flutter? I’m not trying to knock SwiftUI, I am genuinely curious what the value proposition is for anyone considering it...
- amw-zero 6y agoBecause it’s native to the platform. Seriously, that’s huge. The React Native toolchain is cumbersome to say the least. There’s something to say about a first-class library, meaning one that is being used exactly as designed. I mean, why do people use Javascript? Because it’s the native language of the browser.
- rubicon33 6y agoYea I don’t disagree, but what development team has the luxury of choosing SwiftUI? Most places hiring are looking for cross platform “2 developers for the price of one” ... and the burden of dealing with cumbersome react native falls on the developer.
- PandawanFr 6y agoI'm guessing companies that have the resources to go with two separate development teams for each platform will tend to go for that route since it leads to better performing applications. e.g. FB Messenger's blog post about going back to native after using React Native.
- bartvk 6y agoI make my money by doing internal projects for companies. These organizations run their own app store, or just force-download their apps onto all of their iOS devices. It's lovely to focus on one platform.
- Aaargh20318 6y agoIn my experience, cross platform development only works for simple apps. If all you’re doing is fill in some forms and update a database, sure, go with a cross-platform toolkit. If you’re doing anything more complicated than that, the productivity gains diminish quickly to the point where it’s easier and faster to just build to native applications.
- keyle 6y agoQuestion, is it doable on Mojave? I can't lose 32 bits apps.
- buggycoder 6y agoSuper cool!
- lenkite 6y agoIs SwiftUI just an abstraction over AppKit and UIKit ? Does it bring any widgets of its own - ie something native to SwiftUI as opposed to being wrapped ? (apart from the declarative stuff)
- wlesieutre 6y agoIt can draw stuff directly rather than going through UIKit. Example via WWDC by Sundell: https://wwdcbysundell.com/2019/swiftui-relationship-to-uikit-appkit/ https://wwdcbysundell.com/2019/swiftui-relationship-to-uikit... struct ContentView: View { var body: some View { VStack { ForEach(0..<3) { _ in HStack { Text("Leading") Text("Trailing") } } } } } > Looking at the above code sample, it’s easy to jump to the conclusion that the resulting UI will consist of a vertically aligned UIStackView — which’ll then contain a set of horizontally aligned, nested stack views, which in turn each will contain two labels rendered using UILabel. However, none of those assumptions are actually true — as SwiftUI instead draws our labels directly using the private CGDrawingView class.
- mrtksn 6y agoI don’t think so, the look and feels is different. Under the hood it will use some UIKit like UIScrollView but the whole architecture is different. On UIKit, the objects you create stay retained as long as they are used and all you do is to change properties when using. On SwiftUI, everything is released and retained every time there’s a change. That’s why you need to address the life cycle differences when you use UIKit and SwiftUI together.
- ericlewis 6y agoSometimes yes, sometimes no. For most things, no.
- Grustaf 6y agoThat’s not really the right question to ask. Yes in some cases it is backed by UIKit, for now, but that can change at any time. It is a completely new paradigm, that’s it. Implementation details are just that.
- vlozko 6y agoOh wow, I personally know someone who joined the dev pubs team to work on this documentation. I think a big factor in the improvements was their hiring practices. Traditionally Apple has required that employees be on-site. Their dev pubs team is a notable exception and a signify part of that team is remote.
- wil421 6y agoWhen has Apple traditionally required employees to be on site? I know a few people who have worked remote at Apple for over a decade.
- baby 6y agoKnow a bunch of people working remotely for Apple too
- madeofpalk 6y agoMy understanding - as someone who knows nothing but just read tweets - is that hiring strongly prefers on-site, whereas tenured employees are usually able to negotiate remote work.
- ksec 6y agoApple makes exceptions to exceptional people. I mean, OSX x86 port started with a remote engineer.
- deleted 6y ago[deleted]
- pwinnski 6y agoThey've tended to prefer onsite, though I've known of exceptions for as long as I can remember. I interviewed with them in early 2019, and it came down to me and one other person, but I was remote and the other person was in-person. After some back and forth, they went with the other person and told me it was because I would be the second remote person on that team, both hired around the same time, and that nudged them toward the other candidate. Now everybody is remote, so... fortunately, I'm happy where I ended up instead.
- mike_timko 6y agoHow did you find this tutorial? I can't seem to find it by navigating on the developer site.
- Austin_Conlon 6y agoA friend sent me this Tweet: https://twitter.com/zntfdr/status/1338423623149707265?s=21 https://twitter.com/zntfdr/status/1338423623149707265?s=21.
- dep_b 6y agoSo far dealing with stuff like PayKit SwiftUI integration still feels really bad. There's just tons of stuff expecting UIKit and it will take a while before all of that stuff is ported. SwiftUI is really great, Combine can be hard to get into for people not initiated in Reactive and generally it's as fast to build stuff in as Flutter without dealing with the tragedy called Dart.
- radiKal07 6y agoWhat is wrong about Dart? I come from a Kotlin background and I don't see anything wrong with Dart honestly
- pjmlp 6y agoFailed to take over the Web as Chrome team was driving it, then ChromiumVM got dropped, several key designers like Gilad Bracha and Lars Bak left the project, it was ultimely rescued by AdWords team, which had just migrated away from GWT into Dart, got rebooted into a strong typed language with type inference, and picked up by the Flutter team. Nowadays it is basically a language to write Flutter applications, hardly worthwhile to bother using it for anything else. Flutter is taking place on Google politics, while Google lets Flutter, JetPack Composers and PWAs play the game of cross platform GUI frameworks, with the difference that Kotlin and JavaScript/TypeScript have a much broader eco-system than Dart.
- jamil7 6y agoIn my opinion it's not an especially compelling language (yet maybe it evolves into one) and is useless outside of Flutter. It feels shoehorned into the project because Google wanted to find a use for it. It simultaneously alienates mobile developers and cross platform developers by picking a language neither have experience in and neither can use outside of this one framework. There are people taking about Flutter being to Dart what Rails was to Ruby so maybe time will tell. Flutter itself seems decent though, despite a few oddities.
- dep_b 6y agoThe compile time guarantees could have been much better, especially around null pointers. Now they're hacking in non-nullability the same broken way they did it in Java. Same goes for a lot of things like switch / case statements requiring breaks but not supporting checks for covering all cases compile time. In general it just feels like old Java spiced up with some Javascript niceties like Futures and a nice constructor syntax. But you should've noticed that coming from Kotlin? Why wouldn't they use Kotlin as most mobile developers are already used to it?
- saargrin 6y agothe original ones on release were awful for sure
- mathewsanders 6y agoIt’s pretty cool that from the very first step that they are introducing how to use accessibility modifiers to improve support for voice over.
- Razengan 6y agoSwiftUI’s support for accessibility is pretty amazing, way ahead of any other framework I know of and takes minimal effort to adopt too from the examples I saw at WWDC.
- oaiey 6y agoI am impressed by the visualization and guidance giving in that tutorial. Good library documentation is really hard work but can be also super easy (looking). Check e.g. RabbitMQ tutorials. So nice.
- gman83 6y agoIs SwiftUI open source?