Live data from Hacker News

SwiftUI

developer.apple.com

241–250 of 394 posts

Re: SwiftUI

#241

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…

>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.

Re: SwiftUI

#242
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.)

Re: SwiftUI

#243

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 co…

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.

Re: SwiftUI

#244

Earlier quoted context omitted.

I wouldn't call anything close to cross-platform if it only works on Apple's products and devices.

You're welcome to your definition, but if you think developing for desktops, notebooks, smartphones, and tablets, with all the differences they encompass is trivial, you're in for a shock. Even with other cross-platform offerings like Flutter, React, Electron and so on, getting one codebase to work out of the box on just two platforms can be a challenge. On mobile, there tends to be a need to drop down from the cross…

You are literally the only person I have ever heard to use "cross-platform" in the sense you just described.

Did you mean "cross form-factor" or something?

Re: SwiftUI

#245

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 co…

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.

Re: SwiftUI

#246

Earlier quoted context omitted.

You're welcome to your definition, but if you think developing for desktops, notebooks, smartphones, and tablets, with all the differences they encompass is trivial, you're in for a shock. Even with other cross-platform offerings like Flutter, React, Electron and so on, getting one codebase to work out of the box on just two platforms can be a challenge. On mobile, there tends to be a need to drop down from the cross…

You are literally the only person I have ever heard to use "cross-platform" in the sense you just described. Did you mean "cross form-factor" or something?

No. Macs run macOS, iOS devices run iOS (and now, iPadOS), Apple Watches run watchOS, and Apple TVs run tvOS. They might have shared heritage but they are decidedly not the same platforms; these are not different form factors for the same thing (aside from iPhone/iPod touch and iPad), these are different platforms with different use cases, different capabilities, different sets of available frameworks including what languages are supported both in terms of compiled code and what can run as an interpreter on-device, different kinds of considerations for interaction, different userbases with different expectations.

This is not some far flung usage of the term 'cross-platform'.

Nobody would doubt that Windows 10 and Windows Mobile/Windows Phone are/were different platforms. Nobody would imagine a modern Linux distribution and Android were remotely the same thing, despite their shared heritage and the fact that Android can very happily run optimised for pretty much any form factor that an OEM decides.

It's merely because all of these different platforms are made by the same company that even the slightest bit of skepticism creeps into peoples' minds but make no mistake, they are different beasts with different needs. If they were as similar as people think they are, iOS developers wouldn't need something like Project Catalyst to bring their apps to the Mac, they'd already be doing it.

Re: SwiftUI

#247
post #55

Earlier quoted context omitted.

Do you have a link to the comparison?

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.

Thanks! Indeed it's impressive.

Re: SwiftUI

#248
post #231
post #178

Earlier quoted context omitted.

Nice work! In the keynote it was mentioned that SwiftUI would work across all Apple products. Will it work on previous versions or only the latest iOS/macOS/etc?

What? You develop it using SwiftUI, then you compile it and it will run on whatever you compile it to. So yes, it will run on older OS versions.

https://news.ycombinator.com/item?id=20088593

Re: SwiftUI

#249

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

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.

Re: SwiftUI

#250

Earlier quoted context omitted.

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 developme…

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?

The notion that all of Apple's users are just fools for good PR is not one to which I bother to respond because I choose not to be called a pawn.

Treating other people like that is, to my mind, a shallow dismissal of an opinion you did not have the good patience to discover in the first place.

Post reply on HN