Hacker News Reader

> Part of that, I hate to admit, is probably because I'm 60, and I got really sick of sitting in meetups, with a circle of avoidance around me.

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 love this. I quite like Swift.

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

> 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

> upon looking for work at 55, but I've managed to "lean in" to living humbly, and being happy with my work.

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.

Great writeup.

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

>I write native UIKit applications, using Swift. No PWAs, no hybrid systems (like React, Electron, or Ionic).

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?

I tend to do relatively humble apps, most of the time (but I have been working on a pretty damn ambitious social media-style app for over a year and a half. It's still a ways from completion).

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

> the apps I write are really small, really secure, really fast, accessible, highly usable, use very few system resources, leverage the latest Apple tech, have almost no external dependencies, work extremely well, and I write them very, very quickly.

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.

See, here's the deal: I really don't care. I love writing the apps I write, using the tools I use, for the target devices that I target.

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.

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

> the framework would instead fill the gaps

Might this be asking for patent trouble, though?

I doubt that this would pose an issue for most bits of desktop software UI. Most UI patents tend to be focused on specific parts of apps (e.g. the Instagram profile page layout), rather than on more broad UI features like toolbars. They also tend to be more focused on mobile UI, desktop UI hasn’t really moved much in the past 20 years aside from cosmetic tweaks.

And, if I cleave to the Apple toolset (as opposed to rewriting it, like I used to), that stuff is sorted. Apple has much better lawyers than I'll ever be able to afford.

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

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.

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?

That wasn’t a bad rant, until the last two sentences.

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.

Aha, I did not intend to be contemptuous to you personally, sorry about that. And you do not need to justify anything to me, my rant is more of the untargeted frustration kind. I understand the desire to work in a straightforward manner that suits you personally, I am just sad the same thing cannot be achieved across all the platforms.

I’m with you. I’m also an iOS (as well as macOS) developer. I started doing Cocoa development a few years before the iPhone came out, when it was much more of a niche than it is now. I’ve never had trouble making a very good living doing it, but I really started and continue to enjoy it because it enables me to create the things I want to create, right through to a polished UI that fits in with my favorite platforms to use.

You could make another app for Android. I think it's an unsettled question that one cross-platform app is a better business move than two independent apps.

There are use cases, where a hybrid system is the most useful path. These are usually cases, where the main product is a server-based service, and the apps are really fairly basic "skins" of the service.

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.

> But usability is always reduced, in cross-platform systems.

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.

I’m not sure vscode (or JS for that matter) is necessarily slow anymore. I find the potential for speed in the JavaScript world often comes down to good design decisions. vscode performance issues have often been resolved with better design. These days it’s impressively snappy. Of course there are limitations and JS isn’t a top shelf performance language, but for most things with a UI it is pretty good now.

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.

This is my experience with using React Native. I commented on it recently in another context, which was that my team of relatively competent people had a surprisingly hard time keeping the build and deployment pipeline happy. It was a lot of overhead. We essentially had to live with knowing we had low confidence in it, and there wasn’t much to do about it.

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.

This is awesome. I too work on mobile app development. I started on Java way back where I use Eclipse IDE for Android development. Then the transition to Android Studio, I remember I was an early AS adopter around version 0.8. Then I started Swift also the same as you, around 2014. Then another transition to Kotlin. I am not sure if I'm a niche programmer but I want to stay in this lane until I get old and for me as someone who's approaching 40 this is a little bit worrying. But reading your story is awesome and gave me hope.

There is a new crop of startups that are going full native, and not using things like React Native, and Flutter and other 'xchross platform' frameworks. They are falling out of the trend as they have the same problem that we have had since the Java Midlet times in the 90s, they tend to be: write once, debug everywhere.

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

I love swift but don't do any OS X development and don't want to use XCode. Not sure how the LSP plugin is doing these days but last time I tried it it was pretty unstable (also why can't they have it in the store so you won't need to install manually?). I wish swift for tensorflow had really taken off and put it in a position to compete with python as it's a very enjoyable language.

I've done some Swift using AppCode (https://www.jetbrains.com/objc/), a Jetbrains editor, and was very satisfied.

I remember trying that but I wanted to write swift for server and Linux and it was geared entirely to OS X and iOS apps at the time.

I know a very good developer that uses AppCode, and swears by it. He is also a native Swift/UIKit developer.

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.

Sounds like he's still in the apple ecosystem. What i wanted to do was use it for scripting and server stuff (swift for server and Linux) and I think AppCode was not compatible with that at the time.

I'm pretty sure that Swift is an llvm frontend, and that there are probably a number of adapters for it.

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

It's certainly doable command-line.

I love your passion about Swift and UIKit, more power to you! I'm a generalist who spent lots of years trying various cross-platform solutions (Xamarin, C++, RN, KMM etc) and they all fail short when compared to the native apps. XCode sometimes sucks as an IDE but the vertical integration that Apple has is unbeatable.

I got to learn and program Swift at my last job. We needed to integrate a C computer vision library into React Native, so Swift was the answer. I really enjoyed the language. I felt like it gave me a surprising amount of low-level control while still providing high-level abstractions and automated memory management.

I wish I had stuck on with UIKit. SwiftUI has been amazing to build on, and easier than UIKit. The declarative syntax, not worrying about tracking state in the VC, has made readability of views easy.

SwiftUI however has made UI Testing at any level unviable.