Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

30k lines of SwiftUI in production later

blog.timing.is

Post reply on HN
Print view View original

71–80 of 124 posts

Re: 30k lines of SwiftUI in production later

#71

Post by brookst »

bsaul wrote: post #36
toyg wrote: post #34

Earlier quoted context omitted.

What missed opportunity, Apple saw the opportunity right there and took it: the opportunity to reinforce the lock-in they always, always consider imperative to achieve. People think Apple simply don't care about other platforms, but that's just not true. They do care - they care that developers should stay the hell away from them.

i know, it's just completely delusional. Thinking that a programming language can thrive in a walled garden is insane. They've been burned by this in the past with objc, i don't understand how they can try again.

Apple’s business goals are for 1P and 3P apps to provide the best app+device experience on Apple hardware. Everything they to is to that end, since they make their money from selling hardware.

A programming language thriving is a secondary or tertiary goal.

Re: 30k lines of SwiftUI in production later

#72

Post by nodemaker »

herodotus wrote: post #54
meindnoch wrote: post #28

Why can't people just use boring technology?

This is why: it's hard to get things right. When I started programming for Apple almost 20 years ago (mainly using Objective C), too many hours of my time were spent making sure that I was dealing with memory correctly. Easier in Objective C than C's primitive malloc/free, but still hard, even with the tools to help. During my time there, new things were tried: firstly garbage collection, and then automatic reference…

For an expert with some mathematical intuition layout constraints can do a custom layout that lays out perfectly on all screen sizes much better than declarative. However there is a learning curve I admit.

Re: 30k lines of SwiftUI in production later

#74

Post by nodemaker »

lawgimenez wrote: post #27

I think the author was just pushing the boundaries of iOS development too much. You could tell in the app that the UI was complex and some guidelines were not followed. This is the consequence when you over engineer and over design and being fancy.

Native platform development is about going as smooth as possible. Otherwise React Native serves very well for mediocre quality stuff.

Re: 30k lines of SwiftUI in production later

#75

Post by nodemaker »

Zanfa wrote: post #47
mrtksn wrote: post #9

Earlier quoted context omitted.

What's wrong with Xcode? Is it the usual "iPhone is preparing for development" type of annoyances? Is it the bugs that sometimes prevent you from compiling? Or is it something more fundamental like even when everything works fine you don't like it?

1) It's sloooooooooow 2) It's extremely buggy, like on a daily basis where something just doesn't work for any apparent reason that is usually either fixed by killing Xcode or removing derived data & then killing Xcode 3) Lack of plugins for even the most primitive of features like autoformatters 4) XML for build configs inside .xcodeproj 5) Why does it take half a day to update through the App Store? I mean it has s…

For C/C++ Xcode is way better than VSCode in my opinion.

Although I miss github copilot a bit when I do it.

Re: 30k lines of SwiftUI in production later

#76

Post by StewardMcOy »

lapcat wrote: post #51
LudwigNagasena wrote: post #41

Earlier quoted context omitted.

I guess that means we should expect AppKit and SwiftUI to never improve.

AppKit has been going downhill for years.

I don't know why this is being downvoted. The situation is more complex than this simple comment, but the sentiment is correct.

The reality is that AppKit has had its ups and downs recently. There are obviously people in Apple trying to do their best to patch things up, and there have been some nice improvements because of their efforts, but some really bad bugs have been introduced, only to sit unfixed for years. It's gotten to the point where I dread the yearly OS updates, not because I dread having to update my code, but because I worry what has broken.

In my experience, if you don't get your bugs filed within the first week after WWDC, they'll never get fixed, and even if you do, it's a toss-up. But testing your existing code isn't always enough. If you're writing new code to take advantage of some of the new OS features, you can be a month into the beta cycle before you find a bug, and by that point, its too late.

Re: 30k lines of SwiftUI in production later

#77

Post by enraged_camel »

SpaghettiX wrote: post #21

> It took a few hours to fall in love with SwiftUI. > It was in development for 12 months. It would have been less if SwiftUI just gave. > At the end, we didn’t drop it for a couple of reasons. We were too deep into the process. Being a bootstrapped operation that was already severely behind schedule, we couldn’t afford to restart. This may be useful to someone trying to create something: In terms of software enginee…

>> implementing the most challenging parts of your UI as a sanity check

How are you supposed to do this if you don’t yet have proficiency in the language/framework/toolset?

Re: 30k lines of SwiftUI in production later

#78

Post by sgt »

jb1991 wrote: post #31
SpaghettiX wrote: post #21

> It took a few hours to fall in love with SwiftUI. > It was in development for 12 months. It would have been less if SwiftUI just gave. > At the end, we didn’t drop it for a couple of reasons. We were too deep into the process. Being a bootstrapped operation that was already severely behind schedule, we couldn’t afford to restart. This may be useful to someone trying to create something: In terms of software enginee…

The problem with solutions like Flutter is that many apps, especially iOS apps (though maybe not a calendar app), will often use powerful platform features on iOS that are not so readily available on other platforms, so some degree of platform-specific code is always going to be there -- maybe a lot of such code. For example, the amazing Core Image library, or writing Metal kernels (increasingly common since it is ra…

As a Flutter developer, I am 100% aware that native is usually best, unless you are writing Android apps which are bit of a nightmare compared to iOS.

Re: 30k lines of SwiftUI in production later

#79

Post by bsaul »

brookst wrote: post #71
bsaul wrote: post #36

Earlier quoted context omitted.

i know, it's just completely delusional. Thinking that a programming language can thrive in a walled garden is insane. They've been burned by this in the past with objc, i don't understand how they can try again.

Apple’s business goals are for 1P and 3P apps to provide the best app+device experience on Apple hardware. Everything they to is to that end, since they make their money from selling hardware. A programming language thriving is a secondary or tertiary goal.

Except the end-result of that policy is that 90% (made up number) of the app on the store are made with cross-platform tools, because very few can afford 1/ learning a language just for one platform 2/ not reusing any code at all between platforms.

I don’t think swift has any future in the long term unless they go multiplatform.

Re: 30k lines of SwiftUI in production later

#80

Post by StewardMcOy »

_corvo_ wrote: post #6
silh wrote: post #4

Earlier quoted context omitted.

AFAIK, you can also use VS code or CLion.

I’m assuming you meant AppCode. It’s been discontinued: https://www.jetbrains.com/objc/ With VSCode, do you get live preview?

The Swift team released a VS Code plugin recently. As far as I'm aware, it doesn't do live preview, but considering how often Xcode fails to render live previews, I'm not seeing that as much of a loss.
Post reply on HN