Yes, you can use SPM to package up Objective-C code.

Right, but you can’t have a single package containing both ObjC and Swift. It’s a limitation of SwiftPM that has prevented me from using it for a few projects (I am using it in several others, though).

You can mix them, it just has to be released as a binary framework which is a bit annoying as I would prefer a pure source release but it does work.

Since it clearly wasn’t obvious, I was asking in the context of a package consumer, not publisher.

My involvement with MacOS development is somewhat limited and I have no plans publishing any packages yet ;)

Oh gotcha, yeah they’re absolutely usable as any maintainer mixing the languages and providing SPM support will handle the binary release part. If anything it’s nicer for the consumer (binary releases in general) as it cuts down on full app rebuild times.

I kept hitting my head against the wall, and getting a million stupid errors trying to resolve header files. But in the end I got it working, and I will no longer be one of the guys pestering the old Cocoapods servers :)

For whoever comes after me... When ChatGPT suggests changing your Objective-C from this:

   #import package.h

To this:

   #import <package/package.h>

Just skip that rabbithole of inifiny-nested failure, and just do this instead:

   @import package;

And you're done. You can thank me later :)

I should have included the following information in the blog post (will update it later!):

I usually have:

- 45g of air popped popcorn (64 calories).

- 5 to 10g of butter (37 - 74 calories).

- couple of garlic cloves (10 cals).

Probably my favourite book on programming. Thanks for posting it here - I'll have to make time for a re-read of it.

Information arbitrage is one helluva social media drug.

The thing that's "holding back" the iPad isn't hardware. It's the economics of the App store.

I'm sure Apple are very happy with the niche the iPad dominates in - it leaves plenty of room for Mac laptop sales.

Maybe you just aren't going to be able to afford everything and will just have to make a choice about what you consume.

It's not really a question of what you can afford; it's a question of who deserves your business.

I suspect Apple knows the developer experience for Swift is terrible (even if the Apple developer community at large is in mass denial about this).

The number 2 item on Swift Core Teams goals for Swift 6 is "Create a fantastic development experience". See: https://forums.swift.org/t/on-the-road-to-swift-6/32862

Whether anyone at Apple cares about documentation any more is another matter. A really sad state of affairs, because once upon a time, Apple had some of the best documentation out there. Of course, that was when they actively needed to court a developer community, and couldn't just announce something half-baked at WWDC and get mass adoption from enthusiastic developers.

I don't know, maybe some of the die hards are in denial. I really enjoy the language and the platforms but I'd readily admit it's pretty far behind in terms of DX. I think at this point Apple is going to have to make this a really big priority if they want to remain relevant and it's going to take a lot of effort on their part.

While I certainly can't speak for all diehards, I hear a lot of complaints about the state of Apple's documentation from long-time developers these days. (In my experience, the true Apple diehards are often very critical of the company, but they tend to have specific trenchant critiques.)

Even iOS programming communities will admit you're brave for using SwiftUI right now. It's brand new, has a lot of issues like being completely unable to show you a coherent type-error message (like if you have an error inside a ForEach view).

It's just cutting edge tech.

Could you talk a bit about the kinds of things you had to fight the compiler on?

Can you identify any idioms or approaches that seem normal or natural in other languages, but which are problematic in Rust?

Two examples: The application has two main components, a controller and a struct containing the ui implementation. Callbacks in the cursive library are called with a reference to Cursive, but I had a hard time figuring out how to pass the controller to the callback. In the end I decided to use a message channel (mpsc::Receiver and mpsc::Sender) to let the two components communicate. After some struggling I saw that cursive has a function to set user data which is accessible inside the callbacks. So I pass the channels through userdats. Not sure if this is the best architecture. I never managed to pass a reference to the controller to the ui callbacks. The Compiler complained about undefined lifetime of the reference, though I knew that both outlive the application runtime.

A similar situation occurred in the asynchronous communication with gopher servers. I use a thread to fetch a resource from another server while keeping the ui responsive. Passing the result from the thread back did not work out in the beginning.

I don’t think the idioms are so different in Rust, but when passing data between components, threads and the like, you have to be very specific in your code, using Arcs, RwLocks, Mutexes, etc.

On the bright sight, when the code compiles, it usually worked as intended. Using C or C++, there would be more race conditions, null pointer exceptions and more.

You are dealing with a lot, in a compressed period of time.

Try to remember that your first priority and responsibility is looking after your own mental, physical and spiritual (I don't mean this in a religious sense) well being.

In your situation, work really should be the lowest priority that you can afford to make it. If you can afford to take extended time off to deal with everything you need to, I would highly recommend that you give it serious consideration.

I wouldn’t just take time off without a plan for doing something. It’s really easy to spend months or years at home without improvements. Go to a psychologist or something. I once spent a month at a yoga ashram which was a turnaround for me.