Is SwiftUI framework declarative or imperative or neither? - swiftui

I'm having a discussion with a collegue, who insists the SwiftUI is imperative. To me, it seems very declarative. Is he right?

As noted in numerous WWDC 2019 videos (e.g., SwiftUI Essentials and Introducing SwiftUI), SwiftUI is declarative. Apple repeatedly contrasts it to traditional, imperative approaches. The first line of their SwiftUI documentation says that it is for “declaring your app's user interface”. Apple’s SwiftUI Essentials WWDC 2019 video describes SwiftUI as their “new declarative framework.”
Admittedly, SwiftUI can be married with imperative techniques, too. For example, one can combine SwiftUI views with UIKit imperatively generated views/apps. In another example, when one adds a tap handler to a view element, one can subtly shift from the “what” of declarative programming to the “how” of imperative programming, as you outline a series of steps to be taken to achieve some task. Perhaps your colleague is alluding to one of these aspects of SwiftUI.
But it is inaccurate to contend that SwiftUI is an imperative framework. It is essentially declarative.

SwiftUI uses the programming paradigm known as declarative programming.
A major advantage of learning and using SwiftUI is allowing for cross-platform development for the different operating systems within the Apple ecosystem. No more having to learn four different frameworks if you want to build an app that has components on Apple Watch, Apple TV, MacBook Pro, and finally your iPhone.
It is important to know that SwiftUI does not replace UIKit. Instead, it is built on top of providing and an additional layer of abstractions for us.

Imperative mainly focuses on the how a program is doing something. Declarative in my mind means that SwiftUI plainly states what is going on via its syntax. In Apple's marketing blurb of SwiftUI they show a sample of code that is very declarative in my opinion. You can tell that in a view you can target a body and display images and vertically stack some text with in the body. I think its stating what is going on without low level syntax like:
#IBOutlet weak var CaptionLabel: UILabel!
#IBAction func Submit(_ sender: Any) {
CaptionLabel.text = "Hello World"
}
Based on the syntax above there is a lot of how something is working. You can see #IBAction which is declaring to the Interface builder that this is how a function is being set to a button press. To me this is kind of the how it is working not really what is happening. In the new SwiftUI behind the scenes maybe its still #IBAction and #IBOutlets but in my opinion Apple has made the syntax more declarative to humans and doesn't concern us with the behind the scenes things that are going on. I feel this way since SwiftUI is built on top of UIKit. The gauge I kind of use is if the syntax is human readable and its abstracting away a lot of the low level details of how its working then its more declarative.

Related

How do I set the blur intensity of a system material in SwiftUI 3?

SwiftUI 3 introduced the concept of system materials – akin to a UIVisualEffectView with a UIBlurEffect.
Text("Hello world!")
.padding()
.background(.thinMaterial)
How do I change the intensity of blur applied by a system material?
SwiftUI currently does not offer a way to achieve this. It is, however, possible to achieve using SwiftUIX.
Install SwiftUIX via the Swift Package Manager.
In your code, import SwiftUIX.
Use VisualBlurEffectView with the .intensity(_:) modifier.
Text("Hello world!")
.background {
VisualEffectBlurView(blurStyle: .systemThinMaterial)
.intensity(0.5)
}
Disclaimer: Both this answer and the question were written to document SwiftUIX (an MIT-licensed open-source package) in a Q/A style format. As of writing this question I am currently not aware of any simple way to achieve this via UIKIt, and will gladly amend the answer to prescribe an official approach if/when one becomes available. I'd also love to just dump the code specific to this component, but it relies on a number of extensions/hacks that are spread across the SPM package that would be impractical to isolate just for the purpose of bundling a copy-paste solution to this answer.

Are all SwiftUI Views intermediaries for UIKit views?

Are all SwiftUI Views intermediaries for UIKit views? If so what are they wrappers for?
I think NavigationView -> UINavigationController etc...
Absolutely NOT.
First of all, there is no such thing as UIKit for other Apple platforms. So for example, you will see other counterparts like AppKit for macOS, which is enough to say NO to your question.
Second of all, Apple is hardly trying to build all SwiftUI components natively. But until all of them are available, they are using other platforms' existing components instead.
Maybe they will decide to not do it someday, who knows...
This repository can help you see which is linked with which for now

Is it possible to use SwiftUI for UI in an AR-App using SceneKit?

I am currently working on an AR-App using SceneKit. I can't use RealityKit because I need Image Recognition which it doesn't support at this time.
With this tutorial I found a way to integrate SwiftUI into the AR-Scene but not as a typical UI-/HUD-Element.
Is it there a way to use SceneKit for Image Recognition and SwiftUI as UI?
In a certain way you can. Here's a Medium story on this topic. Also this SO post might be useful.

Using CareKit in SwiftUI

I've been struggling with CareKit for past few days and I were unable to use CareKit in my SwiftUI project.
It would be so great if I could get a really really simple project on SwiftUI.
Also how can I use only one specific Card? for example only Task Card.

Clojure: how to architect desktop UI

I'm trying to design a desktop UI for schematics, layout, drawing stuff. Just looking for high level advice from actual software designers.
Assuming an in-memory "database", (clojure map of arbitrary depth for all user data, and possibly another one for application preferences, etc.), I'm examining how to do the model-view-controller thing on these, where the data may be rendered and modified by any one or more of:
A standalone text field that shows a single parameter, such as box width.
An "inspector" type of view that shows multiple parameters of a selected object, such as box width, height, color, checkboxes, etc.
A table/spreadsheet type of view that shows multiple parameters of multiple objects, potentially the whole database
A graphical rendering of the whole thing, such as both schematic and layout view.
Modifying any one of these should show up immediately in every other active view, both text and graphical, not after clicking "ok"... so no modal boxes allowed. If for some reason the table view, an inspector view, and a graphical rendering are all in view, dragging the corner of the box graphically should immediately show up in the text, etc.
The platform in question is JavaFX, but I'd like a clean separation between UI and everything else, so I want to avoid binding in the JFX sense, as that ties my design data very tightly to JFX Properties, increases the graininess of the model, and forces me to work outside the standard clojure functions for dealing with data, and/or deal heavily with the whole getValue/setValue world.
I'm still assuming at least some statefulness/mutability, and the use of built-in Clojure functionality such as the ability to add-watch on an atom/var/ref and let the runtime signal dependent functions.
Platform-specific interaction will rest tightly with the actual UI, such as reifying ActionListeners, and dealing with ObservableValues etc., and will attempt to minimize the reliance on things like JavaFX Property for actual application data. I'm not entertaining FRP for this.
I don't mind extending JFX interfaces or making up my own protocols to use application-specific defrecords, but I'd prefer for the application data to remain as straight Clojure data, unsullied by the platform.
The question is how to set this all up, with closest adherence to the immutable model. I see a few options:
Fine-grain: Each parameter value/primitive (ie Long, Double, Boolean, or String) is an atom, and each view which can modify the value "reaches in" as far as it needs to in the database to change the value. This could suck as there could potentially be thousands of individual values (for example points on a hand-drawn curve), and will require lots of (deref...) junk. I believe this is how JFX would want to do this, with giant arrays of Properties at the leaf nodes, etc., which feels bloated. With this approach it doesn't seem much better than just coding it up in Java/C++.
Medium-grain: Each object/record in the database is an atom of a Clojure map. The entire map is replaced when any one of its values changes. Fewer total atoms to deal with, and allows for example long arrays of straight-up numbers for various things. But this gets complicated when some objects in the database require more nesting than others.
Coarse-grain: There is just one atom: the database. Any time anything changes, the entire database is replaced, and every view needs to re-render its particular portion. This feels a bit like using a hammer to swat a fly, and a naive implementation would require everything to re-render all the time. But I still think this is the best trade off, as any primitive has a clear access path from the root node, whether it is accessed on a per-primitive level or per-record level.
I also need the ability for one data template to be instantiated many times. So for example if the user changes a symbol or shape which is used in multiple places, a single edit will apply everywhere. I believe this also requires some type of "pointer"-like behavior. I think I can store a atom to the model, then instantiate as needed, and it can work in any of the above grain models.
Any other approaches? Is trying to do a GUI editor-like tool in a functional language just stupid?
Thanks
I don't think is stupid to use a functional language to do a GUI editor-like tool. But I can't claim to have an answer to your question. Here are some links that might help you in your journey:
Stuart Sierra - Components Just Enough Structure
Chris Granger - Light Table: Explains how Light Table (source) is structured.
Chris Granger - The IDE as a Value: blog post related to the video above
Conal Elliott - Tangible Functional Programming: Using Functional Reactive Programming to create a composable UI, but his code is in Haskell.
Nathan Herzing & Chris Shea - Helping voters with Pedestal, Datomic, Om and core.async
David Nolen - Comparative Literate Programming: Shows all to use core.async to simplify UI programming in ClojureScript. The ideas here can be used in a desktop UI.
Rich Hickey - The Language of the System: Amazing talk about system programming by the creator of Clojure.
Erik Meijer has a good quote about functional vs imperative code:
...no matter whether it's Haskell, C# Java, F#, Scala, Python, PHP think about the idea of having a sea of imperative code that interacts with the outside world and in there have islands of pure code where you write your functions in a pure way.
But you have to decide how big the islands are and how big the sea is. But the answer is never that there are only islands or only sea. A good programmer knows exactly the right balance.