Man, this makes me sad. I come from a traditional engineering field; in meetup situations, the old guys were ALWAYS the most popular people around due to the sheer volume of problems they've solved and situations they'd seen. I got to talk to so many people whose names are synonymous with their (admittedly niche) fields (except for Ted Anderson[0], who's pretty well-known in the relevant industries) and learned a ton from all of them.

[0]https://fracturemechanics.com/

I've been enjoying Elm for a few years, because it keeps me away from most of the bloat and churn in web UI tech / frameworks, and it's enjoyable (for me) to work in. It really helps to keep my sanity and avoid burnout. Your choice of Swift is really appealing to me... I'm not a huge fan of "apps" in general though. Still, I would guess that Swift will be around for a long time.

I'll add that it helps to be financially sorted (and no longer motivated by trying to become uber rich).

Yup. I'll have to admit that I was quite nervous, when I was first being shown the door, repeatedly, upon looking for work at 55, but I've managed to "lean in" to living humbly, and being happy with my work.

It's not an "either/or" choice. We don't need to be a captain of industry, or raking in big bucks, in order to be a highly-relevant, productive engineer. I think that some of these companies were insanely self-destructive, to have ignored me; but, as things have turned out, I'm glad they did. I needed to be pushed out of the nest.

I have been writing systems for all my life. These usually have some kind of a "backend," which could be a device and/or network-connected server, and a "frontend," which is what a user of the system sees and interacts with. In some cases, I designed the backend, and in others, I adapted, or wrote, a frontend to an existing backend. I've written a number of realtime APIs; some of which have lasted for decades. I do good, robust, work.

I've really enjoyed writing software that presents a user interface. Over the years, I have come to enjoy the process of developing a "mental model" of a software system, and presenting it to a user. I come from an artistic background, so making it aesthetically-pleasant is also something that I like.

Here's an example: I'm in the process of rewriting one of my apps; a "speaker timer."[0] Simple enough, and the iOS system already has one, so there's no "burning need" for the app; but it's something that I use frequently, and I'm not so happy with the "stock" one.

But the one that I wrote a few years ago (Actually, it started with an ObjC one, in 2012) is too complex and awkward. It needs a rewrite anyway, because it's "dated," so this gives me an opportunity to "get it right."

I'm just finishing the initial setup screen. This screen is actually a greatly simplified amalgam of three other screens in the previous version. I think it works great. I'm not moving on to the other screens, until I consider this one "done," meaning that it has all the autolayout complete, works on an old iPhone SE, running iOS 14, has all the voiceover strings done in English, and has zero (as in "zed") bugs; even small ones. I use a personal process that I call "constant beta," where the app is always at "beta" quality; although it may be incomplete. This results in astonishingly high Quality, and a fairly predictable ship schedule. It also means that integration testing starts from Day One.

Just this morning, I spent a couple of hours, chasing down a weird bug, that turned out to be an iOS14 issue, on iPhone SEs (the 1st gen). I couldn't get it to happen on any other devices, running iOS14. Even though it was a UIKit bug (that seems to have been fixed, since), and it was on a deprecated OS, on a deprecated hardware platform, I still figured out how to work around it, and fixed the issue in my app (for the curious, it was because a toolbar that is directly attached to the safe area insets of the main view would cause a weird hang, upon rotate).

There's three more screens to go, and each one will receive the exact same level of attention. Once that's done, I'll do the localizations for the three other supported languages, and give it accessibility testing.

All along, it will be tested on devices, ranging from iPhone SE (1st gen), running iOS14, to iPad Pro 12.9 (running the latest iPadOS), and even Macs.

All that, for a $0.99 app. It sells like crap, and no one really cares, but I won't do any work, unless it has this kind of polish.

I'll probably write a Watch app, after I get the main iOS/iPadOS/Catalyst one done. I'd started one, previously.

I'm quite aware that this is a commercially infeasible workflow, and I don't care. It's like having a kid's trike, that was made by Mercedes engineers.

[0] https://github.com/RiftValleySoftware/ambiamara

Yes, I think this is a really important point. I've discovered over the course of my career that I'm unintentionally very picky with my work. Being in a position (financially) where I'm not forced into work that makes the days feel really really long is amazing.

I like getting older because one's preferences, opinions, and control are so much more refined.

Sounds like a dream scenario. Pure native Apple development is without a doubt the most seamless, intuitive, and enjoyable dev environment I've ever worked with. And libraries like UIKit put anything the JS ecosystem has on offer to shame.

What type of applications do you? Are you contracted or a solo dev?

Pretty much a solo dev. I'm semi-retired (but work harder than I ever did, when earning a paycheck).

Since 2012, I've had over 20 apps on the App Store, but most have been retired. I think I'm down to three or four. I list them here[0].

I'm in the process of rewriting AmbiaMara[1] (I'll clean up the docs, as it gets closer to release). It's a ways off, but it's coming along nicely.

[0] https://littlegreenviper.com/AppDocs/

[1] https://github.com/RiftValleySoftware/ambiamara

And they're only available for one proprietary platform [1], no? Excluding half of the user base for phones (in the US), and probably much more for personal computers, seems like a really bad business move in many cases. And depending on the type of application, it could be considered a different type of accessibility problem. It's depressing, but so often we have to compromise technical excellence and even user experience for economic reasons; in this case, using a cross-platform technology to develop a suckier app that can reach all host platforms is often the smart business move.

[1]: Well, one platform for each form factor.

I do this for the love of the Craft.

But I completely get you, about the business reasons. I can't, in good conscience, argue against most deployments of hybrid systems.

What is sad, is companies that release shoddy hybrid apps, developed by lowest-bid offshore shops (who often do a better job than onshore ones), then refuse to continue supporting their crapplets.

The other thing that bums me out about cross platform “solutions” as a fellow UIKit/AppKit dev is their lowest-common-denominator design, making them incapable of the features that make each OS unique and interesting. I’d like to see the opposite approach, where if platform A was missing something that platform B had, the framework would instead fill the gaps and provide that capability on platform A too. At least for me that’d make cross platform development a good deal more pleasant.

As you noted, a robust set of widgets and capabilities out of the box is important too. The miles-long dependency list that comes with the typical JS app stack is unappealing at best, and nothing is worse than having to hunt down an implementation of a widget you need only to find that the 4 options available all have huge holes in functionality in different places, with 2 in some state of disrepair and 1 not being suitable for your project for some miscellaneous reason.

Might this be asking for patent trouble, though?

Also, I use lots of dependencies. It's just that they are generally ones that I wrote.

I have control issues, I guess...

Everyone wants to write unique UI, but I've learned that's a trap. I write about that, here: https://littlegreenviper.com/miscellany/the-road-most-travel...

Actually, that's not the sad part. The sad part is that Apple, despite being one of the richest companies in the world, basically doesn't care about any attempt to make this situation better, and actually actively works against it.

I work on a cross platform desktop application win/mac, and the process of dealing with OSX development is so frustrating it essentially does not make sense for the size of the user-base. You need Apple hardware to develop. You need an Apple developer account to develop. Xcode is incredibly unstable. C++ support of Clang is out of date. IT management of a fleet of OSX devices is a pain. Notarization and code signing fails regularly due to Apple server downtime. Documentation is horrible, many issues you face must be solved through forum posts where other people shotgun debugged their way out and shared the results. OSX systems are not dependable as long running build servers, frequently causing issues with keychain locks, expiring credentials, volume dismounts, blocking remote access, etc.

On top of that Apple happily blocks any attempt you make at doing cross platform work properly by avoiding support for cross platform APIs: OpenGL is stuck 10 years in the past, and now officially deprecated. Vulkan is not supported. Only supported graphics API is Metal, which is proprietary. WebGL2 support took 5 years to arrive in safari after chrome/ff. WebGPU is likely to follow the same pattern. IOS is locked to a single browser engine. Any attempt to make a webpage behave like an app, works on android but not ios. (example: https://caniuse.com/gyroscope).

Apple doesn't want hybrid apps to work at all, and is busy strangling any initiatives for cross platform APIs. If the browser were invented today Apple would be the first to proclaim a proprietary alternative that would be incompatible and split the world in half. It has created an ecosystem isolated from the world, just the way it likes. As a developer you can learn their ecosystem, and place yourself inside it. However, don't fool yourself into thinking that you are allowing Apple users to use your application, no sir, instead Apple is kind enough to allow you to develop your app for Apple users, and that kindness may expire at any time.

I really cannot understand why a developer would choose to live in such an uncontrollable, closed down, anti-developer system, and even evangelize it.

Apple hates you, why do you love it back? Is this stockholm syndrome?

I do what I do, get the results that I get, and I don’t need to justify it to those that view me with contempt.

A number of years ago, I did take a few months, and learned native Android development (Java, at the time). It was a serious effort, and I spent months, learning the IDE, build system, Play Store, etc. I did publish an app on the Play Store (long since deceased, but I still get Google spam, from it).

I found it to be unpleasant, and returned to the Apple fold. This was nothing against the system. I just didn’t like it.

But usability is always reduced, in cross-platform systems. I have been writing cross-platform stuff for decades. Usually, I wrote the Apple part, and another developer wrote the [usually] Windows part. We have tried things like Qt, which is acceptable, but not especially nice.

No matter how much people crow about how hybrid systems are "every bit as good" as native systems; they are wrong.

If you (and/or your users) care a lot about the Quality of the user experience, then native is the way to go. This is especially true, if there are unusual user interface concepts and widgets involved.

No matter how you write it, though, a released software product is a Responsibility. I liken it to having children. Making them is fun. Having them, is less fun. Once they are in your life, you are Responsible for them.

Anyway, the actual end result was impressive for how much code we were able to reuse, we were able to build it pretty quickly, etc.

But it wasn’t that great in a number of more subtle ways, like in terms of usability as you mention. Accessibility features were missing in some cases. Various behaviours didn’t match the OS quite right, and we couldn’t easily find ways to make it happen. Text handling of all things was extremely convoluted and hard to get right.

You’re right that it suits cases where you want a skin over a more complex back end service. But even then, I’m not convinced it isn’t worth learning to build with native tools.

We’re obsessed with saving time. Every team I’ve worked on that tried to save time was just saving time to build more stuff with corners being cut. It’s rarely actually worth it. Make a few things, do it well, and I bet you’ll see better results than if you build 100 shitty things.

I’m not particularly successful in software so who knows, I’m certainly not an authority.

A native app is limited by capabilities of the platform. Perhaps Xcode is so bad because AppKit does not quite support the use case.

On the other hand you have VSCode, a slow Electron app, but, by it's nature, really easy to extend.

Electron seems to eat a lot of resources, but it can still be fast. I think it tends not to be because the people building stuff with it aren’t necessarily well-versed in writing software. Or perhaps they don’t have the time and resources to make it happen due to constantly shifting business goals, for example.

By all means vscode rarely presents performance issues for me anymore, even on my 2017 MacBook Air. Some things can be slow, but they tend to be specific to extensions and not vscode itself.

So, keep using the native tools as close to the platform is smart strategy on the long term (as fads come and go).

Xcode is a bug farm. I would be filled with chagrin, if it were my project, but it's always easy to be a Monday morning quarterback.

It gets the job done.

Wouldn't surprise me a bit, if it could be done with Eclipse (not my favorite IDE).

It's certainly doable command-line.

SwiftUI however has made UI Testing at any level unviable.