20 ms·

SwiftUI

765 points by fphilipe 7y ago

sdegutis 7y ago
So React.js but native and in Swift? I'm hesitant but hopeful. Tutorial: https://developer.apple.com/tutorials/swiftui/ https://developer.apple.com/tutorials/swiftui/
sz4kerto 7y ago
To me this looks very similar to what Google is doing with Flutter.
- pjmlp 7y ago
  Jetpack Composer you mean. I bet by next IO, Flutter will get replaced by it, specially after the #KotlinEverywhere announcement and Kotlin/Native effort for iOS.
  - mythz 7y ago
    No he means Flutter which has been around a lot longer, it's immediately what I've thought of being inspired by as well: https://flutter.dev/docs/development/tools/hot-reload https://flutter.dev/docs/development/tools/hot-reload
    - pjmlp 7y ago
      I know pretty much what he/she meant, was just making a point that I don't believe in Flutter's long term success. Trying to sell Dart a 2nd time was a mistake.
      - mythz 7y ago
        Flutter's not a PR campaign for Dart, they're a separate project that chose Dart based on its technical capabilities [1]. Given Flutter enables the nicest native x-plat dev experience today I'd say it has a very bright future, which they've also recently announced Flutter for Desktop and Embedded devices. Jetpack compose is years away from the same kind of x-plat support that Flutter's providing for Mobile, Web, Desktop and Embedded [2]. [1] https://flutter.dev/docs/resources/faq#why-did-flutter-choose-to-use-dart https://flutter.dev/docs/resources/faq#why-did-flutter-choos... [2] https://developers.googleblog.com/2019/05/Flutter-io19.html https://developers.googleblog.com/2019/05/Flutter-io19.html
        pjmlp 7y ago
        That after-the-fact reasoning link that gets posted every time someone questions Dart is well known, no need to give it to me. Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "technical capabilities". Flutter is a way to rescue Dart, plain and simple. Yes, Jetpack Compose might be doing its baby steps, but I am betting most developers are more keen in having Kotlin than Dart on their CV, specially after Dart v 1.0's demise. And Android team surely has more political power, given ChromeOS and Fuchsia adoption of ART.
        mythz 7y ago
        > no need to give it to me. Think highly of yourself much? But I'll be continuing to provide links as I see it's relevant and informative, my comments are not just for your benefit, readers can make their own mind whose opinions are more informed - "no need" to tell others how to comment. > Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "technical capabilities". Am I meant to be impressed by this list of languages? I'm not. Are the number of languages meant to give your inexperienced opinion on Flutter's development environment some credence or is this washy strawman meant to downplay anyone else's opinion who wasn't a developer in the 90's when these languages were more relevant? What matters is what's relevant now and Flutter lets you build modern x-plat Mobile, Web, Desktop and Embedded Apps with productive Live Hot Reload environment that's both fast at development and runtime which can be run in a JIT VM, as AOT compiled or transpiled to tree-shaken JS. Which of these above languages provides a more productive and "technically impressive" environment to develop iOS/Android, Web and Embedded Apps than Dart/Flutter? > Flutter is a way to rescue Dart, plain and simple. Adding "plain and simple" to an baseless opinion doesn't re-enforce it, including links that backs up this wild speculation will. What information have you used to be able present this opinion as fact so staunchly? Do you really believe Google invented and funded the Flutter project out of thin air to give Dart a popularity boost? > And Android team surely has more political power, given ChromeOS and Fuchsia adoption of ART. How can Android have more political power for Fuchsia than Dart which is what most of its UI is written in? You can also develop Flutter Apps on Chrome OS so that's no different. Chrome OS is still primarily a Web OS, allowing running Android Apps doesn't make it an OS for running Android Apps and devs aren't going to be lining up to develop Chrome OS Apps using Android. Flutter's strength's is that you can develop x-plat App's that looks, behaves and runs natively on all its supported platforms - feel free to wait until Kotlin reaches the same maturity on iOS before declaring it a Flutter killer. Kotlin still suffers from Android's complicated and fragile tooling and from what I've seen with JetPack compose it's highly coupled to Android - it's going to take a long time before they'll let you build iOS/Android Apps from a single code base.
  - burky 7y ago
    Flutter is cross platform. I looked for it but didn't see where jetpack has this capability. Please post me a link if I’m wrong, I would follow this project if it does support cross platform development.
    - arusahni 7y ago
      Jetpack Compose was announced at IO: https://blog.karumi.com/android-jetpack-compose-review/ https://blog.karumi.com/android-jetpack-compose-review/
  - HillaryBriss 7y ago
    It looks like Jetpack Compose is not really done yet. It's pre-alpha and the Jetpack Compose doc page says don't use it for production. https://developer.android.com/jetpack/compose/ https://developer.android.com/jetpack/compose/ I may be missing something, but SwiftUI seems to be pretty much ready to go today.
    - pjmlp 7y ago
      You are missing the fact that Android team doesn't want to have anything to do with Dart, and started a Kotlin everywhere initiative, including iOS via Kotlin/Native.
    - rhodysurf 7y ago
      Except it’s not ready to go because it’s not backwards compatible it seems.
    - myko 7y ago
      Ready to go today if you're only supporting iOS 13+ Which for most companies is 2+ years away
      - HillaryBriss 7y ago
        I stand corrected. thanks.
      - HillaryBriss 7y ago
        To add a bit more detail: the required level for other Apple OSs are macOS 15+, tvOS 13+ and watchOS 6+.
- itp 7y ago
  Indeed, but (unsurprisingly) Apple-only.
- saagarjha 7y ago
  But native, of course.
  - tootie 7y ago
    And proprietary.
- mmargerum 7y ago
  Flutter doesn't use native controls . It draws everything. Just pointing out that difference.
  - pier25 7y ago
    Native controls aren't drawn too?
    - HillaryBriss 7y ago
      yes, they're drawn too. but, i think what the above comment is pointing out is that Flutter itself does the drawing, instead of delegating the drawing to iOS or Android native widgets.
      - mmargerum 7y ago
        More than just drawing. They have to reimplement all of the behaviors of the built in controls. I'm sure google is up to the task, but my experience has been there's always things missing and and lag behind native .
        kartickv 7y ago
        > there's always things missing and and lag behind native Flutter specifically or cross-platform UI frameworks in general? I don't mind it being different, but does the app feel unpolished?
      - pier25 7y ago
        Actually no, Flutter doesn’t do the drawing. It’s done by Skia, much like Cocoa native controls are drawn by Quartz. There isn’t much of a difference between Flutter controls and native controls, other than being a reimplementation in some cases.
        mpweiher 7y ago
        > other than being a reimplementation in some cases. Hmm...that's pretty much the entire difference between native and non-native controls.
- dep_b 7y ago
  It does, in a good way. I really liked Flutter's UI approach.
- jswizzy 7y ago
  Jetpack Compose is more like it
bilal4hmed 7y ago
Looks a lot like Flutter
Apocryphon 7y ago
Can this retroactively support apps targeting iOS 12 and older?
- aerialcombat 7y ago
  probably not
- cududa 7y ago
  What do you think
- favorited 7y ago
  No. One of the engineers said on Twitter it is a system framework.
- scarface74 7y ago
  The only devices you lose by supporting iOS 13 and not iOS 12 are the iPhone 5s from 2013 and the 6th generation iPod Touch from 2014. iOS users update pretty rapidly.
  - saagarjha 7y ago
    iPhone 6 does not have an iOS 13 IPSW on the developer downloads site. iPad Air and the second and third generation iPad Mini were dropped as well.
    - scarface74 7y ago
      Didn't realize that they dropped the 6 and 6 Plus.
chadlavi 7y ago
The question the whole web asks now: what does this mean for React Native devs
- gmemstr 7y ago
  I bet it's going to stay relatively the same, for now. React Native still works across iOS and Android, which is one of the key features. SwiftUI is iOS only.
  - chadlavi 7y ago
    It's my understanding that a lot of the appeal of RN is also that it allows web devs who are fluent in JS to make mobile apps, so I guess that's not really comparable in SwiftUI either.
    - nicoburns 7y ago
      I'm not sure about that. SwiftUI code looks an awful lot like React code. And IMO (as a web dev), it was always learning the UI framework that seemed like it would be the difficult part of learning iOS dev. Data manipulation APIs are pretty similar in most languages, but learning a new UI paradigm is a pain...
      - lghh 7y ago
        Yes, but alongside learning SwiftUI they will also have to learn whatever is going on in Android land because it's not cross platform.
  - ihuman 7y ago
    > SwiftUI is iOS only It's also on macOS
    - TheOtherDave 7y ago
      I think it’s on tvOS and watchOS, too.
fphilipe 7y ago
Personally, as an iOS developer, this is by far the biggest announcement. Haven’t had the chance to dig deeper, but the comparison between the UITableViewController and that snippet containing just declarative code looks absolutely promising. The only downside is that we’ll have to wait one or two years before we can use it if older iOS versions still need to be supported. Let’s hope for extra quick adoption of iOS 13.
- sim_card_map 7y ago
  Do you have a link to the comparison?
  - dmix 7y ago
    It was during the event, they just displayed an overly dramatic LOC comparison on the screen between a few page-downs on a longer Swift file, then the next screen showed a ~10 line block of code which does the same thing. Followed by the standard audience applause. The livestream hasn't been uploaded yet but I'm sure you could find it in one of the live blogs.
    - saidajigumi 7y ago
      Part of that comparison (on the "before" side) was a bunch of Cocoa autolayout code. It's verbose and annoying, only mitigated if you're using Interface Builder, which has its own significant downsides. If the declarative form in SwiftUI supports a saner approach to managing and adjusting layout, then there's absolutely nothing overdramatic about that comparision. It's a potential game changer.
    - sim_card_map 7y ago
      Thanks! Indeed it's impressive.
- eugeniub 7y ago
  Unfortunately, iOS 13 drops support for iPhone 5s and iPhone 6.[1] Last year, iOS 12 didn't drop support for any devices. The iPhone 6 is a very popular device, and was still sold by Apple less than two years ago. [1]: https://iosref.com/ios/ https://iosref.com/ios/
kylemacomber 7y ago
I’m one of the engineers that spearheaded this initiative inside of Apple. I just wanted to thank the HN community—I’ve been reading HN for 10 years now and it’s been formative in my development as a software engineer. If you’re at WWDC stop by the labs and say hi!
- sdegutis 7y ago
  How would you compare this to React.js? In particular, how does SwiftUI approach the concepts that Redux solves [EDIT: in other words, state management]?
  - rat9988 7y ago
    Redux and react are two different questions.
    - sdegutis 7y ago
      When people make alternatives to React, at some point they have to address the concept of state changes and side-effects, building in conveniences for it, or leaving it for third parties to develop this area.
      - nickbauman 7y ago
        ... Or use something like Reagent where there is language level support for reactive state management using atoms. https://github.com/reagent-project/reagent https://github.com/reagent-project/reagent
        sdegutis 7y ago
        That looks like exactly what SwiftUI is doing.
      - ng12 7y ago
        This has nothing to do with Redux. Redux is about storing global data, nothing more.
skohan 7y ago
I hope it still supports low-level control when you need it.
- bendixso 7y ago
  Yeah, I have the same concern. This is great for those situations where declarative works but sometimes you really want to get low-level and do some custom stuff with imperative code. I suppose we can use the old frameworks for that?
- teilo 7y ago
  Looks like it shifts the focus toward developing more intelligent components. They mentioned custom SwiftUI components a few times in the demo. This is one of the things I am eager to get a deep dive on in later session videos.
- seanalltogether 7y ago
  Well the docs say you can chain an id() property on any view being built in the tree which would hopefully allow you to reference it at runtime and insert/delete children, but I don't see anything obvious for assigning that id to like an outlet so you don't have to traverse the whole tree to find it.
jpochtar 7y ago
fmr founder of Pagedraw here... this looks amazing. I wish we'd built it! :)
stefan_ 7y ago
Apple developers will be glad they get to rewrite their entire application with a new UI framework and paradigm or risk their apps looking garbage on the platform (and stop working by next release). This must be the .. fifth entirely new UI framework from Apple?
- vbezhenar 7y ago
  I don't think that's true. It seems to be higher-level framework based on Cocoa Touch. Existing apps will work just fine. And probably any real world app will have to deal with Cocoa Touch as well, like any real React app have to work with DOM.
- deleted 7y ago
  [deleted]
- rimliu 7y ago
  That's a lot if pointless FUD.
- jaegerpicker 7y ago
  This isn't true at all. Since iOS launched there has been UIKit and then this SwiftUI.
  - grey-area 7y ago
    This must be the .. fifth entirely new UI framework from Apple? This isn't true at all. Since iOS launched there has been UIKit and then this SwiftUI. They didn't say anything about iOS. There have been lots of UI frameworks from Apple, some abandoned before they were even finished: QuickDraw, Quickdraw GX, HIToolbox, AppKit, Cocoa Touch/UIKit, Playgrounds/IB, SwiftUI The constantly changing frameworks and languages are a useful strategy from platform vendors - they do help provide platform lockin, and make it very very difficult to provide cross platform apps. That is a real threat to Apple with offerings like flutter from Google. Of course there are other reasons to make a clean break with the past, but there is a lot of work just to stand still in developing for a platform like Mac OS or IOS - they don't highly value backwards compatibility and often introduce sweeping changes. Constant change is in the platform vendor's financial interest, and I don't think it's unfair to point that out. Just to take one example - apps built for the original iOS are now almost entirely obsolete, and it's not worth reusing any of their code in a modern swift app.
jcelerier 7y ago
The syntax example is still not as clean as QML, which is already a ten-year-old language (examples: http://qmlbook.github.io/ch04-qmlstart/qmlstart.html http://qmlbook.github.io/ch04-qmlstart/qmlstart.html).
- aseipp 7y ago
  Depends on what you mean by "clean". I'd say it's pretty good from what I can see? The examples are also incomparable; the one you link to is nearly 20 lines of code to define nothing more than an embedded triangle image and single text embed with a few colors, while the Swift example hosts an entire modal list with embedded picture components and text (while handling fluid scrolling, right-to-left langs, dark mode theming, etc all implicitly) -- all in the same number of lines or so (and had further mods made during the Keynote by a developer with similar brevity.) Judging from lines only or "cleanliness" I'd say SwiftUI is doing pretty good here, but ultimately the examples are too apples and oranges to draw any real conclusions from. Syntax aside, there is a large semantic difference between the two: QML is a separate language/modeling tool that is embedded into the application runtime. SwiftUI is in fact ordinary Swift code and the UI you define with it is also ordinary Swift code too, code that XCode and the Swift compiler understand and analyze and refactor and compile like any other. Just with some special magic to make the UI builder work with it. I think this has a lot of advantages notably from a toolchain perspective, since you don't even need XCode (just the Swift compiler) to do things like xrefs/refactorings across SwiftUI code, nor maintain tooling like that across two languages (XYZ + whatever UI modeling language) Given that, my first impressions of how far they took it (and how well it came out) are pretty good.
  - stabbles 7y ago
    > while the Swift example hosts an entire modal list with embedded picture components and text (while handling fluid scrolling, right-to-left langs, dark mode theming, etc all implicitly) I think you might check out more of QML / QtQuick 2 before drawing any conclusions. import QtQuick 2.12 import QtQuick.Layouts 1.12 ListView { model: Model.items delegate: RowLayout { Image { source: image } Column { Text { text: title } Text { text: subtitle color: "gray" } } } } This should be more or less the same. Fluid scrolling is backed by the underlying Flickable [1]. RTL support is available an can be changed in runtime [2]. Themes / colors can be changed in runtime as well [3]. Lastly, it runs on Windows, Linux and Android as well as OSX and iOS. [1] https://doc.qt.io/qt-5/qml-qtquick-flickable.html https://doc.qt.io/qt-5/qml-qtquick-flickable.html [2] https://doc.qt.io/qt-5/qtquick-positioning-righttoleft.html https://doc.qt.io/qt-5/qtquick-positioning-righttoleft.html [3] https://doc.qt.io/qt-5/qtquickcontrols2-styles.html https://doc.qt.io/qt-5/qtquickcontrols2-styles.html
TheRealDunkirk 7y ago
Other than a few-hour intro seminar on building iOS apps, almost 10 years ago, I've never written anything in Swift. The announcements around it today got the biggest reactions from the crowd. Is is really great, blasé, or too early to tell?
- saagarjha 7y ago
  It’s too early to tell, but it’s certainly very exciting.
- JimDabell 7y ago
  It's probably the biggest shakeup to Apple's developer platform since Swift was announced.
- teilo 7y ago
  You were not using Swift 10 years ago, or even almost 10 years ago. It was released in 2014.
  - TheRealDunkirk 7y ago
    Ah, now I see the reason for the downvotes. I just meant "Apple's language for doing iPhone apps," and, of course, that was Obj-C back then. I haven't thought about it since.
oflannabhra 7y ago
This is fantastic, and I am almost upset by how little info the keynote address included. Obviously there will be a ton of detail coming out this week with the labs and documentation being released, looking forward to that. As an iOS developer, this is by far the biggest announcement. This has huge potential to provide value to me and my team. I'm looking forward to ripping out programmatic NSLayoutConstraint and Interface Builder from my projects ASAP. This seems like it includes much more than that, however.
- kennywinker 7y ago
  Details will be in the Platform State of The Union later today. Keynotes are always press/casual-fan focused
- Jerry2 7y ago
  The "real" developer keynote is "Platforms State of the Union" which will surely cover a lot more of it. The morning keynote is for the press and executives to highlight latest releases with some dev stuff thrown in.
  - ehsankia 7y ago
    Yeah, it's similar to I/O where there's a separate developer keynote, and specific "State of the Union" talks for each platform/framework.
azhenley 7y ago
.color(.gray)) What object is .gray acting on?
- didgeoridoo 7y ago
  That syntax is a shortcut for UIColor.gray, so this is really: .color(UIColor.gray)
  - JimDabell 7y ago
    I would expect it's the grey static member of SwiftUI's Color struct: https://developer.apple.com/documentation/swiftui/color/3049710-gray https://developer.apple.com/documentation/swiftui/color/3049...
- kennywinker 7y ago
  That’d be standard swift type inference. The .color function takes a single unnammed parameter of type Color (or similar, idk exactly). Color.gray is a static constant value. So .color(Color.gray) can be simplified to .color(.gray)
  - steve_adams_86 7y ago
    Huh, that's actually a great way to do type inference. Swift seems like an excellent language.
- deleted 7y ago
  [deleted]
- auggierose 7y ago
  that's shortcut syntax for an enumeration case where the type of the enumeration can be inferred
  - favorited 7y ago
    It's not just for enums. It works for any static variable on a given type. So you can say .gray and have it map to NSColor.gray, etc.
untog 7y ago
I'd be curious to know how many React Native devs work on cross-platform apps. In casual conversation I've had it actually isn't that high, despite it being one of the central promises of RN. Given that SwiftUI has live reloading and a sensible template interface I could absolutely see it winning over some RN devs. There's something to be said (particularly with Apple) for using the native toolset rather than RN, Flutter and the like.
- deleted 7y ago
  [deleted]
- wtetzner 7y ago
  > In casual conversation I've had it actually isn't that high, despite it being one of the central promises of RN. But applications written in React Native aren't cross platform, are they? You have different components depending on the platform. My understanding is that they claimed you wouldn't have to learn a different framework when switching to a new platform, not that your apps would be portable.
  - zwily 7y ago
    You can share components but have to carefully handle any platform-specific code.
  - k__ 7y ago
    I built cross-platform apps with it. It works by supplying me with native modules and native components for every platform and I write my domain logic in portable JavaScript.
  - joshjhargreaves 7y ago
    Applications written in React Native typically are cross-platform; saying that they are not is a pretty large misrepresentation of the framework. At its base React Native provides a common set of native components with the same API on both iOS and Android such as View, Image & Text which can all be styled and laid out through common APIs. These APIs pretty much give you most of what you need to make an entire APP. Sometimes you may want to have different behavior per platfrom and for that you can use the Platform API (provided by React Native) to switch for each platform. This would allow you to do things like change the styling on each platform or the native components you use. React Native makes it pretty easy to expose native components to JavaScript. It is also up to the native component author if they want to create a common API for all platforms that they support. In the case of Views & styling it makes a lot of sense to have the same API on iOS and Android, but sometimes they are some platform features that are only available on one platform. Wile Swift Layout is not cross-platform, it may soon be and I think it does a lot for promoting declarative UI & maybe they did take some inspiration from React! View docs: https://facebook.github.io/react-native/docs/view.html https://facebook.github.io/react-native/docs/view.html Styling: https://facebook.github.io/react-native/docs/style https://facebook.github.io/react-native/docs/style Layout: https://facebook.github.io/react-native/docs/flexbox https://facebook.github.io/react-native/docs/flexbox
thomasjames 7y ago
Interesting move we see from the big players to more declarative UI toolkits. First Flutter, now this.
- ognarb 7y ago
  Don't forget qml
  - mmckeen 7y ago
    Yeah, it's a shame people are praising these new frameworks but forget similar ones that have been around and rocking for years.
- pzo 7y ago
  You have to give credit to react time which seems that started this paradigm of declarative and reactive ui frameworks. After that you got react native, flutter, jetpack compose and now swift ui. As for declarative (but not reactive) ui prior art is also Qt qml.
  - thomasjames 7y ago
    Both looked kind of like GTK (in a non-verbose language like Python) to me, too. Maybe I am seeing things.
  - sandeepc24 7y ago
    Also have a look at https://fsprojects.github.io/Fabulous/ https://fsprojects.github.io/Fabulous/
mikece 7y ago
I was fully expecting something along the lines of "Oh, and SwiftUI will compile to WebAssembly allowing your apps to look just as awesome and run just as fast in Safari." Probably still in alpha...
- saagarjha 7y ago
  Why would Apple want these apps to run in Safari? They have a platform to run these already.
  - mikece 7y ago
    Safari isn't the point -- running on other platforms is. Market share for iOS globally is nowhere close to Android; in India iOS is only about 10% so if your SwiftUI app could run in Chrome on Android and is installable as a PWA, you open up the rest of the handset market.
    - donarb 7y ago
      SwiftUI is not just for iOS, it's for MacOS, tvOS, iPadOS and WatchOS as well. That covers well over a billion devices with all kinds of apps.
    - saagarjha 7y ago
      Apple doesn’t really care about you being able to run your UI code on those platforms.
      - mmargerum 7y ago
        True. in fact they have a vested interest in not making this happen, but someone will. This looks really impressive and i've grown to like swift quite a bit.
lisardo 7y ago
It’s nice to finally see a FRP framework for iOS like React/Elm. MVC must die already.
- seanmcdirmid 7y ago
  How is this like FRP, React, or Elm (each of those things being fairly different themselves). SwiftUI actually reminds me of JavaFX when done with JavaFX Script (ahead of its time by too much), but I haven't been able to dig up a lot of examples from their website yet.
- steve_adams_86 7y ago
  FRP and MVC seem like different types of patterns to me. Functional reactive is about how you manage state and flow while MVC is largely about separation of concerns. In my (possibly poor) understanding, you could actually use them together. I'm interested in your take on that though. I'm self taught and I've got some weird ideas about things.
- ch4s3 7y ago
  Elm isn't FRP anymore [1], it uses some sort of process and scheduler model behind the msg system. React isn't FRP either, though you can approximate higher order FRP with Redux if you want. [1] https://elm-lang.org/blog/farewell-to-frp https://elm-lang.org/blog/farewell-to-frp
chkgk 7y ago
I didn't catch it. Is Xcode 11 (beta) available already? Do I need macOS Catalina (beta) to run it? I seem to have missed the crucial information and cannot find it on apples developers pages...
- saagarjha 7y ago
  https://developer.apple.com/download/ https://developer.apple.com/download/
  - chkgk 7y ago
    Thank you, but that's how far I got myself. It is telling me there are no downloads available at this time. I am asking, because I am still on 10.14.5 and I thought the Xcode 11 beta might only be available on the 10.15 beta.
    - DelightOne 7y ago
      Under Applications now: Xcode 11 beta
    - saagarjha 7y ago
      Check the “Applications” tab, the Xcode download is there (they redesigned the page, which makes it IMO worse). No idea if it runs on Mojave, but I would think so based on history.
    - mthoms 7y ago
      The XCode 11 "whats new" page [0] says: >To use the SwiftUI design canvas Xcode 11 must running on macOS Catalina. Please let us know if you find that's incorrect. [0] https://developer.apple.com/xcode/whats-new/ https://developer.apple.com/xcode/whats-new/
- gschrader 7y ago
  The direct download is here: https://developer.apple.com/services-account/download?path=/WWDC_2019/Xcode_11_Beta/Xcode_11_Beta.xip https://developer.apple.com/services-account/download?path=/... for some reason my account only shows "There’s currently no beta software available for download."
Redoubts 7y ago
var body: some View { Wait, what? When was `some` a keyword?
- skohan 7y ago
  It's part of generalized existentials, a forthcoming language feature.
- saagarjha 7y ago
  It’s part of Swift 5.2: https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md https://github.com/apple/swift-evolution/blob/master/proposa...
- alexjm 7y ago
  It's part of opaque types, which are new in Swift 5.1 https://docs.swift.org/swift-book/LanguageGuide/OpaqueTypes.html https://docs.swift.org/swift-book/LanguageGuide/OpaqueTypes....
- ardit33 7y ago
  I am still scratching my head why the 'some' keyword is needed/required for opaque types. Eg. SquareButton and RoundButton are implementations of the Button (protocol). You want to create a function that returns the button, but you don't want to specify to the user exactly what type of button is it (as it doesn't matter). Your function could just declare the top level protocol as the return type without needed to specify the word "some" createPlayButton -> Button instead of createPlayButton -> some Button Am I missing something? It feels like the 'some' keyword is just there to help the compiler and not the users necessary it seems like the equivalent of id <MyProtocol> in Objective-C. Basically just a surface re-arranging of names, but keeping the same concepts as in Objective-C I feel Golang did better in this regards... (eg. not necessary distinguishing between protocols and super class-es, it is quacks like a duck, it is a duck)
  - skohan 7y ago
    The difference is subtle but it's there. The "some" keyword indicates that the function returns a specific type, even if that type isn't known to the caller. One place where this is meaningful is if you have to use the result of that function in a generic function. For instance if my functions are defined like this: func createPlayButton() -> Button { ... } func doSomething<T: Button>(_ button: T) { ... } And I try to call this: doSomething(createPlayButton()) I will get an error, because the protocol Button does not conform to itself. However If I use opaque types: func createPlayButton() -> some Button { ... } this works just fine because the compiler is able to determine the concrete type returned by `createPlayButton`
checker659 7y ago
One more blow to the head for objective-c. Wonder if this the final nail in the coffin.
- mmargerum 7y ago
  It certainly gives me a reason to migrate now. Swift alone wasn't enough of a reason.
- protomyth 7y ago
  Given that Craig Federighi basically said this type of migration only comes around every 20 years, I would imagine Objective-C is dead. I do hope they actually take the time and fix the Swift examples so they are updated. This does hurt. I've been programming Objective-C since NeXTSTEP and love it. Swift is still like Perl for me. Something I will use for programming for money, but not enjoy for one minute. I loved the clarity of selector syntax, but Javascript clones rule the world. I still don't understand the love of commas or why they are needed.
  - adamnemecek 7y ago
    How is swift a javascript clone? Objective c is insanely verbose.
    - protomyth 7y ago
      How is swift a javascript clone? They ditched the selector syntax and went to a Javascript / C++ like syntax. There were so many ways to keep the selector syntax, but they went conformist. Objective c is insanely verbose. well, no - Swift's call syntax actually results in the same or more characters: somePoint.moveBy(x: 2.0, y: 3.0) [somePoint moveByX: 2.0 y: 3.0]; somePoint.moveBy(x: 2.0, y: 3.0, z: 4.0) [somePoint moveByX: 2.0 y: 3.0 z: 4.0]; Swift benefited from some shortening of the method names that can be equally applied to Objective-C. Plus, why the whole split by a left parentheses and comma thing?
  - steve1977 7y ago
    I feel you. I understand that Apple tries to cater to the "web developer" crowd as well, but sometimes this feels like a regression compared to what OPENSTEP was about.
laszlokorte 7y ago
Do the trailing closures implicitly return arrays of child elements? Or what kind of syntax is that?
- saagarjha 7y ago
  Single-expression functions can now return a value without the “return” keyword: https://github.com/apple/swift-evolution/blob/master/proposals/0255-omit-return.md https://github.com/apple/swift-evolution/blob/master/proposa...
  - laszlokorte 7y ago
    Yeah but the example code looks like multiple expressions?
    - saagarjha 7y ago
      Those might be functions that alter context of the closure rather than being returned. Or it might be some Swift compiler magic?
      - skohan 7y ago
        They look like initializers. Functions are lower-case by convention in Swift.
        saagarjha 7y ago
        That is convention, but there’s no need to follow it ;)
      - laszlokorte 7y ago
        So far I found out it's implemented via parameter attribute [1] [1]: https://developer.apple.com/documentation/swiftui/viewbuilder https://developer.apple.com/documentation/swiftui/viewbuilde...
hokkos 7y ago
So it look like react but it doesn't seems to be immediate mode GUI, still retained ? The body is a property not a function.
- Hemospectrum 7y ago
  That's a "computed property," ie. a getter method pretending to be an instance variable.
let_var 7y ago
First-call declarative UI support is amazing!
Pym 7y ago
This reminds me Visual Studio back in 2001 when I discovered programming. Everything was so easy to prototype. I'm so happy to see Apple is taking this direction. Thank you guys!
- pplante 7y ago
  I assume you mean Visual Basic, since Visual Studio was geared towards C/C++. Unless you actually used the MFC designer in VS5/6, which never really worked that well for me.
  - Pym 7y ago
    Actually I had VB6 in mind yes, but after a few months playing with it I made the switch to .NET (which was still in beta I believe at the time) so I was using Visual Studio ".NET" :)
thought_alarm 7y ago
I'm laughing at all the handwringing over Marzipan in the lead-up to this year's WWDC. The future of MacOS development is not Marzipan and never was. The future is SwiftUI.
- saagarjha 7y ago
  SwiftUI running through Catalyst, surely?
  - MR4D 7y ago
    Or maybe Catalyst runs on (in?) SwiftUI? @kylemacomber - can you provide some context here? I'm sure many of us would love to get a high-level understanding of this.
  - thought_alarm 7y ago
    SwiftUI isn't confined to Catalyst. It's available to native Mac AppKit apps as well as UIKit apps. (At least it appears that way, going by the WWDC session descriptions. We'll know more in a couple of hours)
    - saagarjha 7y ago
      Yeah, or once I can finish unarchiving Xcode…
- dmitriid 7y ago
  "A rose by any other name would smell as Marzipan". Even if it's called SwiftUI and not Marzipan, it still has all the same future problems as when it was called Marzipan [1] [1] https://blog.iconfactory.com/2019/05/what-to-expect-from-marzipan/ https://blog.iconfactory.com/2019/05/what-to-expect-from-mar...
  - mwfunk 7y ago
    SwiftUI is totally unrelated to Marzipan.
- 7y ago
lostmsu 7y ago
> across all Apple platforms
mmckeen 7y ago
Reminds me a bit of QML, though less declarative. Qt creator also has some pretty good IDE support.
DelightOne 7y ago
Where does this leave View Controllers? Is this available for those too? How does composition of multiple custom views work?
meabed 7y ago
Reminds of Visual Basic, seriously nothing is even close to an invention there. It has been forever since Apple development experience is the most crappy and unproductive of all other languages. The least they should do is replacing this shit Xcode, and allowing other company to build better IDE and language tooling for swift or whatever.
throwayEngineer 7y ago
Apple isn't any more Ethical. What has changed?
deleted 7y ago
[deleted]
DanGarthwaite 7y ago
It doesn't matter that it looks like flutter. It matters that flutter will be able take advantage of it.
- saagarjha 7y ago
  Flutter draws its own controls, so no, it cannot take advantage of SwiftUI.
PabloSichert 7y ago
I've been working on a very similar framework[1], but wasn't satisfied with the ergonomics enough to release it. My plans were to extend the Swift compiler with JSX-like syntax[2] that makes use of the declarative framework. Of course that's still possible, especially now with a canonical "Apple" way of building declarative interfaces in Swift. I'm a bit sad that with the announcement of SwiftUI my implementation will not stand a chance anymore, but I definitely learned a lot along the way how declarative rendering and reconcilation works in detail. Bottom line - this is very great news for native app development, declarative UI makes it vastly more easy to reason about code. [1] https://github.com/PabloSichert/Sx/blob/master/Example/Incrementer.swift https://github.com/PabloSichert/Sx/blob/master/Example/Incre... [2] https://facebook.github.io/jsx/ https://facebook.github.io/jsx/
thegayngler 7y ago
Thank you so much for this. I was learning iOS again for the fourth time. This time is different. I learned about programmatic UI from Brian LBTA guy which has been so much easier than IB. Now this update just makes my learning iOS a whole lot easier for me. I'm so thrilled. Thank you thank you thank you Apple!!!!!!!!
- thegayngler 7y ago
  Why am I being downvoted simply for being happy about this update and that it brings down the learning curve for other engineers?
  - kartickv 7y ago
    Unfortunately, many geek forums accept cynicism, negativity, sarcasm and snark, and downvote a happy post, usually with some excuse like "doesn't contribute to the discussion".
zapzupnz 7y ago
I'm sure SwiftUI has been in development for a long time, but it seems to me to be Apple's response to frameworks like React Native and Electron. We get a simple way to make UIs for multiple platforms, we get a nice batteries-included language, and Swift 5.1's dynamic method offers a similar functionality to hot reloading. Of course, it can't answer everybody's needs (no Windows, Linux, or Android support) but combine SwiftUI with Project Catalyst, and I'm really hoping to see plenty of high-quality cross-platform apps that don't have a whole instance of Chrome underlying them.
- robertAngst 7y ago
  >Of course, it can't answer everybody's needs (no Windows, Linux, or Android support) I don't understand how my fellow developers could ever tolerate Apple doing this. This goes one way, and its been like this for decades.
  - zapzupnz 7y ago
    Because not all of your "fellow developers" have the same priorities as you. For a lot of developers, targeting just the Apple platforms is still a worthwhile investment in itself: Apple's customers tend to pay higher prices for quality Mac software — yes, outside the Mac App Store, too — and they will very often be happy to pay for the accompanying iOS app if it's worth doing so. There have been Apple-only development houses since the year dot and this won't change just because Apple decided to release a platform to make it a little easier for its developers; they're not beholden to the rest of the world and it's ridiculous to believe so.
    - robertAngst 7y ago
      Given the high cost, high cost options exist on other platforms that are also fantastic. So if everyone can spend 3,000 dollars and get best in class computing, what are you paying for with Apple? They have lots of marketing that psychologically makes you feel good?
      - 7y ago
RantyDave 7y ago
Ahhh, I don't get it. XCode already does all of this, and has done for very many years. Y'all are excited because you can see the code?
melling 7y ago
there were lots of Swift holdouts. In fact, there has been a resurgence of Objective C Objective C is much higher than Swift: 11 vs 18. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ This should reverse the rankings and might push Swift into a top 10 language.
- vorg 7y ago
  > Objective C is much higher than Swift: 11 vs 18. And Apache Groovy rose from number 91 to number 17 in the past 12 months also according to that same Tiobe page (May 2019). Quoting Tiobe for anything only discredits what you're trying to prove.
childintime 7y ago
I was waiting for Apple to react to Flutter. It was a threat. They couldn't bluntly forbid Flutter apps. Now it seems this is their answer. Soon you'll be able to compile SwiftUI to Flutter and reach all platforms it reaches. Their play: to get the best experience, you'd still need to buy an iPhone.
- mleonhard 7y ago
  Who said anything about compiling SwiftUI to Flutter?
dvtrn 7y ago
Does the syntax sort of kind of remind anyone else of Shoes?[1] http://shoesrb.com/ http://shoesrb.com/
- ksec 7y ago
  Yes, I wonder what framework Apple engineers looked at for inspiration, and if they looked at shoes. Although I doubt they are allowed to answer this question.
  - jurip 7y ago
    Here's one comment about inspiration: https://twitter.com/jckarter/status/1135666944273571840 https://twitter.com/jckarter/status/1135666944273571840
- geowwy 7y ago
  The nesting makes it look similar but Shoes isn't declarative so it works very differently under the hood
binthere 7y ago
Will there be a similar API for Objective-C?
vedantroy 7y ago
This is definitely an overly ambitious project idea, but now that Google has Jetpack Compose and Apple has SwiftUI, and the web has React, I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively. Then you would get truly native, cross-platform development. Now, the probability this would ever work is 1%, but it's something that has lingered in my mind anyway.
- Despegar 7y ago
  >I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively. Just no. As an Apple user, just use whatever the tools they give you when you're developing for Apple platforms.
- tspike 7y ago
  It would be great until you need to debug something. Then it would be a nightmare.
- munificent 7y ago
  > I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively. Flutter targets native code on Android and iOS and JavaScript for the web. It has very mature compilers for all three.
- astrange 7y ago
  All meta-platforms are themselves platforms; meta-ness is in the implementation. So you could always do this no matter what you started from, but it's not actually a good idea. https://xkcd.com/927/ https://xkcd.com/927/
archagon 7y ago
Lots of engineers are suggesting that SwiftUI, plus other declarative frameworks, might be "the future" of app development. However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing. If you're working with highly interactive interfaces, complex animations, or dense, layered documents (DAWs, video editors), it seems that you would need explicit state and imperative code at the center of it all, and that a declarative approach would require hacks and workarounds at every turn. In my humble opinion, some of the most interesting, ground-breaking, and creative software has these properties; whereas this reactive stuff seems tailored to bog-standard utility software. However: I've never used React or any of its derivatives, so this is mostly inference. Is this take accurate or not? In theory, could you scale SwiftUI to build something like Logic, Blender, or Photoshop (for example)? Also, have any declarative UI frameworks been released that feature a "platform" layer, where you get to define how your declarative code actually turns into UI, widgets, and behaviors? It seems that SwiftUI relies on (encoded) assumptions of what an ideal UIKit or AppKit app is supposed to look and feel like, and it would be really powerful if we could mess with this foundation or even swap it out entirely. (It's very possible I'm mixing up reactive/declarative/reactive-UI concepts since I'm not too familiar with the territory.)
- arithma 7y ago
  Take most of the Adobe creative suite as an example. Different paradigms will fit different aspects of the UI design. Nobody wants to expend the same effort to build CRUDs as they would when they're working on "groundbreaking" stuff. Reality is a bit more nuanced: you want to abstract as much as possible and make it trivial, so that you can focus most energy where it matters. Patterns/Language/Frameworks all come into play here, and SwiftUI is a beautiful addition.
- kccqzy 7y ago
  Every software needs explicit state. If React is any indication, it tells us that the management of this explicit state can be made much more pleasant when written in a declarative way.
- pault 7y ago
  I can only speak for React, but the declarative component model doesn't eliminate state or imperative code, it just nudges you towards separating your stateful code from your layout/rendering code. In the React/Redux convention, your application is one big state machine with transitions encoded in reducers, and your state -> view data transformations in "selectors". View components are composed into one big pure function of state. Putting barriers between those classes of functionality makes it much easier to compose complex behavior from small, focused functions. Obviously you can write code with those properties in any context, but conventional React/Redux architecture makes the lines more explicit, which is why I like it. Lots of people hate it.
artemiszx 7y ago
Thinking about starting a new project over the summer. But seeing the demos it seems just starting something in UIKit now is a bad idea?
myko 7y ago
So frustrating this wont be usable for most apps for at least 2 years. Meanwhile Android, which yeah only 5% of users or something crazy small are on the latest version, will get to use the latest libraries on versions released 5+ years ago.
creolabs 7y ago
This is exactly what we did with Creo a couple of years ago: design, preview and development in a single tool. We rewritten UIKit from scratch in order to be able to preview iOS code on MacOS. Looks like we did it right. https://creolabs.com https://creolabs.com
croxx5f 7y ago
It smells a little like dart UI as code(flutterish may i say)
machinesbuddy 7y ago
It reminded me of Scaloid https://github.com/pocorall/scaloid https://github.com/pocorall/scaloid
kensai 7y ago
OMG, has anyone noticed the device icons on the bottom of the SwiftUI page? Steve will be turning in his grave...
dgellow 7y ago
Something like this available in C++ would be so great for cross platform applications!
- zaiste 7y ago
  There is Boden (native apps from a single C++17 codebase) https://www.boden.io/ https://www.boden.io/
  - dgellow 7y ago
    As far as I understand Boden is still a work in progress, far from being ready for prime time.
abalone 7y ago
I’m wondering what this could mean for replacing React Native. Obviously SwiftUI is geared for Apple’s platforms but overall it seems pretty high level and perhaps amenable to being adapted to Android by somebody. Swift is open source after all. This would solve a problem a lot of devs have in deciding how to build a cross platform app. We don’t want to give up first class support for each platform but it’s silly to have completely separate codebases. I hear even Apple has React Native dev groups.
OkGoDoIt 7y ago
For more information, there's a much more in-depth demo in the "Platforms State of the Union" session, which is now posted at https://developer.apple.com/videos/play/wwdc2019/103/ https://developer.apple.com/videos/play/wwdc2019/103/
appliaison 7y ago
Now, will someone be a sweetheart and write a transpiler that will transpile AndroidXML to SwiftyUI and SwiftyUI to AndroidXML. Also, while you're at it, please write a transpiler for Flutter to SwiftyUI and SwiftyUI to Flutter. K. Thx.
atilkan 7y ago
Looks nice like Flutter.
adamspb 7y ago
Am I the only one thinking "SwiftUI compile to WASM"?

765 points by fphilipe 7y ago

So React.js but native and in Swift? I'm hesitant but hopeful. Tutorial: https://developer.apple.com/tutorials/swiftui/ https://developer.apple.com/tutorials/swiftui/

sz4kerto 7y ago

To me this looks very similar to what Google is doing with Flutter.

pjmlp 7y ago
Jetpack Composer you mean. I bet by next IO, Flutter will get replaced by it, specially after the #KotlinEverywhere announcement and Kotlin/Native effort for iOS.
- mythz 7y ago
  No he means Flutter which has been around a lot longer, it's immediately what I've thought of being inspired by as well: https://flutter.dev/docs/development/tools/hot-reload https://flutter.dev/docs/development/tools/hot-reload
  - pjmlp 7y ago
    I know pretty much what he/she meant, was just making a point that I don't believe in Flutter's long term success. Trying to sell Dart a 2nd time was a mistake.
    - mythz 7y ago
      Flutter's not a PR campaign for Dart, they're a separate project that chose Dart based on its technical capabilities [1]. Given Flutter enables the nicest native x-plat dev experience today I'd say it has a very bright future, which they've also recently announced Flutter for Desktop and Embedded devices. Jetpack compose is years away from the same kind of x-plat support that Flutter's providing for Mobile, Web, Desktop and Embedded [2]. [1] https://flutter.dev/docs/resources/faq#why-did-flutter-choose-to-use-dart https://flutter.dev/docs/resources/faq#why-did-flutter-choos... [2] https://developers.googleblog.com/2019/05/Flutter-io19.html https://developers.googleblog.com/2019/05/Flutter-io19.html
      - pjmlp 7y ago
        That after-the-fact reasoning link that gets posted every time someone questions Dart is well known, no need to give it to me. Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "technical capabilities". Flutter is a way to rescue Dart, plain and simple. Yes, Jetpack Compose might be doing its baby steps, but I am betting most developers are more keen in having Kotlin than Dart on their CV, specially after Dart v 1.0's demise. And Android team surely has more political power, given ChromeOS and Fuchsia adoption of ART.
        mythz 7y ago
        > no need to give it to me. Think highly of yourself much? But I'll be continuing to provide links as I see it's relevant and informative, my comments are not just for your benefit, readers can make their own mind whose opinions are more informed - "no need" to tell others how to comment. > Only someone that never used Common Lisp, Smalltak, Delphi, C++ Builder and other 4GLs in the 90's, can be impressed by Dart's "technical capabilities". Am I meant to be impressed by this list of languages? I'm not. Are the number of languages meant to give your inexperienced opinion on Flutter's development environment some credence or is this washy strawman meant to downplay anyone else's opinion who wasn't a developer in the 90's when these languages were more relevant? What matters is what's relevant now and Flutter lets you build modern x-plat Mobile, Web, Desktop and Embedded Apps with productive Live Hot Reload environment that's both fast at development and runtime which can be run in a JIT VM, as AOT compiled or transpiled to tree-shaken JS. Which of these above languages provides a more productive and "technically impressive" environment to develop iOS/Android, Web and Embedded Apps than Dart/Flutter? > Flutter is a way to rescue Dart, plain and simple. Adding "plain and simple" to an baseless opinion doesn't re-enforce it, including links that backs up this wild speculation will. What information have you used to be able present this opinion as fact so staunchly? Do you really believe Google invented and funded the Flutter project out of thin air to give Dart a popularity boost? > And Android team surely has more political power, given ChromeOS and Fuchsia adoption of ART. How can Android have more political power for Fuchsia than Dart which is what most of its UI is written in? You can also develop Flutter Apps on Chrome OS so that's no different. Chrome OS is still primarily a Web OS, allowing running Android Apps doesn't make it an OS for running Android Apps and devs aren't going to be lining up to develop Chrome OS Apps using Android. Flutter's strength's is that you can develop x-plat App's that looks, behaves and runs natively on all its supported platforms - feel free to wait until Kotlin reaches the same maturity on iOS before declaring it a Flutter killer. Kotlin still suffers from Android's complicated and fragile tooling and from what I've seen with JetPack compose it's highly coupled to Android - it's going to take a long time before they'll let you build iOS/Android Apps from a single code base.
- burky 7y ago
  Flutter is cross platform. I looked for it but didn't see where jetpack has this capability. Please post me a link if I’m wrong, I would follow this project if it does support cross platform development.
  - arusahni 7y ago
    Jetpack Compose was announced at IO: https://blog.karumi.com/android-jetpack-compose-review/ https://blog.karumi.com/android-jetpack-compose-review/
- HillaryBriss 7y ago
  It looks like Jetpack Compose is not really done yet. It's pre-alpha and the Jetpack Compose doc page says don't use it for production. https://developer.android.com/jetpack/compose/ https://developer.android.com/jetpack/compose/ I may be missing something, but SwiftUI seems to be pretty much ready to go today.
  - pjmlp 7y ago
    You are missing the fact that Android team doesn't want to have anything to do with Dart, and started a Kotlin everywhere initiative, including iOS via Kotlin/Native.
  - rhodysurf 7y ago
    Except it’s not ready to go because it’s not backwards compatible it seems.
  - myko 7y ago
    Ready to go today if you're only supporting iOS 13+ Which for most companies is 2+ years away
    - HillaryBriss 7y ago
      I stand corrected. thanks.
    - HillaryBriss 7y ago
      To add a bit more detail: the required level for other Apple OSs are macOS 15+, tvOS 13+ and watchOS 6+.
itp 7y ago
Indeed, but (unsurprisingly) Apple-only.
saagarjha 7y ago
But native, of course.
- tootie 7y ago
  And proprietary.
mmargerum 7y ago
Flutter doesn't use native controls . It draws everything. Just pointing out that difference.
- pier25 7y ago
  Native controls aren't drawn too?
  - HillaryBriss 7y ago
    yes, they're drawn too. but, i think what the above comment is pointing out is that Flutter itself does the drawing, instead of delegating the drawing to iOS or Android native widgets.
    - mmargerum 7y ago
      More than just drawing. They have to reimplement all of the behaviors of the built in controls. I'm sure google is up to the task, but my experience has been there's always things missing and and lag behind native .
      - kartickv 7y ago
        > there's always things missing and and lag behind native Flutter specifically or cross-platform UI frameworks in general? I don't mind it being different, but does the app feel unpolished?
    - pier25 7y ago
      Actually no, Flutter doesn’t do the drawing. It’s done by Skia, much like Cocoa native controls are drawn by Quartz. There isn’t much of a difference between Flutter controls and native controls, other than being a reimplementation in some cases.
      - mpweiher 7y ago
        > other than being a reimplementation in some cases. Hmm...that's pretty much the entire difference between native and non-native controls.
dep_b 7y ago
It does, in a good way. I really liked Flutter's UI approach.
jswizzy 7y ago
Jetpack Compose is more like it

bilal4hmed 7y ago

Looks a lot like Flutter

Apocryphon 7y ago

Can this retroactively support apps targeting iOS 12 and older?

aerialcombat 7y ago
probably not
cududa 7y ago
What do you think
favorited 7y ago
No. One of the engineers said on Twitter it is a system framework.
scarface74 7y ago
The only devices you lose by supporting iOS 13 and not iOS 12 are the iPhone 5s from 2013 and the 6th generation iPod Touch from 2014. iOS users update pretty rapidly.
- saagarjha 7y ago
  iPhone 6 does not have an iOS 13 IPSW on the developer downloads site. iPad Air and the second and third generation iPad Mini were dropped as well.
  - scarface74 7y ago
    Didn't realize that they dropped the 6 and 6 Plus.

chadlavi 7y ago

The question the whole web asks now: what does this mean for React Native devs

gmemstr 7y ago
I bet it's going to stay relatively the same, for now. React Native still works across iOS and Android, which is one of the key features. SwiftUI is iOS only.
- chadlavi 7y ago
  It's my understanding that a lot of the appeal of RN is also that it allows web devs who are fluent in JS to make mobile apps, so I guess that's not really comparable in SwiftUI either.
  - nicoburns 7y ago
    I'm not sure about that. SwiftUI code looks an awful lot like React code. And IMO (as a web dev), it was always learning the UI framework that seemed like it would be the difficult part of learning iOS dev. Data manipulation APIs are pretty similar in most languages, but learning a new UI paradigm is a pain...
    - lghh 7y ago
      Yes, but alongside learning SwiftUI they will also have to learn whatever is going on in Android land because it's not cross platform.
- ihuman 7y ago
  > SwiftUI is iOS only It's also on macOS
  - TheOtherDave 7y ago
    I think it’s on tvOS and watchOS, too.

fphilipe 7y ago

Personally, as an iOS developer, this is by far the biggest announcement. Haven’t had the chance to dig deeper, but the comparison between the UITableViewController and that snippet containing just declarative code looks absolutely promising. The only downside is that we’ll have to wait one or two years before we can use it if older iOS versions still need to be supported. Let’s hope for extra quick adoption of iOS 13.

sim_card_map 7y ago
Do you have a link to the comparison?
- dmix 7y ago
  It was during the event, they just displayed an overly dramatic LOC comparison on the screen between a few page-downs on a longer Swift file, then the next screen showed a ~10 line block of code which does the same thing. Followed by the standard audience applause. The livestream hasn't been uploaded yet but I'm sure you could find it in one of the live blogs.
  - saidajigumi 7y ago
    Part of that comparison (on the "before" side) was a bunch of Cocoa autolayout code. It's verbose and annoying, only mitigated if you're using Interface Builder, which has its own significant downsides. If the declarative form in SwiftUI supports a saner approach to managing and adjusting layout, then there's absolutely nothing overdramatic about that comparision. It's a potential game changer.
  - sim_card_map 7y ago
    Thanks! Indeed it's impressive.
eugeniub 7y ago
Unfortunately, iOS 13 drops support for iPhone 5s and iPhone 6.[1] Last year, iOS 12 didn't drop support for any devices. The iPhone 6 is a very popular device, and was still sold by Apple less than two years ago. [1]: https://iosref.com/ios/ https://iosref.com/ios/

kylemacomber 7y ago

I’m one of the engineers that spearheaded this initiative inside of Apple. I just wanted to thank the HN community—I’ve been reading HN for 10 years now and it’s been formative in my development as a software engineer. If you’re at WWDC stop by the labs and say hi!

sdegutis 7y ago
How would you compare this to React.js? In particular, how does SwiftUI approach the concepts that Redux solves [EDIT: in other words, state management]?
- rat9988 7y ago
  Redux and react are two different questions.
  - sdegutis 7y ago
    When people make alternatives to React, at some point they have to address the concept of state changes and side-effects, building in conveniences for it, or leaving it for third parties to develop this area.
    - nickbauman 7y ago
      ... Or use something like Reagent where there is language level support for reactive state management using atoms. https://github.com/reagent-project/reagent https://github.com/reagent-project/reagent
      - sdegutis 7y ago
        That looks like exactly what SwiftUI is doing.
    - ng12 7y ago
      This has nothing to do with Redux. Redux is about storing global data, nothing more.

skohan 7y ago

I hope it still supports low-level control when you need it.

bendixso 7y ago
Yeah, I have the same concern. This is great for those situations where declarative works but sometimes you really want to get low-level and do some custom stuff with imperative code. I suppose we can use the old frameworks for that?
teilo 7y ago
Looks like it shifts the focus toward developing more intelligent components. They mentioned custom SwiftUI components a few times in the demo. This is one of the things I am eager to get a deep dive on in later session videos.
seanalltogether 7y ago
Well the docs say you can chain an id() property on any view being built in the tree which would hopefully allow you to reference it at runtime and insert/delete children, but I don't see anything obvious for assigning that id to like an outlet so you don't have to traverse the whole tree to find it.

jpochtar 7y ago

fmr founder of Pagedraw here... this looks amazing. I wish we'd built it! :)

stefan_ 7y ago

Apple developers will be glad they get to rewrite their entire application with a new UI framework and paradigm or risk their apps looking garbage on the platform (and stop working by next release). This must be the .. fifth entirely new UI framework from Apple?

vbezhenar 7y ago
I don't think that's true. It seems to be higher-level framework based on Cocoa Touch. Existing apps will work just fine. And probably any real world app will have to deal with Cocoa Touch as well, like any real React app have to work with DOM.
deleted 7y ago
[deleted]
rimliu 7y ago
That's a lot if pointless FUD.
jaegerpicker 7y ago
This isn't true at all. Since iOS launched there has been UIKit and then this SwiftUI.
- grey-area 7y ago
  This must be the .. fifth entirely new UI framework from Apple? This isn't true at all. Since iOS launched there has been UIKit and then this SwiftUI. They didn't say anything about iOS. There have been lots of UI frameworks from Apple, some abandoned before they were even finished: QuickDraw, Quickdraw GX, HIToolbox, AppKit, Cocoa Touch/UIKit, Playgrounds/IB, SwiftUI The constantly changing frameworks and languages are a useful strategy from platform vendors - they do help provide platform lockin, and make it very very difficult to provide cross platform apps. That is a real threat to Apple with offerings like flutter from Google. Of course there are other reasons to make a clean break with the past, but there is a lot of work just to stand still in developing for a platform like Mac OS or IOS - they don't highly value backwards compatibility and often introduce sweeping changes. Constant change is in the platform vendor's financial interest, and I don't think it's unfair to point that out. Just to take one example - apps built for the original iOS are now almost entirely obsolete, and it's not worth reusing any of their code in a modern swift app.

jcelerier 7y ago

The syntax example is still not as clean as QML, which is already a ten-year-old language (examples: http://qmlbook.github.io/ch04-qmlstart/qmlstart.html http://qmlbook.github.io/ch04-qmlstart/qmlstart.html).

aseipp 7y ago
Depends on what you mean by "clean". I'd say it's pretty good from what I can see? The examples are also incomparable; the one you link to is nearly 20 lines of code to define nothing more than an embedded triangle image and single text embed with a few colors, while the Swift example hosts an entire modal list with embedded picture components and text (while handling fluid scrolling, right-to-left langs, dark mode theming, etc all implicitly) -- all in the same number of lines or so (and had further mods made during the Keynote by a developer with similar brevity.) Judging from lines only or "cleanliness" I'd say SwiftUI is doing pretty good here, but ultimately the examples are too apples and oranges to draw any real conclusions from. Syntax aside, there is a large semantic difference between the two: QML is a separate language/modeling tool that is embedded into the application runtime. SwiftUI is in fact ordinary Swift code and the UI you define with it is also ordinary Swift code too, code that XCode and the Swift compiler understand and analyze and refactor and compile like any other. Just with some special magic to make the UI builder work with it. I think this has a lot of advantages notably from a toolchain perspective, since you don't even need XCode (just the Swift compiler) to do things like xrefs/refactorings across SwiftUI code, nor maintain tooling like that across two languages (XYZ + whatever UI modeling language) Given that, my first impressions of how far they took it (and how well it came out) are pretty good.
- stabbles 7y ago
  > while the Swift example hosts an entire modal list with embedded picture components and text (while handling fluid scrolling, right-to-left langs, dark mode theming, etc all implicitly) I think you might check out more of QML / QtQuick 2 before drawing any conclusions. import QtQuick 2.12 import QtQuick.Layouts 1.12 ListView { model: Model.items delegate: RowLayout { Image { source: image } Column { Text { text: title } Text { text: subtitle color: "gray" } } } } This should be more or less the same. Fluid scrolling is backed by the underlying Flickable [1]. RTL support is available an can be changed in runtime [2]. Themes / colors can be changed in runtime as well [3]. Lastly, it runs on Windows, Linux and Android as well as OSX and iOS. [1] https://doc.qt.io/qt-5/qml-qtquick-flickable.html https://doc.qt.io/qt-5/qml-qtquick-flickable.html [2] https://doc.qt.io/qt-5/qtquick-positioning-righttoleft.html https://doc.qt.io/qt-5/qtquick-positioning-righttoleft.html [3] https://doc.qt.io/qt-5/qtquickcontrols2-styles.html https://doc.qt.io/qt-5/qtquickcontrols2-styles.html

TheRealDunkirk 7y ago

Other than a few-hour intro seminar on building iOS apps, almost 10 years ago, I've never written anything in Swift. The announcements around it today got the biggest reactions from the crowd. Is is really great, blasé, or too early to tell?

saagarjha 7y ago
It’s too early to tell, but it’s certainly very exciting.
JimDabell 7y ago
It's probably the biggest shakeup to Apple's developer platform since Swift was announced.
teilo 7y ago
You were not using Swift 10 years ago, or even almost 10 years ago. It was released in 2014.
- TheRealDunkirk 7y ago
  Ah, now I see the reason for the downvotes. I just meant "Apple's language for doing iPhone apps," and, of course, that was Obj-C back then. I haven't thought about it since.

oflannabhra 7y ago

This is fantastic, and I am almost upset by how little info the keynote address included. Obviously there will be a ton of detail coming out this week with the labs and documentation being released, looking forward to that. As an iOS developer, this is by far the biggest announcement. This has huge potential to provide value to me and my team. I'm looking forward to ripping out programmatic NSLayoutConstraint and Interface Builder from my projects ASAP. This seems like it includes much more than that, however.

kennywinker 7y ago
Details will be in the Platform State of The Union later today. Keynotes are always press/casual-fan focused
Jerry2 7y ago
The "real" developer keynote is "Platforms State of the Union" which will surely cover a lot more of it. The morning keynote is for the press and executives to highlight latest releases with some dev stuff thrown in.
- ehsankia 7y ago
  Yeah, it's similar to I/O where there's a separate developer keynote, and specific "State of the Union" talks for each platform/framework.

azhenley 7y ago

.color(.gray)) What object is .gray acting on?

didgeoridoo 7y ago
That syntax is a shortcut for UIColor.gray, so this is really: .color(UIColor.gray)
- JimDabell 7y ago
  I would expect it's the grey static member of SwiftUI's Color struct: https://developer.apple.com/documentation/swiftui/color/3049710-gray https://developer.apple.com/documentation/swiftui/color/3049...
kennywinker 7y ago
That’d be standard swift type inference. The .color function takes a single unnammed parameter of type Color (or similar, idk exactly). Color.gray is a static constant value. So .color(Color.gray) can be simplified to .color(.gray)
- steve_adams_86 7y ago
  Huh, that's actually a great way to do type inference. Swift seems like an excellent language.
deleted 7y ago
[deleted]
auggierose 7y ago
that's shortcut syntax for an enumeration case where the type of the enumeration can be inferred
- favorited 7y ago
  It's not just for enums. It works for any static variable on a given type. So you can say .gray and have it map to NSColor.gray, etc.

untog 7y ago

I'd be curious to know how many React Native devs work on cross-platform apps. In casual conversation I've had it actually isn't that high, despite it being one of the central promises of RN. Given that SwiftUI has live reloading and a sensible template interface I could absolutely see it winning over some RN devs. There's something to be said (particularly with Apple) for using the native toolset rather than RN, Flutter and the like.

deleted 7y ago
[deleted]
wtetzner 7y ago
> In casual conversation I've had it actually isn't that high, despite it being one of the central promises of RN. But applications written in React Native aren't cross platform, are they? You have different components depending on the platform. My understanding is that they claimed you wouldn't have to learn a different framework when switching to a new platform, not that your apps would be portable.
- zwily 7y ago
  You can share components but have to carefully handle any platform-specific code.
- k__ 7y ago
  I built cross-platform apps with it. It works by supplying me with native modules and native components for every platform and I write my domain logic in portable JavaScript.
- joshjhargreaves 7y ago
  Applications written in React Native typically are cross-platform; saying that they are not is a pretty large misrepresentation of the framework. At its base React Native provides a common set of native components with the same API on both iOS and Android such as View, Image & Text which can all be styled and laid out through common APIs. These APIs pretty much give you most of what you need to make an entire APP. Sometimes you may want to have different behavior per platfrom and for that you can use the Platform API (provided by React Native) to switch for each platform. This would allow you to do things like change the styling on each platform or the native components you use. React Native makes it pretty easy to expose native components to JavaScript. It is also up to the native component author if they want to create a common API for all platforms that they support. In the case of Views & styling it makes a lot of sense to have the same API on iOS and Android, but sometimes they are some platform features that are only available on one platform. Wile Swift Layout is not cross-platform, it may soon be and I think it does a lot for promoting declarative UI & maybe they did take some inspiration from React! View docs: https://facebook.github.io/react-native/docs/view.html https://facebook.github.io/react-native/docs/view.html Styling: https://facebook.github.io/react-native/docs/style https://facebook.github.io/react-native/docs/style Layout: https://facebook.github.io/react-native/docs/flexbox https://facebook.github.io/react-native/docs/flexbox

thomasjames 7y ago

Interesting move we see from the big players to more declarative UI toolkits. First Flutter, now this.

ognarb 7y ago
Don't forget qml
- mmckeen 7y ago
  Yeah, it's a shame people are praising these new frameworks but forget similar ones that have been around and rocking for years.
pzo 7y ago
You have to give credit to react time which seems that started this paradigm of declarative and reactive ui frameworks. After that you got react native, flutter, jetpack compose and now swift ui. As for declarative (but not reactive) ui prior art is also Qt qml.
- thomasjames 7y ago
  Both looked kind of like GTK (in a non-verbose language like Python) to me, too. Maybe I am seeing things.
- sandeepc24 7y ago
  Also have a look at https://fsprojects.github.io/Fabulous/ https://fsprojects.github.io/Fabulous/

mikece 7y ago

I was fully expecting something along the lines of "Oh, and SwiftUI will compile to WebAssembly allowing your apps to look just as awesome and run just as fast in Safari." Probably still in alpha...

saagarjha 7y ago
Why would Apple want these apps to run in Safari? They have a platform to run these already.
- mikece 7y ago
  Safari isn't the point -- running on other platforms is. Market share for iOS globally is nowhere close to Android; in India iOS is only about 10% so if your SwiftUI app could run in Chrome on Android and is installable as a PWA, you open up the rest of the handset market.
  - donarb 7y ago
    SwiftUI is not just for iOS, it's for MacOS, tvOS, iPadOS and WatchOS as well. That covers well over a billion devices with all kinds of apps.
  - saagarjha 7y ago
    Apple doesn’t really care about you being able to run your UI code on those platforms.
    - mmargerum 7y ago
      True. in fact they have a vested interest in not making this happen, but someone will. This looks really impressive and i've grown to like swift quite a bit.

lisardo 7y ago

It’s nice to finally see a FRP framework for iOS like React/Elm. MVC must die already.

seanmcdirmid 7y ago
How is this like FRP, React, or Elm (each of those things being fairly different themselves). SwiftUI actually reminds me of JavaFX when done with JavaFX Script (ahead of its time by too much), but I haven't been able to dig up a lot of examples from their website yet.
steve_adams_86 7y ago
FRP and MVC seem like different types of patterns to me. Functional reactive is about how you manage state and flow while MVC is largely about separation of concerns. In my (possibly poor) understanding, you could actually use them together. I'm interested in your take on that though. I'm self taught and I've got some weird ideas about things.
ch4s3 7y ago
Elm isn't FRP anymore [1], it uses some sort of process and scheduler model behind the msg system. React isn't FRP either, though you can approximate higher order FRP with Redux if you want. [1] https://elm-lang.org/blog/farewell-to-frp https://elm-lang.org/blog/farewell-to-frp

chkgk 7y ago

I didn't catch it. Is Xcode 11 (beta) available already? Do I need macOS Catalina (beta) to run it? I seem to have missed the crucial information and cannot find it on apples developers pages...

saagarjha 7y ago
https://developer.apple.com/download/ https://developer.apple.com/download/
- chkgk 7y ago
  Thank you, but that's how far I got myself. It is telling me there are no downloads available at this time. I am asking, because I am still on 10.14.5 and I thought the Xcode 11 beta might only be available on the 10.15 beta.
  - DelightOne 7y ago
    Under Applications now: Xcode 11 beta
  - saagarjha 7y ago
    Check the “Applications” tab, the Xcode download is there (they redesigned the page, which makes it IMO worse). No idea if it runs on Mojave, but I would think so based on history.
  - mthoms 7y ago
    The XCode 11 "whats new" page [0] says: >To use the SwiftUI design canvas Xcode 11 must running on macOS Catalina. Please let us know if you find that's incorrect. [0] https://developer.apple.com/xcode/whats-new/ https://developer.apple.com/xcode/whats-new/
gschrader 7y ago
The direct download is here: https://developer.apple.com/services-account/download?path=/WWDC_2019/Xcode_11_Beta/Xcode_11_Beta.xip https://developer.apple.com/services-account/download?path=/... for some reason my account only shows "There’s currently no beta software available for download."

Redoubts 7y ago

var body: some View { Wait, what? When was `some` a keyword?

skohan 7y ago
It's part of generalized existentials, a forthcoming language feature.
saagarjha 7y ago
It’s part of Swift 5.2: https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md https://github.com/apple/swift-evolution/blob/master/proposa...
alexjm 7y ago
It's part of opaque types, which are new in Swift 5.1 https://docs.swift.org/swift-book/LanguageGuide/OpaqueTypes.html https://docs.swift.org/swift-book/LanguageGuide/OpaqueTypes....
ardit33 7y ago
I am still scratching my head why the 'some' keyword is needed/required for opaque types. Eg. SquareButton and RoundButton are implementations of the Button (protocol). You want to create a function that returns the button, but you don't want to specify to the user exactly what type of button is it (as it doesn't matter). Your function could just declare the top level protocol as the return type without needed to specify the word "some" createPlayButton -> Button instead of createPlayButton -> some Button Am I missing something? It feels like the 'some' keyword is just there to help the compiler and not the users necessary it seems like the equivalent of id <MyProtocol> in Objective-C. Basically just a surface re-arranging of names, but keeping the same concepts as in Objective-C I feel Golang did better in this regards... (eg. not necessary distinguishing between protocols and super class-es, it is quacks like a duck, it is a duck)
- skohan 7y ago
  The difference is subtle but it's there. The "some" keyword indicates that the function returns a specific type, even if that type isn't known to the caller. One place where this is meaningful is if you have to use the result of that function in a generic function. For instance if my functions are defined like this: func createPlayButton() -> Button { ... } func doSomething<T: Button>(_ button: T) { ... } And I try to call this: doSomething(createPlayButton()) I will get an error, because the protocol Button does not conform to itself. However If I use opaque types: func createPlayButton() -> some Button { ... } this works just fine because the compiler is able to determine the concrete type returned by `createPlayButton`

checker659 7y ago

One more blow to the head for objective-c. Wonder if this the final nail in the coffin.

mmargerum 7y ago
It certainly gives me a reason to migrate now. Swift alone wasn't enough of a reason.
protomyth 7y ago
Given that Craig Federighi basically said this type of migration only comes around every 20 years, I would imagine Objective-C is dead. I do hope they actually take the time and fix the Swift examples so they are updated. This does hurt. I've been programming Objective-C since NeXTSTEP and love it. Swift is still like Perl for me. Something I will use for programming for money, but not enjoy for one minute. I loved the clarity of selector syntax, but Javascript clones rule the world. I still don't understand the love of commas or why they are needed.
- adamnemecek 7y ago
  How is swift a javascript clone? Objective c is insanely verbose.
  - protomyth 7y ago
    How is swift a javascript clone? They ditched the selector syntax and went to a Javascript / C++ like syntax. There were so many ways to keep the selector syntax, but they went conformist. Objective c is insanely verbose. well, no - Swift's call syntax actually results in the same or more characters: somePoint.moveBy(x: 2.0, y: 3.0) [somePoint moveByX: 2.0 y: 3.0]; somePoint.moveBy(x: 2.0, y: 3.0, z: 4.0) [somePoint moveByX: 2.0 y: 3.0 z: 4.0]; Swift benefited from some shortening of the method names that can be equally applied to Objective-C. Plus, why the whole split by a left parentheses and comma thing?
- steve1977 7y ago
  I feel you. I understand that Apple tries to cater to the "web developer" crowd as well, but sometimes this feels like a regression compared to what OPENSTEP was about.

laszlokorte 7y ago

Do the trailing closures implicitly return arrays of child elements? Or what kind of syntax is that?

saagarjha 7y ago
Single-expression functions can now return a value without the “return” keyword: https://github.com/apple/swift-evolution/blob/master/proposals/0255-omit-return.md https://github.com/apple/swift-evolution/blob/master/proposa...
- laszlokorte 7y ago
  Yeah but the example code looks like multiple expressions?
  - saagarjha 7y ago
    Those might be functions that alter context of the closure rather than being returned. Or it might be some Swift compiler magic?
    - skohan 7y ago
      They look like initializers. Functions are lower-case by convention in Swift.
      - saagarjha 7y ago
        That is convention, but there’s no need to follow it ;)
    - laszlokorte 7y ago
      So far I found out it's implemented via parameter attribute [1] [1]: https://developer.apple.com/documentation/swiftui/viewbuilder https://developer.apple.com/documentation/swiftui/viewbuilde...

hokkos 7y ago

So it look like react but it doesn't seems to be immediate mode GUI, still retained ? The body is a property not a function.

Hemospectrum 7y ago
That's a "computed property," ie. a getter method pretending to be an instance variable.

let_var 7y ago

First-call declarative UI support is amazing!

Pym 7y ago

This reminds me Visual Studio back in 2001 when I discovered programming. Everything was so easy to prototype. I'm so happy to see Apple is taking this direction. Thank you guys!

pplante 7y ago
I assume you mean Visual Basic, since Visual Studio was geared towards C/C++. Unless you actually used the MFC designer in VS5/6, which never really worked that well for me.
- Pym 7y ago
  Actually I had VB6 in mind yes, but after a few months playing with it I made the switch to .NET (which was still in beta I believe at the time) so I was using Visual Studio ".NET" :)

thought_alarm 7y ago

I'm laughing at all the handwringing over Marzipan in the lead-up to this year's WWDC. The future of MacOS development is not Marzipan and never was. The future is SwiftUI.

saagarjha 7y ago
SwiftUI running through Catalyst, surely?
- MR4D 7y ago
  Or maybe Catalyst runs on (in?) SwiftUI? @kylemacomber - can you provide some context here? I'm sure many of us would love to get a high-level understanding of this.
- thought_alarm 7y ago
  SwiftUI isn't confined to Catalyst. It's available to native Mac AppKit apps as well as UIKit apps. (At least it appears that way, going by the WWDC session descriptions. We'll know more in a couple of hours)
  - saagarjha 7y ago
    Yeah, or once I can finish unarchiving Xcode…
dmitriid 7y ago
"A rose by any other name would smell as Marzipan". Even if it's called SwiftUI and not Marzipan, it still has all the same future problems as when it was called Marzipan [1] [1] https://blog.iconfactory.com/2019/05/what-to-expect-from-marzipan/ https://blog.iconfactory.com/2019/05/what-to-expect-from-mar...
- mwfunk 7y ago
  SwiftUI is totally unrelated to Marzipan.
7y ago

lostmsu 7y ago

> across all Apple platforms

mmckeen 7y ago

Reminds me a bit of QML, though less declarative. Qt creator also has some pretty good IDE support.

DelightOne 7y ago

Where does this leave View Controllers? Is this available for those too? How does composition of multiple custom views work?

meabed 7y ago

Reminds of Visual Basic, seriously nothing is even close to an invention there. It has been forever since Apple development experience is the most crappy and unproductive of all other languages. The least they should do is replacing this shit Xcode, and allowing other company to build better IDE and language tooling for swift or whatever.

throwayEngineer 7y ago

Apple isn't any more Ethical. What has changed?

deleted 7y ago

[deleted]

DanGarthwaite 7y ago

It doesn't matter that it looks like flutter. It matters that flutter will be able take advantage of it.

saagarjha 7y ago
Flutter draws its own controls, so no, it cannot take advantage of SwiftUI.

PabloSichert 7y ago

I've been working on a very similar framework[1], but wasn't satisfied with the ergonomics enough to release it. My plans were to extend the Swift compiler with JSX-like syntax[2] that makes use of the declarative framework. Of course that's still possible, especially now with a canonical "Apple" way of building declarative interfaces in Swift. I'm a bit sad that with the announcement of SwiftUI my implementation will not stand a chance anymore, but I definitely learned a lot along the way how declarative rendering and reconcilation works in detail. Bottom line - this is very great news for native app development, declarative UI makes it vastly more easy to reason about code. [1] https://github.com/PabloSichert/Sx/blob/master/Example/Incrementer.swift https://github.com/PabloSichert/Sx/blob/master/Example/Incre... [2] https://facebook.github.io/jsx/ https://facebook.github.io/jsx/

thegayngler 7y ago

Thank you so much for this. I was learning iOS again for the fourth time. This time is different. I learned about programmatic UI from Brian LBTA guy which has been so much easier than IB. Now this update just makes my learning iOS a whole lot easier for me. I'm so thrilled. Thank you thank you thank you Apple!!!!!!!!

thegayngler 7y ago
Why am I being downvoted simply for being happy about this update and that it brings down the learning curve for other engineers?
- kartickv 7y ago
  Unfortunately, many geek forums accept cynicism, negativity, sarcasm and snark, and downvote a happy post, usually with some excuse like "doesn't contribute to the discussion".

zapzupnz 7y ago

I'm sure SwiftUI has been in development for a long time, but it seems to me to be Apple's response to frameworks like React Native and Electron. We get a simple way to make UIs for multiple platforms, we get a nice batteries-included language, and Swift 5.1's dynamic method offers a similar functionality to hot reloading. Of course, it can't answer everybody's needs (no Windows, Linux, or Android support) but combine SwiftUI with Project Catalyst, and I'm really hoping to see plenty of high-quality cross-platform apps that don't have a whole instance of Chrome underlying them.

robertAngst 7y ago
>Of course, it can't answer everybody's needs (no Windows, Linux, or Android support) I don't understand how my fellow developers could ever tolerate Apple doing this. This goes one way, and its been like this for decades.
- zapzupnz 7y ago
  Because not all of your "fellow developers" have the same priorities as you. For a lot of developers, targeting just the Apple platforms is still a worthwhile investment in itself: Apple's customers tend to pay higher prices for quality Mac software — yes, outside the Mac App Store, too — and they will very often be happy to pay for the accompanying iOS app if it's worth doing so. There have been Apple-only development houses since the year dot and this won't change just because Apple decided to release a platform to make it a little easier for its developers; they're not beholden to the rest of the world and it's ridiculous to believe so.
  - robertAngst 7y ago
    Given the high cost, high cost options exist on other platforms that are also fantastic. So if everyone can spend 3,000 dollars and get best in class computing, what are you paying for with Apple? They have lots of marketing that psychologically makes you feel good?
    - 7y ago

RantyDave 7y ago

Ahhh, I don't get it. XCode already does all of this, and has done for very many years. Y'all are excited because you can see the code?

melling 7y ago

there were lots of Swift holdouts. In fact, there has been a resurgence of Objective C Objective C is much higher than Swift: 11 vs 18. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ This should reverse the rankings and might push Swift into a top 10 language.

vorg 7y ago
> Objective C is much higher than Swift: 11 vs 18. And Apache Groovy rose from number 91 to number 17 in the past 12 months also according to that same Tiobe page (May 2019). Quoting Tiobe for anything only discredits what you're trying to prove.

childintime 7y ago

I was waiting for Apple to react to Flutter. It was a threat. They couldn't bluntly forbid Flutter apps. Now it seems this is their answer. Soon you'll be able to compile SwiftUI to Flutter and reach all platforms it reaches. Their play: to get the best experience, you'd still need to buy an iPhone.

mleonhard 7y ago
Who said anything about compiling SwiftUI to Flutter?

dvtrn 7y ago

Does the syntax sort of kind of remind anyone else of Shoes?[1] http://shoesrb.com/ http://shoesrb.com/

ksec 7y ago
Yes, I wonder what framework Apple engineers looked at for inspiration, and if they looked at shoes. Although I doubt they are allowed to answer this question.
- jurip 7y ago
  Here's one comment about inspiration: https://twitter.com/jckarter/status/1135666944273571840 https://twitter.com/jckarter/status/1135666944273571840
geowwy 7y ago
The nesting makes it look similar but Shoes isn't declarative so it works very differently under the hood

binthere 7y ago

Will there be a similar API for Objective-C?

vedantroy 7y ago

This is definitely an overly ambitious project idea, but now that Google has Jetpack Compose and Apple has SwiftUI, and the web has React, I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively. Then you would get truly native, cross-platform development. Now, the probability this would ever work is 1%, but it's something that has lingered in my mind anyway.

Despegar 7y ago
>I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively. Just no. As an Apple user, just use whatever the tools they give you when you're developing for Apple platforms.
tspike 7y ago
It would be great until you need to debug something. Then it would be a nightmare.
munificent 7y ago
> I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively. Flutter targets native code on Android and iOS and JavaScript for the web. It has very mature compilers for all three.
astrange 7y ago
All meta-platforms are themselves platforms; meta-ness is in the implementation. So you could always do this no matter what you started from, but it's not actually a good idea. https://xkcd.com/927/ https://xkcd.com/927/

archagon 7y ago

Lots of engineers are suggesting that SwiftUI, plus other declarative frameworks, might be "the future" of app development. However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing. If you're working with highly interactive interfaces, complex animations, or dense, layered documents (DAWs, video editors), it seems that you would need explicit state and imperative code at the center of it all, and that a declarative approach would require hacks and workarounds at every turn. In my humble opinion, some of the most interesting, ground-breaking, and creative software has these properties; whereas this reactive stuff seems tailored to bog-standard utility software. However: I've never used React or any of its derivatives, so this is mostly inference. Is this take accurate or not? In theory, could you scale SwiftUI to build something like Logic, Blender, or Photoshop (for example)? Also, have any declarative UI frameworks been released that feature a "platform" layer, where you get to define how your declarative code actually turns into UI, widgets, and behaviors? It seems that SwiftUI relies on (encoded) assumptions of what an ideal UIKit or AppKit app is supposed to look and feel like, and it would be really powerful if we could mess with this foundation or even swap it out entirely. (It's very possible I'm mixing up reactive/declarative/reactive-UI concepts since I'm not too familiar with the territory.)

arithma 7y ago
Take most of the Adobe creative suite as an example. Different paradigms will fit different aspects of the UI design. Nobody wants to expend the same effort to build CRUDs as they would when they're working on "groundbreaking" stuff. Reality is a bit more nuanced: you want to abstract as much as possible and make it trivial, so that you can focus most energy where it matters. Patterns/Language/Frameworks all come into play here, and SwiftUI is a beautiful addition.
kccqzy 7y ago
Every software needs explicit state. If React is any indication, it tells us that the management of this explicit state can be made much more pleasant when written in a declarative way.
pault 7y ago
I can only speak for React, but the declarative component model doesn't eliminate state or imperative code, it just nudges you towards separating your stateful code from your layout/rendering code. In the React/Redux convention, your application is one big state machine with transitions encoded in reducers, and your state -> view data transformations in "selectors". View components are composed into one big pure function of state. Putting barriers between those classes of functionality makes it much easier to compose complex behavior from small, focused functions. Obviously you can write code with those properties in any context, but conventional React/Redux architecture makes the lines more explicit, which is why I like it. Lots of people hate it.

artemiszx 7y ago

Thinking about starting a new project over the summer. But seeing the demos it seems just starting something in UIKit now is a bad idea?

myko 7y ago

So frustrating this wont be usable for most apps for at least 2 years. Meanwhile Android, which yeah only 5% of users or something crazy small are on the latest version, will get to use the latest libraries on versions released 5+ years ago.

creolabs 7y ago

This is exactly what we did with Creo a couple of years ago: design, preview and development in a single tool. We rewritten UIKit from scratch in order to be able to preview iOS code on MacOS. Looks like we did it right. https://creolabs.com https://creolabs.com

croxx5f 7y ago

It smells a little like dart UI as code(flutterish may i say)

machinesbuddy 7y ago

It reminded me of Scaloid https://github.com/pocorall/scaloid https://github.com/pocorall/scaloid

kensai 7y ago

OMG, has anyone noticed the device icons on the bottom of the SwiftUI page? Steve will be turning in his grave...

dgellow 7y ago

Something like this available in C++ would be so great for cross platform applications!

zaiste 7y ago
There is Boden (native apps from a single C++17 codebase) https://www.boden.io/ https://www.boden.io/
- dgellow 7y ago
  As far as I understand Boden is still a work in progress, far from being ready for prime time.

abalone 7y ago

I’m wondering what this could mean for replacing React Native. Obviously SwiftUI is geared for Apple’s platforms but overall it seems pretty high level and perhaps amenable to being adapted to Android by somebody. Swift is open source after all. This would solve a problem a lot of devs have in deciding how to build a cross platform app. We don’t want to give up first class support for each platform but it’s silly to have completely separate codebases. I hear even Apple has React Native dev groups.

OkGoDoIt 7y ago

For more information, there's a much more in-depth demo in the "Platforms State of the Union" session, which is now posted at https://developer.apple.com/videos/play/wwdc2019/103/ https://developer.apple.com/videos/play/wwdc2019/103/

appliaison 7y ago

Now, will someone be a sweetheart and write a transpiler that will transpile AndroidXML to SwiftyUI and SwiftyUI to AndroidXML. Also, while you're at it, please write a transpiler for Flutter to SwiftyUI and SwiftyUI to Flutter. K. Thx.

atilkan 7y ago

Looks nice like Flutter.

adamspb 7y ago

Am I the only one thinking "SwiftUI compile to WASM"?