When Objective-C headers are imported into Swift using a bridging header, a single Objective-C protocol appears as two different entities in Swift code.

Say we have the following Objective-C header file that has been imported into a Swift target using a bridging header:

// Fungible.h

@protocol Fungible<NSObject>
- (NSString *)funge;
@end

There are two ways to refer to this protocol in Swift: using a native Swift type, or using an Objective-C Protocol object reference.

let fungibleSwiftProtocol = Fungible.self
let fungibleObjCProtocol = NSProtocolFromString("Fungible")!

These two types should be the same—after all, they refer to the same protocol—but they are not, as shown when we print out their descriptions and ObjectIdentifiers:

print("fungibleSwiftProtocol: \(fungibleSwiftProtocol)")
print("fungibleSwiftProtocol object identifier: \(ObjectIdentifier(fungibleSwiftProtocol))")
print("fungibleObjCProtocol: \(fungibleObjCProtocol)")
print("fungibleObjCProtcol object identifier: \(ObjectIdentifier(fungibleObjCProtocol))")

Which produces the output:

fungibleSwiftProtocol: Fungible
fungibleSwiftProtocol object identifier: ObjectIdentifier(0x00000001f5d8e300)
fungibleObjCProtocol: <Protocol: 0x100008780>
fungibleObjCProtcol object identifier: ObjectIdentifier(0x0000000100008780)

They are different! But of course they’re different, you say: one of them is a Swift Any.Type, while the other is a Protocol instance. Sure, but they refer to the same thing. Is there a way to actually test if they refer to the same thing?

Read more…

• #ios
• #macos
• #programming
• #swift
• #objective-c

Open Source Software in a world of capitalism can only exist as a pastime for the already-rich. Only companies extracting profit from something else can afford to maintain OSS. Only individuals paid for something else can contribute significant time to OSS projects in their spare time.

It’s a precarious thing to profit directly from maintaining OSS and selling it as a service, precisely because someone else can copy and repackage your work for less money—which is entirely within the spirit of OSS—and undercut your business model. A business truly in the spirit of GPL would celebrate such a copy; but a business that must profit from their work on OSS would see it as theft of their livelihood.

In other words, insistence on “pure altruism” as the basis of open-source software is essentially a shorthand for excluding those who are not already wealthy. It’s elitist.

• #opinion
• #programming

“Quiet quitting” doesn’t exist, at least not in any numbers that matter.

People aren’t “quiet quitting”; they’re burned out. Years of layoffs and increasing responsibilities are frying people to a crisp. Yes, people who WFH have more options to disengage for self-care, but that’s actually a good thing.

Almost every coworker I’ve met wants the company to succeed—their well-being is tied to the company’s fortune, after all. They want to do quality work. They want to brag about their products. They want to have fun. But also, almost every coworker I’ve met is stressed out with shrinking deadlines and continual layoffs, and always having to do more with less time.

Adding RTO to the mix means workers have to invest even more time in commuting to the office, and even less time to cope with ever increasing amounts of work. RTO will not cure Quiet Quitting. They’ll just reveal it for what it is: burnout, and make it worse.

• #opinion
• #FridayDevAdvice

I continue to believe that #returnToOffice is primarily based on these factors:

1. Executives (not managers—they don’t care) wanting more control over workers’ days. They want to imprison underlings in buildings so they have no choice but to attend to their commands. It strokes their ego and makes them look important. Bonus points if the executive works remotely most of the time.

2. Preserving commercial real estate values. Companies that have huge campuses and other investments in CRE are most eager to have people return to buildings. A famous fruit company would look like a fool for spending $5B on a space donut if it weren’t filled with people.

3. Municipalities are renegotiating tax breaks they offered based on employment targets. No foot traffic downtown = no tax incentives for companies.

4. It’s a hidden layoff. RTO is meant to be a hardship, so people quit. It doesn’t matter that the people who quit first are the most wealthy and in-demand workers. Numbers are numbers.

• #opinion
• #remoteWork
• #returnToOffice

Jason Snell wrote on SixColors:

Without good hardware and software, Apple’s services would be irrelevant. I hope everyone in a position of authority at Apple understands that. Services are a way to help make Apple’s hardware even more profitable than it already was. But services can never, ever take precedence over Apple’s hardware. If Apple ever begins to see its hardware as merely a vessel for selling more subscription services, the game will be over.

https://sixcolors.com/post/2024/08/existential-thoughts-about-apples-reliance-on-services-revenue/

Existential thoughts about Apple’s reliance on Services revenue

Apple Pay and Apple Card are among Apple’s growing services. Apple’s latest quarterly results were about as boring as you can get while still featuring $21.4 billion in profit and setti…

sixcolors.com

I suspect this line has already been crossed. #Apple has gone through these phases:

1. We sell hardware
2. We sell hardware and software
3. We give away software to sell hardware
4. We sell hardware and charge other people to sell software
5. We sell services to enhance our hardware
6. We sell services through our hardware

We are now between phases 5 and 6. The sheer profitability of Services will inevitably lead to a de-emphasis of (non-iPhone) hardware sales. I predict Services will very soon exceed iPhone in terms of profits because of its incredible margins.

• #apple
• #opinion